https://bugzilla.novell.com/show_bug.cgi?id=458913 Summary: Failed to boot after kernel upgrade (grub, udev, solved) Product: openSUSE 11.0 Version: Final Platform: x86-64 OS/Version: openSUSE 11.0 Status: NEW Severity: Normal Priority: P5 - None Component: Update Problems AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: agn@acm.org QAContact: jsrain@novell.com Found By: Customer This bug was encountered when upgrading to opensuse 11.0 in two cases. The system will not boot after the kernel was upgraded via yast/online-upgrade. case 1: normal upgrade of a server with a 4-disk (pta on two controllers) from 10.0 to 11.0. In 11.0 the pta disks are now named /dev/sd{a,b,c,d}. The disks are mostly a software raid5 array, with a 1GB partition each for /boot, /tmp, and two sawp's. The disk that used to be /dev/hda has the /boot partition and the grub-boot loader. During the upgrade/installation, it was referred to a /dev/sda, but after the first boot, udev decided to call it /dev/sdc (and swap it it with /tmp). mdadm took it in strides and after fixing /etc/fstab life was good until the kernel-update via yast/online-update. The update proceeded normally, but then the system was no longer able to boot, hanging right after the boot system selection and failing to find the kernel image. The MBR is fine. case 2: upgrade of an FC7 system to opensuse 11.0. The "upgrade" went surprisingly painless. System has a 3ware hardware raid5 array and an sata disk for /boot, / and swap. Called /dev/sda and /dev/sdb in the freshly installed system. The sata disk is the boot disk and lives on a sata controller on the motherboard. It is the boot disk. After the kernel-upgrade the system no longer boots (same symptom). cause: the script that updates the menu.lst file in /boot/grub is blissfully unaware of the madness that lurks behind udev. It made the silly assumption that in case 1: /dev/sdc1 (= /boot) should be referred to as "root (hd2,0)" in menu.lst. In case 2, is assumes that /dev/sdb1 (= /boot) ought to be "root (hd1,0)". fix: use a rescue system correct the menu.lst file in /boot/grub to refer to the boot disk as "root (hd0,0)". Gratuitous flame: hardware device discovery in Linux is just plain nuts! I ran into this problem numerous times. The underlying hardware is 100% deterministic, does not play musical chairs and does not depend on the phase of the moon. Yet, Linux manages to assign device names randomly. I know udev and how to fix this some times, but it is an anoying, unnecessary waste of time. In this case, the nice folks at Suse, can get it right. And it is not just disks: I have a mythTV server with multiple tuner cards that are different and are connected to different video-sources. /dev/video<n> used to scramble without being hardwired via udev, which is tedious. A box in our lab that controls numerous devices via USB->RS232 dongles gets routinely confuse which /dev/ttyUSB<n> controls what. udev that! These dongles are real primitive and don't have unique ID's. Thus the boot procedure now involves unplugging the lot of them and plugging them in after the system is up in a certain sequence. Good grief. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.