Bug 152237

Summary:	Installation on LVM over software raid fails
Product:	[openSUSE] SUSE Linux 10.1	Reporter:	Clyde Kunkel <clydekunkel7734>
Component:	Basesystem	Assignee:	Hannes Reinecke <hare>
Status:	VERIFIED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Critical
Priority:	P5 - None	CC:	lgrimmer, lmb, nfbrown
Version:	Beta 4
Target Milestone:	---
Hardware:	i686
OS:	SuSE Linux 10.1
Whiteboard:
Found By:	Customer	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	yast logs fdisk -l and lvm configuration and lspci Initrd messages y2log tarball mkinitrd

Description Clyde Kunkel 2006-02-20 14:23:59 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.

Comment 1 Michael Gross 2006-02-20 14:35:58 UTC

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'.

Comment 2 Clyde Kunkel 2006-02-20 16:20:14 UTC

Created attachment 69360 [details]
yast logs

Yes, 1 occurs at the first stage of the installation and on each subsequent boot.

Comment 3 Clyde Kunkel 2006-02-20 16:21:18 UTC

Created attachment 69362 [details]
fdisk -l and lvm configuration and lspci

Here is the rest of the information requested.  Thanks for looking at this.

Comment 4 Michael Gross 2006-02-20 16:24:30 UTC

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.

Comment 5 Clyde Kunkel 2006-02-20 18:43:44 UTC

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.

Comment 6 Lenz Grimmer 2006-02-21 08:40:29 UTC

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.

Comment 7 Michael Gross 2006-02-21 14:58:06 UTC

Reassigning to the kernel maintainers.

Comment 8 Lars Marowsky-Bree 2006-02-21 16:05:59 UTC

Not a kernel bug, but initrd. Hannes, didn't you recently change the raid initialization on boot?

Comment 9 Clyde Kunkel 2006-02-27 16:07:52 UTC

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.

Comment 10 Hannes Reinecke 2006-02-28 09:12:28 UTC

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 :-).

Comment 11 Clyde Kunkel 2006-02-28 15:06:38 UTC

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?

Comment 12 Hannes Reinecke 2006-03-01 14:02:47 UTC

Created attachment 70799 [details]
mkinitrd

Updated /sbin/mkinitrd with update md handling.

Comment 13 Hannes Reinecke 2006-03-01 14:04:19 UTC

The above mkinitrd fixes the problem. Will be on the next beta.

Comment 14 Clyde Kunkel 2006-03-02 15:15:00 UTC

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.

Comment 15 Clyde Kunkel 2006-03-03 01:17:15 UTC

Got the time and can confirm that the mkinitrd in comment #12 solves the original reported problem.  Thanks.