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: Rahul on 29 Apr 2010 13:32 Robert Heller <heller(a)deepsoft.com> wrote in news:vq-dnSQK-IrSPEXWnZ2dnUVZ_g2dnZ2d(a)posted.localnet: > You might want to do something to 'fix' this problem by swapping the > PCI cards for the internal and external RAID disks. I'm guessing you > have some flavor of (LSI) MegaRAID SCSI RAID controller in a PCI slot > and an Ataptec (?) SCSI card in another PCI slot for the external SCSI > connected (self-contained) RAID unit. Swap the two PCI cards. This > will reverse the order they are seen by the BIOS. > > I am assuming that the /boot file system is mounted using the LABEL= > feature in the system's /etc/fstab file. Thanks very much for all the tips guys! I finally have the server correctly booting up. But I can only do this if my external RAID array is disconnected. If I connect it the grub order seems to get messed up again. As an alternative I was thinking of booting up the server and then mounting /home from the external RAID array. Unfortunately if I connect that array after bootup it does not automatically appear in the /dev list. Is there any way or command to make the system probe for such a SCSI- connected array after bootup? That would be the quickest fix for now I feel! -- Rahul
From: Rahul on 29 Apr 2010 13:34 Robert Heller <heller(a)deepsoft.com> wrote in news:ivmdnY9yPqqJQkXWnZ2dnUVZ_tGdnZ2d(a)posted.localnet: /boot. Rahul needs to do the following: > > 1) fire up his CentOS 5.4 rescue disk > 2) use e2label to give /dev/sda1 a label (e2label /dev/sda1 boot) > 3) change /dev/sdb1 to LABEL=boot in the /etc/fstab file. > 4) make sure /boot is properly mounted > 5) chroot /mnt/sysimage > 6) grub-install /dev/sda > 7) exit > 8) exit Thanks very much Robert for the detailed diagnosis. You are probably spot on for most part. But not all: The /boot was already being mounted using a LABEL. I checked fstab. Also e2label shows that the boot partition indeed has the /boot label. I even tried the grub reinstalls but nothing works. Except, as I say in the other post, if I keep the external RAID drive unconnected then now I can boot successfully. Got to figure out how to mount /home now. Thanks again!! -- Rahul
From: Robert Heller on 29 Apr 2010 13:55 At Thu, 29 Apr 2010 17:34:49 +0000 (UTC) Rahul <nospam(a)nospam.invalid> wrote: > > Robert Heller <heller(a)deepsoft.com> wrote in > news:ivmdnY9yPqqJQkXWnZ2dnUVZ_tGdnZ2d(a)posted.localnet: > > /boot. Rahul needs to do the following: > > > > 1) fire up his CentOS 5.4 rescue disk > > 2) use e2label to give /dev/sda1 a label (e2label /dev/sda1 boot) > > 3) change /dev/sdb1 to LABEL=boot in the /etc/fstab file. > > 4) make sure /boot is properly mounted > > 5) chroot /mnt/sysimage > > 6) grub-install /dev/sda > > 7) exit > > 8) exit > > Thanks very much Robert for the detailed diagnosis. You are probably spot > on for most part. But not all: > > The /boot was already being mounted using a LABEL. I checked fstab. Also > e2label shows that the boot partition indeed has the /boot label. I even > tried the grub reinstalls but nothing works. > > Except, as I say in the other post, if I keep the external RAID drive > unconnected then now I can boot successfully. Got to figure out how to > mount /home now. OK, it sounds like you need to swap the order of the PCI cards. This will make the external RAID show up as /dev/sdb and NOT interfere with grub's and the BIOS's view of things and the O/S disk will stay /dev/sda. What is probably happening is that the external RAID drive is being seen *first* and getting itself mapped to the first BIOS disk (0x80 / 'C'). You don't want this as it confuses grub. If you swap the PCI cards, the internal RAID (served by the MegaRAID card) will get mapped to the first BIOS disk (0x80 / 'C') and then the external RAID drive will get mapped to the second BIOS disk (0x81 / 'D'). Grub will happily ignore this second drive. When the kernel boots, it will load the drivers for the internal and external RAID drives and udev will do its magic and map /dev/sd?? as needed. The system will then boot up as it should. Be sure to have a LABEL for the external RAID drive's file systems and use that in /etc/fstab. > > Thanks again!! > -- 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: unruh on 29 Apr 2010 14:15 On 2010-04-29, Rahul <nospam(a)nospam.invalid> wrote: > Robert Heller <heller(a)deepsoft.com> wrote in > news:vq-dnSQK-IrSPEXWnZ2dnUVZ_g2dnZ2d(a)posted.localnet: > >> You might want to do something to 'fix' this problem by swapping the >> PCI cards for the internal and external RAID disks. I'm guessing you >> have some flavor of (LSI) MegaRAID SCSI RAID controller in a PCI slot >> and an Ataptec (?) SCSI card in another PCI slot for the external SCSI >> connected (self-contained) RAID unit. Swap the two PCI cards. This >> will reverse the order they are seen by the BIOS. >> >> I am assuming that the /boot file system is mounted using the LABEL= >> feature in the system's /etc/fstab file. > > Thanks very much for all the tips guys! > > I finally have the server correctly booting up. But I can only do this if > my external RAID array is disconnected. If I connect it the grub order > seems to get messed up again. > > As an alternative I was thinking of booting up the server and then mounting > /home from the external RAID array. Unfortunately if I connect that array > after bootup it does not automatically appear in the /dev list. > > Is there any way or command to make the system probe for such a SCSI- > connected array after bootup? That would be the quickest fix for now I > feel! It is still not clear to me what your setup is. At one point you seemed to say that there were three "disks" and internal raid array, and external raid array, and an extra disk containing the /boot partition. It is also unclear to me at which point grub is dying on you. Does the operating system chooser splash screen come up, grup starts doing stuff, and then dies? Or does it die right after the chooser, or before? You might be able to tell grup to find the right partition via UUID rather than via disk name. Or via label. >
From: TomT on 29 Apr 2010 15:12
Robert Heller <heller(a)deepsoft.com> wrote: >At Wed, 28 Apr 2010 17:55:59 -0600 TomT <TomT(a)UnrealBox.invalid> wrote: > >> It seems like your RAID problem messed GRUB up as both J G Miller and >> Robert Heller have said. > >Right. From what little Rahul has told us, I'm guessing that his >machine has two disk controllers: > >1) Some flavor of [PCI] Adaptec SCSI controller (probably some sort of > 2940-flavor card) with some sort of self-contained SCSI-connected > RAID unit (eg a small-scale box like a DEC HZ70) > Since he mentioned the Adaptec SCSI *first*, I *suspect* that the > external RAID box originally showed up as /dev/sda >2) Some sort of [LSI] MegaRAID PCI SCSI RAID controller with three > internal SCSI disks, that contain some flavor of RHEL or CentOS, with > two partitions, originall /dev/sdb1 (mounted as /boot) and /dev/sdb2, > which is a LVM volume group. For some idiot reason, the O/S was > installed on the *second* logical disk, or else the system somehow > became the second logical disk (maybe the Adaptec SCSI controller + > external RAID box was added later). You're way ahead of my knowledge here, Robert. >The BIOS was configured to boot off of /dev/sdb (originally or at some >point). Then the external RAID lost a disk (which was replaced and the >RAID array rebuilt off-line somehow). Now with /dev/sda (the external >RAID array) not connected the BIOS is trying to boot from what used to >be /dev/sdb, but is now /dev/sda. Grub at this point is using the BIOS >parameters for /dev/sdb though or at least the piece of grub residing >in the MBR of the MegaRAID logical disk that used to be /dev/sdb, but >is not /dev/sda. Yes, this seems reasonable. >I suspect that the /etc/fstab on the root file system wants to mount >/dev/sdb1 as /boot when it reall ought be to mounting /dev/sda1 as >/boot. Rahul needs to do the following: Agree again. >1) fire up his CentOS 5.4 rescue disk >2) use e2label to give /dev/sda1 a label (e2label /dev/sda1 boot) >3) change /dev/sdb1 to LABEL=boot in the /etc/fstab file. >4) make sure /boot is properly mounted >5) chroot /mnt/sysimage >6) grub-install /dev/sda >7) exit >8) exit > >When the system has rebooted properly, shut it down (shutdown -h now) > >Open the case and swap the positions of the two PCI cards (the MegaRAID >and the Adaptec card). > >Fire up the machine to make sure things are working properly. > >Shut the machine down and re-connect the external RAID system and start >the machine up. The external box should now show up as /dev/sdb. > >I guessing whoever originally set this box up was some flavor of idiot. LOL! >Yes, you don't *have* to install Linux on the *first* logical disk, but >PC BIOS/Boot loaders work better if you do, especially when you have >disks that can possibly be removed from the system easily. Especially >if they are SCSI disks, since SCSI disks have a 'fluid' device naming... Agreed yet again. I hope Rahul understands your instructions. TomT |