http://bugzilla.novell.com/show_bug.cgi?id=586837 http://bugzilla.novell.com/show_bug.cgi?id=586837#c2 --- Comment #2 from Dennis Olsson <DOlsson@WEB.de> 2010-03-17 00:01:49 CET --- After having done some more debugging, it seems that there is also a problem with "mkinitrd". After having installed the packages, YaST issues a pop-up window with a count down to a reboot. During this reboot MD device does *not* get (re)activated, which then causes problems with the next stage of the installation process, while the disk setup is now screwed-up (in my case the LVM gets activated using "/dev/sdb3" instead of "/dev/md/raid1p3"!). But, instead of using the YaST "reboot", it does not help either to do a real reboot, while the MD device does *not* get activated during the running of the "initrd" either! The reason why the MD device does not get initialized during the running of the "initrd" is that the "md_dev" variable tested for in "boot/51-md.sh" has *not* been set, which means that "mdadm -A" does not get called! And thus does not assemble and starts the partitioned MD device. The "md_dev" variable is *only* getting set in either "boot/03-storage.sh" and here _only_ when the *root* device is a MD device (/dev/md*), i.e. when root is a MD device itself (which is not the case here -- see below), or "boot/51-md.sh" and here _only_ when the root device name consists of hexadecimal digits, i.e. (as far as I can deduce) when root is kept in a (MD) container. But, in this case, we have: /dev/sda + /dev/sdb => /dev/md/raid1 where /dev/md/raid1 has 3 (three) partitions: /dev/md/raid1p1 containing /boot file system /dev/md/raid1p2 containing swap device (used as resume device) /dev/md/raid1p3 containing LVM partition with volume group named "raid1" where the LVM volume group named "raid1" contains: /dev/raid1/root113 containing / file system In the used configuration (see comment #1) the "rootdev" is defined (in "/config/storage.sh") as "/dev/block/253:1" (device mapper minor 1), which has the consequence that the "md_dev" variable is being left empty, and thus not calling "mdadm -A". As I have not been able to figure out how "mkinitrd" determines how to setup these things, I cannot say what should be done for configurations like the one I am using. Instead, I stopped the YaST2 installation at the pop-up "reboot" countdown by clicking "Stop", switch to a text console, and made the following changes to the generated "initrd": config/md.sh (adding new line; only works, when doing "slow_boot=on"): md_dev="/dev/md/raid1" run_all.sh (added after line with "root_md"; only works, when doing "fast boot"): md_dev="/dev/md/raid1" etc/mdadm.conf (changed existing line to these two lines instead): ARRAY /dev/md/raid1 metadata=1.00 name=raid1 UUID=<value from existing file> HOMEHOST Loke Returning to the YaST console and clicking "OK" will *not* work, while for reasons I do not understand the MD device does _not_ get activated, resulting in LVM getting very confused about finding the volume group "raid1" twice on "/dev/sdb3" as well as "/dev/sda3", choicing "/dev/sdb3" over "/dev/sda3". It should not have - of course - seen the "/dev/sd*" partitions at all, but instead the "/dev/md/raid1p3" alias "/dev/md127p3" and have used this one instead. So, instead, after having replaced the "initrd" with the changes from above incorporated, I *rebooted* the system by issueing: vgchange -a n mdadm --stop /dev/md/raid1 reboot But, also here LVM gets confused -- this time, though, the MD device *does* get started, but the LVM activation still sees the "/dev/sdb3" and "/dev/md/raid1" and prefers "/dev/sdb3" over "/dev/md/raid1" (which, of course, should really have been "/dev/md/raid1p3"!). The reason for this confusion is that the MD activation only activates one device (here "/dev/sda"), but not the other device (here "/dev/sdb"), which is (also) part of the MD device! But, why not?? I have not been able to figure that one out... In any instances, the installation cannot be continued, while the root file system has a completely wrong setup, eventual corrupting it beyond repair. It seems that the changes made by Arvin Schnell to implement feature #305883 still needs a few fixes in YaST as well as "mkinitrd", before it works correctly. ;-) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.