Bugzilla – Bug 137062
9.3->10.x upgrade fails with 'yast2 update' when using LSI scsi hardware/drivers (was: upgrade from 9.3 fails with mirrored root)
Last modified: 2006-02-07 16:56:53 UTC
Installation of 9.3 with mirrored root (/ = /dev/md0) works fine. Upgrading to 10.0 by booting off boot CD works with no problems. Upgrading to 10.0 from within Yast2 works, but system panics on reboot. System can be booted off installation CD, but no amount of fiddling with GRUB settings will allow the system to boot directly off the hard drive. I booted off off of CD and modified the mkinitrd script and ran it to get more detailed output: ... + echo -n Waiting for device /dev/md0 to appear: Waiting for device /dev/md0 to appear: + [ 10 -gt 0 ] + [ -e /dev/md0 ] + echo ok ok + retval=0 + break + [ -n -a 0 -eq 1 ] + return 0 + /sbin/udevinfo -q path -n md0 no record for 'md0' in database + path= This seems to be the critical bit. udevinfo can't find an entry for /dev/md0, and blows the rest of the script. A new 10.0 install with mirrored root works fine, and the above command (/sbin/udevinfo -q path -n md0) produces proper results (/block/md0). Same with a new install of 9.3 (natch). Interestingly, on a fresh install of 10.0 with no mirrors, '/sbin/udevinfo -q path -n md0' gives the same "no record for 'md0' in database" error--even if /dev/md0 is created on the command line.
Just checked, and I get the same behavior with 10.1 alpha 3. That is, an update through Yast2 doesn't work (ends up with a panic), but the update from CD does work.
Did some more checking. The "no record for 'md0' in database" seems to be a red herring. Further comparison of a bad system to a good one reveals that on the bad system, raidautorun is detecting md0, but not assinging any physical partitions to it. GOOD: Loading reiserfs raidautorun ... md: Autodetecting RAID arrays. md: autorun ... md: considering sda2 ... md: adding sda2 ... md: adding sda1 ... md: created md0 md: bind<sda1> md0: WARNING: sda2 appears to be on the same physical disk as sda1. True protection against single-disk failure might be compromised. md: bind<sda2> md: running: <sda2><sda1> raid1: raid set md0 active with 2 out of 2 mirrors md: ... autorun DONE. done... BAD: Loading reiserfs raidautorun ... md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. done... FYI, all these tests have been done under VMware, using cloned copies of the same machine, so the update/upgrade is the only thing that's changing.
*** Bug 137053 has been marked as a duplicate of this bug. ***
OK, I've finally gotten the problem down to its bare essentials. The LSI SCSI ("fusion") driver changed in the 2.6.13 kernel. From http://lists.debian.org/debian-knoppix/2005/10/msg00054.html : The LSI Fusion driver (mptscsih, widely used, in particular VMware disks) has an added abstraction layer in 2.6.13. It now goes mptbase -> mptscsih -> (mptspi, mptlan, mptfc), for SCSI, LAN and Fiber Channel, respectively. ... linuxrc on the initrd will probably also need to be changed from "mptscsih" to "mptspi"... Taking a box that is broken (LSI SCSI, upgraded from 9.3 to 10.x via 'yast2 update'), and changing 'mptscsih' to 'mptspi' in /etc/sysconfig/kernel, then rerunning mkinitrd fixes the system. So, the final fix should be to have the yast2 'upgrade' module check for this kind of change and update /etc/sysconfig/kernel accordingly. (I have no idea how to figure out what changes to look for, outside of bug reports.) FWIW, I've checked the same setup (upgrading from 9.3 to 10.0 from 'yast2 update' with a mirrored root filesystem) with IDE and Buslogic SCSI drives, and they don't have this problem.
The next update kernel for 10.0 will contain a fix for this. Thanks.
Correction: it's going to be the second-next update; for the update scheduled for this week, it's already too late.