machine stops at GRUB screen during boot process
in [General Linux]
|
Prev: NYC LOCAL: Tuesday 27 April 2010 NYLUG: Squeak Hack Fest
Next: Fancast compared to Hulu plus my not so quick look at a bunch of the Linux OS
From: Robert Heller on 29 Apr 2010 18:48 At Thu, 29 Apr 2010 21:42:29 +0000 (UTC) Rahul <nospam(a)nospam.invalid> wrote: > > Robert Heller <heller(a)deepsoft.com> wrote in > news:RMednVLRfbO-bETWnZ2dnUVZ_r6dnZ2d(a)posted.localnet: > > > Thanks Robert! > > > There are two options: > > > > If this is not possible either because if the Adaptec chip is actually > > on the motherboard or if there is some physical reason the cards > > cannot be swapped (type of PCI card (aic79xx is for the 64-bit PCI > > cards), physical constraints of the case, etc.), then you have another > > option: > > You predicted correctly. A straight swap seems impossible. The internal > MegaRAID drives seem to be connected to a PCI card (I see LSI logic > printed on the card) > > The external array on the other hand is connected directly to a riser on > the Motherboard. This seems to be a SCSI riser. (There's a short cable in > there that connects the internal SCSI riser to a plate on the backplane.) You have a integrated Adaptec *chip* on the motherboard somewhere and the riser is the SCSI bus connector, in this case connecting to an external connector plate (much like the late model AT motherboards that had integrated serial and parallel ports). > > > 2) When the system starts to boot up, you can type ^A when the Adaptec > > SCSI BIOS anounces itself. You can then configure the SCSI BIOS not > > to get loaded (eg you can disable it). > > I'll try that now! That seems like the way to go. Will report success or > not in case that helps anyone! I didn't realize that disabling the > Adaptec BIOS didn't affect the recognition by later stages. > > There was some other things that puzzled me. Just in case you knew the > answers: > > A) > My grub file syntax seems slightly different from what's documented on > the grubwebpage. > > e.g > my Grub: default=0 > GNU Grub: default 0 > > my Grub: splashimage=(hd0,0)/grub/splash.xpm.gz > GNU Grub: undocumented. > > Is this some kind of tweak that Red Hat is doing? It seems to work > nevertheless. It is probably a version issue -- the grub webpage is probably documenting a *newer* release of grub. CentOS 5 (RHEL 5) is using grub 0.97. > > B) > > What's the difference between: > grub-install /dev/sda > and > grub-install /dev/sda1 > > I understand that the former installs GRUB on the MBR and the other on > the partition but when does one do one over the other? > One would to the latter if one is using *another* bootloader to load grub (eg you are using MS-Windows's (native) boot loader to load grub or something like 'System Commander', etc.). Since the *BIOS* generally only deals with the MBR, you should use the first version when grub is going to be the primary (BIOS invoked) boot loader. -- Robert Heller -- 978-544-6933 Deepwoods Software -- Download the Model Railroad System http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows heller(a)deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/
From: Bit Twister on 29 Apr 2010 18:53 On Fri, 30 Apr 2010 00:42:51 +0200 (CEST), Dave U Random wrote: > Thinking out of the box here: have you tried using LILO instead? If I mis-understand it correctly, when you do the lilo install it hard codes drive and location. If drive numbering moves, lilo is not going to work any better than grub.
From: Rahul on 29 Apr 2010 19:06 Dave U. Random <anonymous(a)anonymitaet-im-inter.net> wrote in news:a4e33e8d6728036af292ba50cbd4a7e1(a)anonymitaet-im-inter.net: > Why don't you blacklist the aic79xx module, so that it doesn't > get loaded automatically? You can then execute appropriate commands at > Will that prevent the grub bootloader from finding it? I thought blacklisting comes in a bit later? -- Rahul
From: Robert Heller on 29 Apr 2010 19:08 At Thu, 29 Apr 2010 22:53:46 +0000 (UTC) Bit Twister <BitTwister(a)mouse-potato.com> wrote: > > On Fri, 30 Apr 2010 00:42:51 +0200 (CEST), Dave U Random wrote: > > > Thinking out of the box here: have you tried using LILO instead? > > If I mis-understand it correctly, when you do the lilo install it hard > codes drive and location. If drive numbering moves, lilo is not going > to work any better than grub. Right. -- Robert Heller -- 978-544-6933 Deepwoods Software -- Download the Model Railroad System http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows heller(a)deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/
From: Rahul on 29 Apr 2010 19:51
Robert Heller <heller(a)deepsoft.com> wrote in news:G- mdnWtRPso8kUfWnZ2dnUVZ_hmdnZ2d(a)posted.localnet: > You don't have to worry about the LVM volumns 'moving around' because > of device discovery order -- the volumn group works like a e[234]fs > LABEL. You should be using LABEL= for all file systems on 'bare' on bare > partititions (eg /dev/sd<mumble>1 for /boot). (You *can* use LABEL= for > file systems on LVM volumns, but you don't *have* to.) > But there is no way to teach grub to use LABELs or Logvols, right? -- Rahul |