Bugzilla – Bug 152237
Installation on LVM over software raid fails
Last modified: 2006-03-03 12:50:16 UTC
beta4 still does not install properly on LVM over software raid. Appears to be two problems, maybe not related. If needed, I can create separate bzs. During initrd following pertinent msgs written to boot console (hand transcribed): md: raid5 personality registered for level 5 md: raid4 personality registered for level 4 Loading dm-raid device-mapper: 4.5.0-ioctl (2005-10-04) initialized: dm-devel@redhat.com Loading DM snapshot Waiting for /dev/mapper/control to appear: ok Loading jbd Loading ext3 mdadm: Bad super-minor numbers: . Unable to find volume group "VolGroup1" Attempting manual resume md: md0 stopped At this point normal raid detection occurs on md0 and md1 which are raid5 and contain the LVs Then: md: personality for level 1 is not loaded and dropped to a shell. PROBLEM 1: Note that in the msgs above, an attempt was made to find the root device AFTER the raid startup failure, but BEFORE the raid startup recovery. After dropping into a shell, you can issue the VGCHANGE -a y VolGroup1 command that failed earlier, exit the shell and proceed with start-up. The initrd /etc/mdadm.conf was correctly formed and matchs root /etc/mdadm.conf: DEVICE /dev/sdc1 /dev/sdb1 /dev/sda1 /dev/sdd1 /dev/sdb2 /dev/sda2 /dev/sdb3 /dev/sda3 ARRAY /dev/md0 level=raid5 UUID=cd879c12:f5a85ca8:f5f2f808:03584f68 ARRAY /dev/md1 level=raid5 UUID=a5ea2e77:b74cc8e4:ce5b7933:ca532827 ARRAY /dev/md2 level=raid1 UUID=57d23615:7e6b6c41:2d282714:f1133734 PROBLEM 2: The system has a level 1 raid, md2, which was visible during installation in the partitioning phase, but no module was loaded by mkinitrd, nor was one needed then. After getting past the above problem, I added raid1 to INITRD_MODULES in /etc/sysconfig/kernel and ran mkinitrd. This fixed the level 1 not loaded problem, but did not fix the initial bad startup of the software raid sets. The md2 level 1 raidset is not needed during initial boot, but should be started after initrd during init.
I suppose (1) happens at the first stage of the installation? Anyway: Attach the YaST logfiles of the installation and add seperate information about your volume configuration as well as the output `fdisk -l'.
Created attachment 69360 [details] yast logs Yes, 1 occurs at the first stage of the installation and on each subsequent boot.
Created attachment 69362 [details] fdisk -l and lvm configuration and lspci Here is the rest of the information requested. Thanks for looking at this.
OK let's start with the assumption that there is a problem with the initrd. Clyde, please provide the kernel boot messages for the first stage of the installation.
Created attachment 69391 [details] Initrd messages Used a serial console to capture initrd msgs. Delineated the pertinent areas with lines of ****. Thanks for your attention.
Created attachment 69471 [details] y2log tarball I can confirm and reproduce this problem here - the system fails to boot from a logical volume on top of a RAID... See my YaST2 log files attached. Let me know, if you need additional info.
Reassigning to the kernel maintainers.
Not a kernel bug, but initrd. Hannes, didn't you recently change the raid initialization on boot?
I see that this is still NEW. Shouldn't it be ASSIGNED to someone--maybe "Hannes" in comment 8? Thanks. Looking forward to testing the next release.
I did some changes for mkinitrd, so it might be fixed. Not sure, though, whether it really is. Regarding the module loading issue: Currently mkinitrd does not attempt to include modules automatically but rather relies on the contents of /etc/sysconfig/kernel:INITRD_MODULES. And that should be updated by YaST. So make sure all required modules are listed there before rebooting :-).
Thanks for the reply. I updated /etc/sysconfig/kernel:INITRD_MODULES for he raid1 problem. Where can I get your updated mkinitrd to test? Will I have to wait for beta 5 or RC 1?
Created attachment 70799 [details] mkinitrd Updated /sbin/mkinitrd with update md handling.
The above mkinitrd fixes the problem. Will be on the next beta.
Tried to load 10.1b5 and too many problems to overcome in a quick manner. However, did see that the mkinitrd problem still existed. Could not get to the point to try the mkinitrd in comment #12. If have time, will try again this weekend, else wait for next release. Thanks for the attchement tho.
Got the time and can confirm that the mkinitrd in comment #12 solves the original reported problem. Thanks.