[opensuse] 11.0 mdraid1 - Install OK, after updates - GRUB ERROR 17
Listmates, Latest fresh install of 11.0 has been quite frustrating. The original install went fine and the system booted fine. After 2nd online-update (1st update just updated zypper/package mgmt) the machine is left unbootable with GRUB ERROR 17. I have included as much information about the setup as I can manually type from within (Rescue# ). Why did online update break the boot loader config and how do I fix grub now? The setup is a simple 2-disk ATA md raid1 install on an older i386 box (abit kt7, 1G of ram, 2 250G Maxtor drives). Both disks are partitioned identically: sda1 100M primary sda5 20G logical sda6 2G swap sda7 220G logical sdb1 100M primary sdb5 20G logical sdb6 2G swap sdb7 220G logical md0 (sda1 sdb1) as /boot md1 (sda5 sdb5) as / md2 (sda7 sdb7) as /home As noted the fresh install booted fine. I was able to configure kde, and do online updates. The reboot from the 2nd online update which included the kernel update is where the problem started. I didn't mess with anything in Yast except to configure the network card and to do an online update. Here is the configuration information: Current grub setup: ---menu.lst--- root(hd0,0) kernel /vmlinuz-2.6.25.11-0.1-pae root=/dev/md1 resume=/dev/sda6 splash=silent showopts vga=0x317 ---device.map--- (fd0) /dev/fd0 (hd0) /dev/sda (hd1) /dev/sdb ---grub.conf--- setup --stage2=/boot/grub/stage2 (hd1,0) (hd0,0) quit ---grub.conf.old (this was in /etc from the install - changing made no difference)--- setup --stage2=/boot/grub/stage2 (hd0,0) (hd0,0) setup --stage2=/boot/grub/stage2 (hd1,0) (hd0,0) quit Booting to the 11.0 rescue system, cat proc partitions shows md0, md1 and md2 just fine. mdadm reports that all md raids are fine and are using the right partitions. Mounting the drives with: mount /dev/md1 /mnt mount /dev/md0 /mnt/boot mount /dev/md2 /mnt/home all works fine. I can access and edit all the files. However for some reason the grub config is gone and it fails during the boot sequence. I have tried manually starting the installed system from the cd, but selecting sda5 or sdb5 or sda1 or sdb1 results in nothing. I have tried specifying /dev/sda5 and /dev/sdb5 in grub menu.lst, but nothing works. It seems like in 10.3 I could manually boot the system by choosing the root partition on either drive in the raid and it would work. Not so here. I have been unsuccessful using grub-install from rescue mode and I can't get yast to work with everything mounted under /mnt. I need help. Anybody know what voodoo is required to straighted grub out in this situation? Anything else I can provide? Thanks in advance for any help or wisdom you can provide. -- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
David C. Rankin wrote:
---menu.lst---
root(hd0,0) kernel /vmlinuz-2.6.25.11-0.1-pae root=/dev/md1 resume=/dev/sda6 splash=silent showopts vga=0x317
initrd /initrd-2.6.25.11-0.1-pae is also there (omitted in original post) -- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
----- Original Message -----
From: "David C. Rankin"
David C. Rankin wrote:
---menu.lst---
root(hd0,0) kernel /vmlinuz-2.6.25.11-0.1-pae root=/dev/md1 resume=/dev/sda6 splash=silent showopts vga=0x317
initrd /initrd-2.6.25.11-0.1-pae
is also there (omitted in original post)
I just had to manually get around the os 11.0 b0rked bootloader stuff in order to boot from software raid1 too. In my case I specifically wanted grub in mbr. They make a perfectly good argument for not doing that anymore so I won't say this is what you should do, only that it's the way I did it. boot the os11.0 install media choose repair pretty much anywhere after that, ctrl-alt-F2 to the 2nd console I'll assume you either know how to manually assemble the raids and mount them, or that they are already assembled and mounted by the install/repair system. In my case after choosing repair, auto, selecting the /dev/md2 (which is my "/" on raid10) and skipping over some errors where the util doesn't quite know what to make of the partitions, I get to a point where it attempts to repair the boot loader. At that point I ctrl-alt-F2 and the util has already assembled /dev/md0 (/boot on raid1) and /dev/md2 (/ on raid10) And it has mounted them like so: /dev/md2 -> /mnt /dev/md0 -> /mnt/boot So then I was able to do this: chroot /mnt vi /boot/grub/devices.map: (hd0) /dev/sda (hd1) /dev/sdb (hd2) /dev/sdc (hd3) /dev/sdd (hd4) /dev/sde (hd5) /dev/sdf (hd6) /dev/sdg (hd7) /dev/sdh vi /boot/grub/menu.lst: # Modified by YaST2. Last modification on Thu Aug 21 18:04:29 UTC 2008 default 0 timeout 10 ##YaST - activate ###Don't change this comment - YaST2 identifier: Original name: linux### title openSUSE 11.0 kernel (hd0,0)/vmlinuz root=/dev/md2 noresume showopts initrd (hd0,0)/initrd ###Don't change this comment - YaST2 identifier: Original name: failsafe### title Failsafe -- openSUSE 11.0 kernel (hd0,0)/vmlinuz root=/dev/md2 showopts ide=nodma apm=off acpi=off noresume edd=off x11failsafe initrd (hd0,0)/initrd vi /etc/grub.conf: setup (hd0) (hd0,0) setup (hd1) (hd1,0) setup (hd2) (hd2,0) setup (hd3) (hd3,0) setup (hd4) (hd4,0) setup (hd5) (hd5,0) setup (hd6) (hd6,0) setup (hd7) (hd7,0) quit grub --batch http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 08/22/2008 05:18 AM, David C. Rankin wrote:
Listmates,
Latest fresh install of 11.0 has been quite frustrating. The original install went fine and the system booted fine. After 2nd online-update (1st update just updated zypper/package mgmt) the machine is left unbootable with GRUB ERROR 17. I have included as much information about the setup as I can manually type from within (Rescue# ). Why did online update break the boot loader config and how do I fix grub now? My guess is your grub.conf is the problem. BTW, I have no idea why you have a separate /boot partition in your setup, but not the problem. To fix it, boot to the rescue system, and reinstall grub to your MBR of sda, i.e. mount /dev/md1 /mnt mount /dev/md0 /mnt/boot mount -o bind /dev /mnt/dev mount -o bind /proc /mnt/proc mount -o bind /sys /mnt/sys cd /mnt chroot /mnt
#Then reinstall grub via grub command line: root (hd0,0) setup (hd0) #Then to install in the other drives MBR for possible fallover: root (hd1,0) setup (hd1) quit #That will leave grub command line. exit shutdown -r now That should get you going. -- Joe Morris Registered Linux user 231871 running openSUSE 10.3 x86_64 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Joe Morris wrote:
On 08/22/2008 05:18 AM, David C. Rankin wrote:
Listmates,
Latest fresh install of 11.0 has been quite frustrating. The original install went fine and the system booted fine. After 2nd online-update (1st update just updated zypper/package mgmt) the machine is left unbootable with GRUB ERROR 17. I have included as much information about the setup as I can manually type from within (Rescue# ). Why did online update break the boot loader config and how do I fix grub now? My guess is your grub.conf is the problem. BTW, I have no idea why you have a separate /boot partition in your setup, but not the problem. To fix it, boot to the rescue system, and reinstall grub to your MBR of sda, i.e. mount /dev/md1 /mnt mount /dev/md0 /mnt/boot mount -o bind /dev /mnt/dev mount -o bind /proc /mnt/proc mount -o bind /sys /mnt/sys cd /mnt chroot /mnt
#Then reinstall grub via grub command line: root (hd0,0) setup (hd0) #Then to install in the other drives MBR for possible fallover: root (hd1,0) setup (hd1) quit #That will leave grub command line. exit shutdown -r now That should get you going.
Thank you Joe and Brian, Damn that was frustrating. Evidently, something in the online-update/kernel update wiped out a mbr or something else grub relied on to boot successfully. What was particularly STRANGE was NOTHING was changed in either /boot/grub/menu.lst /boot/grub/device.map or /etc/grub.conf. For my setup with md0=/boot md1=/ md2=/home, the following corrected the problem. (1) boot from the install DVD (2) choose "Rescue System", login as "root" (no password needed) (3) mount all md devices under /mnt, then bind dev/, proc/ and sys/ and chroot as mentioned by Joe above. **Note, you need to mount the md device containing the / (root) filesystem first. Otherwise the /boot and /home directories will not exist: mount /dev/md1 /mnt mount /dev/md0 /mnt/boot mount /dev/md2 /mnt/home mount -o bind /dev /mnt/dev mount -o bind /proc /mnt/proc mount -o bind /sys /mnt/sys cd /mnt chroot /mnt (4) use grub as mentioned above to fix the mbr on you raid discs (mine were hd0 and hd1): grub
root (hd0,0) setup (hd0) *** few lines of grub output *** root (hd1,0) setup (hd1) *** more lines of grub output *** quit
(5) exit (to exit chroot) and reboot I don't know if this also helped, but I used fdisk to set the /boot and / partitions on each disc as bootable with fdisk /dev/sda and toggling the boot flag with the "a" option. Anyway, it boots normally again. Thanks again for the help. Hopefully this will not happen again on the next kernel update... -- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
David C. Rankin schreef:
Joe Morris wrote:
Listmates,
Latest fresh install of 11.0 has been quite frustrating. The original install went fine and the system booted fine. After 2nd online-update (1st update just updated zypper/package mgmt) the machine is left unbootable with GRUB ERROR 17. I have included as much information about the setup as I can manually type from within (Rescue# ). Why did online update break the boot loader config and how do I fix grub now? My guess is your grub.conf is the problem. BTW, I have no idea why you have a separate /boot partition in your setup, but not the
On 08/22/2008 05:18 AM, David C. Rankin wrote: problem. To fix it, boot to the rescue system, and reinstall grub to your MBR of sda, i.e. mount /dev/md1 /mnt mount /dev/md0 /mnt/boot mount -o bind /dev /mnt/dev mount -o bind /proc /mnt/proc mount -o bind /sys /mnt/sys cd /mnt chroot /mnt
#Then reinstall grub via grub command line: root (hd0,0) setup (hd0) #Then to install in the other drives MBR for possible fallover: root (hd1,0) setup (hd1) quit #That will leave grub command line. exit shutdown -r now That should get you going.
Thank you Joe and Brian,
Damn that was frustrating. Evidently, something in the online-update/kernel update wiped out a mbr or something else grub relied on to boot successfully. What was particularly STRANGE was NOTHING was changed in either /boot/grub/menu.lst /boot/grub/device.map or /etc/grub.conf. For my setup with md0=/boot md1=/ md2=/home, the following corrected the problem.
Is it possible that the problem isn't with menu.lst but with device.map? I also had some error 17s, and still have them if I forget to power on an usb drive. Something wrong with the order of mapping the drives? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 08/25/2008 01:31 AM, Amedee Van Gasse wrote:
Is it possible that the problem isn't with menu.lst but with device.map? I also had some error 17s, and still have them if I forget to power on an usb drive. Something wrong with the order of mapping the drives?
That sounds like it may be the way your BIOS presents the new drive to the system. There is often an order of drives in the BIOS. if this is changed at the BIOS level, it may make device.map incorrect for what the BIOS is saying, causing the type of problem you are seeing. To get a grub error means grub is found by the BIOS, to get the error means grub has not found the grub files it needs in the places it was setup to look for them. -- Joe Morris Registered Linux user 231871 running openSUSE 10.3 x86_64 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (4)
-
Amedee Van Gasse -
Brian K. White -
David C. Rankin -
Joe Morris