This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 501135 - mkinitrd fails to include RAID module for swap array
mkinitrd fails to include RAID module for swap array
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-16 18:19 EDT by Jason Tibbitts
Modified: 2009-05-21 22:04 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-18 11:09:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of mkinitrd -v (8.77 KB, text/plain)
2009-05-16 18:19 EDT, Jason Tibbitts
no flags Details
Fixed mkinitrd script (43.99 KB, text/plain)
2009-05-17 14:19 EDT, Hans de Goede
no flags Details

  None (edit)
Description Jason Tibbitts 2009-05-16 18:19:15 EDT
Created attachment 344299 [details]
Output of mkinitrd -v

For whatever reason, on a software RAID machine I've always made a RAID1 array and stuck swap on it:

part raid.10 --asprimary --ondisk=sda --size=32768
part raid.11 --asprimary --ondisk=sdb --size=32768
part raid.12 --asprimary --ondisk=sdc --size=32768
part raid.13 --asprimary --ondisk=sdd --size=32768
raid swap --level=1 --device=md1 raid.10 raid.11 raid.12 raid.13

With rawhide, anaconda sets up the swap device just fine but at boot time it can't be activated:

md: md1 stopped.
md: bind<sdb2>
md: bind<sdc2>
md: bind<sdd2>
md: bind<sda2>
md: md1: raid array is not clean -- starting background reconstruction
md: personality for level 1 is not loaded!

I unpacked the generated initrd and indeed it is missing the raid1 module.  It includes the raid10 module needed to mount the LVM that holds root on this machine, however, so the system still boots, just without swap.  If I do
  mdadm --run /dev/md1; swapon -a
after boot then swap comes online just fine.

If I manually run
  mkinitrd -v -f /boot/initrd-2.6.29.3-140.fc11.x86_64.img 2.6.29.3-140.fc11.x86_64
I get:

Creating initramfs
Looking for driver for /dev/mapper/vg0-root in /sys/block/dm-3
Found DeviceMapper component dm-3
Found MDRAID component md2
Looking for deps of module scsi:t-0x00
Looking for deps of module pci:v00008086d00002681sv000015D9sd00008380bc01sc06i01
Looking for deps of module scsi:t-0x00
Looking for deps of module pci:v00008086d00002681sv000015D9sd00008380bc01sc06i01
Looking for deps of module scsi:t-0x00
Looking for deps of module pci:v00008086d00002681sv000015D9sd00008380bc01sc06i01
Looking for deps of module scsi:t-0x00
Looking for deps of module pci:v00008086d00002681sv000015D9sd00008380bc01sc06i01
Looking for driver for /dev/md1 in /sys/block/md1
Found MDRAID component md1
Using modules:  raid10
Building initrd in /tmp/initrd.wf8e9m

I tried passing --with=raid1 and --with=raid1.ko but I couldn't seem to get mkinitrd to include the raid1 module into the initrd.  Ahh, but --with=md-raid1 seems to have worked, and the resulting initrd brings up the swap device without problems.
Comment 1 Hans de Goede 2009-05-17 04:00:01 EDT
Can you paste the contents of /proc/mdstat here please, and what does:
awk "/^md1[  ]*:/ { print\$4 }" /proc/mdstat

Give as output ?
Comment 2 Jason Tibbitts 2009-05-17 12:08:42 EDT
Here's /proc/mdstat on the system with the raid1 module in the initrd, which is also what anaconda sets up before the initial reboot:

Personalities : [raid10] [raid1]
md0 : active raid1 sda3[0] sdd3[3] sdc3[2] sdb3[1]
      262080 blocks [4/4] [UUUU]

md1 : active raid1 sda2[0] sdd2[3] sdc2[2] sdb2[1]
      33554368 blocks [4/4] [UUUU]

md2 : active raid10 sda1[0] sdd1[3] sdc1[2] sdb1[1]
      1885886720 blocks 64K chunks 2 near-copies [4/4] [UUUU]

unused devices: <none>

The command you provided gives "raid1".

