Bug 137053 - upgrade from 9.3 fails with mirrored root
Summary: upgrade from 9.3 fails with mirrored root
Status: RESOLVED DUPLICATE of bug 137062
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Update Problems (show other bugs)
Version: unspecified
Hardware: i586 Other
: P5 - None : Major
Target Milestone: ---
Assignee: E-mail List
QA Contact: Klaus Kämpf
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-05 22:13 UTC by Paul Archer
Modified: 2005-12-07 10:31 UTC (History)
0 users

See Also:
Found By: Customer
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Archer 2005-12-05 22:13:55 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.
Comment 1 Danny Al-Gaaf 2005-12-07 10:31:06 UTC

*** This bug has been marked as a duplicate of 137062 ***