The bad /proc/mdstat, from the machine booted with the default initrd that mkinitrd will set up which does not have the raid1 module:

Personalities : [raid10] [raid1]
md0 : active raid1 sda3[0] sdd3[3] sdc3[2] sdb3[1]
      262080 blocks [4/4] [UUUU]

md1 : inactive sda2[0] sdd2[3] sdc2[2] sdb2[1]
      134217472 blocks

md2 : active raid10 sda1[0] sdd1[3] sdc1[2] sdb1[1]
      1885886720 blocks 64K chunks 2 near-copies [4/4] [UUUU]

unused devices: <none>

The awk command produces "sda2[0]" in that case.  (I filed bug 500754 a few days ago for that parsing error.)

Please also note that even if I boot a system with the raid1 module in the initrd so that the array comes up active, mkinitrd will still generate an initrd that does not have the proper module.
Comment 3 Hans de Goede 2009-05-17 14:19:00 EDT
Created attachment 344343 [details]
Fixed mkinitrd script

Ah, we had a =~ compare in there for not loading the same module twice,
so once it had raid10 it would wrongly think it also has raid1.

Can you give this version a try on a system which had md1 up and running please?
Comment 4 Jason Tibbitts 2009-05-17 14:40:09 EDT
Yes, that works; thanks.

./mkinitrd -v -f /boot/initrd-2.6.29.3-140.fc11.x86_64.img 2.6.29.3-140.fc11.x86_64
[...]
Looking for driver for /dev/md1 in /sys/block/md1
Found MDRAID component md1
Using modules:  raid10 raid1

and the resulting initrd boots fine and properly activates all of the arrays.
Comment 5 Hans de Goede 2009-05-18 11:09:02 EDT
(In reply to comment #4)
> Yes, that works; thanks.
> 

Ok, thanks for testing, the fix in the attached mkinitrd has been commited to
mkinitrd's git tree:
http://git.fedorahosted.org/git/?p=mkinitrd;a=commitdiff;h=3ee7edafb764be37428ab0defb0df62c62fad265

And thus will be part of the next mkinitrd release (6.0.84-1), not sure if
that will make F-11 final though.
Comment 6 Warren Togami 2009-05-18 20:06:56 EDT
[warren@newcaprica ~]$ koji latest-pkg f11-final mkinitrd
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
mkinitrd-6.0.84-1.fc11                    f11-final             pjones

6.0.84-1 is already in F11 as of 4 days ago.  Is this the version that fixes this issue?
Comment 7 Jason Tibbitts 2009-05-18 20:22:24 EDT
I can verify that mkinitrd-6.0.84-1.fc11 has this problem; it was the original version I tested.  However, I'm confused as to the versioning of mkinitrd.  The git log shows that it was just bumped to 6.0.84 today, yet the package having that version was built by pjones four days ago.  Perhaps the package version was updated but the actual source version wasn't?
Comment 8 Jason Tibbitts 2009-05-18 20:26:22 EDT
Maybe I just don't understand git:

Bump version to 6.0.84

author	Peter Jones <pjones@redhat.com>
	 Thu, 14 May 2009 18:51:23 +0000 (14:51 -0400)
committer	Peter Jones <pjones@pjones4.install.bos.redhat.com>
	 Mon, 18 May 2009 21:50:42 +0000 (17:50 -0400)
commit	827481b8ace83cde4fdc626b9eef09256bd68f5a

So the version was bumped, the tarball was made and the new package was built on the 14th, but the update wasn't committed to the tree until the 18th?
Comment 9 Hans de Goede 2009-05-19 03:04:39 EDT
I think pjones did a 6.0.84 in his local git tree, and did a Fedora build from that, but then did not push that to git, causing me to state the version with
the fix in would be 6.0.84. I stand corrected, the version with the fix in will be 6.0.85.
Comment 10 Jason Tibbitts 2009-05-21 22:04:47 EDT
I can verify that this is fixed in today's rawhide (which has mkinitrd-6.0.85).

Note You need to log in before you can comment on or make changes to this bug.