Bug 196828 - Recent kernels do not generate dm for initrd images
Recent kernels do not generate dm for initrd images
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
rawhide
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Peter Jones
David Lawrence
bzcl34nup
:
: 229158 229161 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-26 23:04 EDT by Dwaine Garden
Modified: 2008-08-02 19:40 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:34:06 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)

  None (edit)
Description Dwaine Garden 2006-06-26 23:04:56 EDT
Description of problem:
The dm lines are missing on all the initrd images that get generated when you
update with yum.   The dmraid stuff stopped getting added to the initrd images
when the PAE kernels started coming out.

The machine is unable to boot the kernel.

Version-Release number of selected component (if applicable):


How reproducible:
Update a rawhide installation with a PAE kernel.  All the older smp kernels
where fine.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
Bad.........  PAE kernels.

#!/bin/nash

mount -t proc /proc /proc
setquiet
echo Mounting proc filesystem
echo Mounting sysfs filesystem
mount -t sysfs /sys /sys
echo Creating /dev
mount -o mode=0755 -t tmpfs /dev /dev
mkdir /dev/pts
mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts
mkdir /dev/shm
mkdir /dev/mapper
echo Creating initial device nodes
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mknod /dev/systty c 4 0
mknod /dev/tty c 5 0
mknod /dev/console c 5 1
mknod /dev/ptmx c 5 2
mknod /dev/rtc c 10 135
mknod /dev/tty0 c 4 0
mknod /dev/tty1 c 4 1
mknod /dev/tty2 c 4 2
mknod /dev/tty3 c 4 3
mknod /dev/tty4 c 4 4
mknod /dev/tty5 c 4 5
mknod /dev/tty6 c 4 6
mknod /dev/tty7 c 4 7
mknod /dev/tty8 c 4 8
mknod /dev/tty9 c 4 9
mknod /dev/tty10 c 4 10
mknod /dev/tty11 c 4 11
mknod /dev/tty12 c 4 12
mknod /dev/ttyS0 c 4 64
mknod /dev/ttyS1 c 4 65
mknod /dev/ttyS2 c 4 66
mknod /dev/ttyS3 c 4 67
echo Setting up hotplug.
hotplug
echo Creating block device nodes.
mkblkdevs
echo "Loading scsi_mod.ko module"
insmod /lib/scsi_mod.ko
echo "Loading sd_mod.ko module"
insmod /lib/sd_mod.ko
echo "Loading libata.ko module"
insmod /lib/libata.ko
echo "Loading sata_via.ko module"
insmod /lib/sata_via.ko
echo "Loading jbd.ko module"
insmod /lib/jbd.ko
echo "Loading ext3.ko module"
insmod /lib/ext3.ko
echo "Loading dm-mod.ko module"
insmod /lib/dm-mod.ko
echo "Loading dm-mirror.ko module"
insmod /lib/dm-mirror.ko
echo "Loading dm-zero.ko module"
insmod /lib/dm-zero.ko
echo "Loading dm-snapshot.ko module"
insmod /lib/dm-snapshot.ko
echo Making device-mapper control node
mkdmnod
echo Attaching to iSCSI storage
mkblkdevs
echo Scanning logical volumes
lvm vgscan --ignorelockingfailure
echo Activating logical volumes
lvm vgchange -ay --ignorelockingfailure  VolGroup00
resume /dev/VolGroup00/LogVol01
echo Creating root device.
mkrootdev -t ext3 -o defaults,ro /dev/VolGroup00/LogVol00
echo Mounting root filesystem.
mount /sysroot
echo Setting up other filesystems.
setuproot
echo Switching to new root and running init.
switchroot

Expected results:
Here is a good copy of a initrid script.

Good....

#!/bin/nash

mount -t proc /proc /proc
setquiet
echo Mounting proc filesystem
echo Mounting sysfs filesystem
mount -t sysfs /sys /sys
echo Creating /dev
mount -o mode=0755 -t tmpfs /dev /dev
mkdir /dev/pts
mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts
mkdir /dev/shm
mkdir /dev/mapper
echo Creating initial device nodes
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mknod /dev/systty c 4 0
mknod /dev/tty c 5 0
mknod /dev/console c 5 1
mknod /dev/ptmx c 5 2
mknod /dev/rtc c 10 135
mknod /dev/tty0 c 4 0
mknod /dev/tty1 c 4 1
mknod /dev/tty2 c 4 2
mknod /dev/tty3 c 4 3
mknod /dev/tty4 c 4 4
mknod /dev/tty5 c 4 5
mknod /dev/tty6 c 4 6
mknod /dev/tty7 c 4 7
mknod /dev/tty8 c 4 8
mknod /dev/tty9 c 4 9
mknod /dev/tty10 c 4 10
mknod /dev/tty11 c 4 11
mknod /dev/tty12 c 4 12
mknod /dev/ttyS0 c 4 64
mknod /dev/ttyS1 c 4 65
mknod /dev/ttyS2 c 4 66
mknod /dev/ttyS3 c 4 67
echo Setting up hotplug.
hotplug
echo Creating block device nodes.
mkblkdevs
echo "Loading scsi_mod.ko module"
insmod /lib/scsi_mod.ko
echo "Loading sd_mod.ko module"
insmod /lib/sd_mod.ko
echo "Loading libata.ko module"
insmod /lib/libata.ko
echo "Loading sata_via.ko module"
insmod /lib/sata_via.ko
echo "Loading jbd.ko module"
insmod /lib/jbd.ko
echo "Loading ext3.ko module"
insmod /lib/ext3.ko
echo "Loading dm-mod.ko module"
insmod /lib/dm-mod.ko
echo "Loading dm-mirror.ko module"
insmod /lib/dm-mirror.ko
echo "Loading dm-zero.ko module"
insmod /lib/dm-zero.ko
echo "Loading dm-snapshot.ko module"
insmod /lib/dm-snapshot.ko
echo Making device-mapper control node
mkdmnod
mkblkdevs
rmparts sdb
rmparts sda
dm create via_ecfdfiehfa 0 312499998 striped 2 128 8:0 0 8:16 0
dm partadd via_ecfdfiehfa
echo Scanning logical volumes
lvm vgscan --ignorelockingfailure
echo Activating logical volumes
lvm vgchange -ay --ignorelockingfailure  VolGroup00
resume /dev/VolGroup00/LogVol01
echo Creating root device.
mkrootdev -t ext3 -o defaults,ro /dev/VolGroup00/LogVol00
echo Mounting root filesystem.
mount /sysroot
echo Setting up other filesystems.
setuproot
echo Switching to new root and running init.
switchroot

Additional info:
Here is the output of mkinitrd -v -f /tmp/foo.img $(uname -r) 

Creating initramfs
Looking for deps of module sata_via: libata scsi_mod
Looking for deps of module libata: scsi_mod
Looking for deps of module scsi_mod
Looking for deps of module sd_mod: scsi_mod
Looking for deps of module ide-disk
Looking for deps of module ext3: jbd
Looking for deps of module jbd
Looking for driver for device mapper/via_ecfdfiehfap2
Looking for deps of module dm-mod
Looking for deps of module dm-mirror: dm-mod
Looking for deps of module dm-zero: dm-mod
Looking for deps of module dm-snapshot: dm-mod
Using modules: /lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/scsi/scsi_mod.ko
/lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/scsi/sd_mod.ko
/lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/scsi/libata.ko
/lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/scsi/sata_via.ko 
/lib/modules/2.6.17-1.2307_FC6PAE/kernel/fs/jbd/jbd.ko
/lib/modules/2.6.17-1.2307_FC6PAE/kernel/fs/ext3/ext3.ko
/lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/md/dm-mod.ko
/lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/md/dm-mirror.ko
/lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/md/dm-zero.ko
/lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/md/dm-snapshot.ko
/sbin/nash -> /tmp/initrd.qW9233/bin/nash
/sbin/insmod.static -> /tmp/initrd.qW9233/bin/insmod
copy from `/lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/scsi/scsi_mod.ko'
[elf32-i386] to `/tmp/initrd.qW9233/lib/scsi_mod.ko' [elf32-i386]
copy from `/lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/scsi/sd_mod.ko'
[elf32-i386] to `/tmp/initrd.qW9233/lib/sd_mod.ko' [elf32-i386]
copy from `/lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/scsi/libata.ko'
[elf32-i386] to `/tmp/initrd.qW9233/lib/libata.ko' [elf32-i386]
copy from `/lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/scsi/sata_via.ko'
[elf32-i386] to `/tmp/initrd.qW9233/lib/sata_via.ko' [elf32-i386]
copy from `/lib/modules/2.6.17-1.2307_FC6PAE/kernel/fs/jbd/jbd.ko' [elf32-i386]
to `/tmp/initrd.qW9233/lib/jbd.ko' [elf32-i386]
copy from `/lib/modules/2.6.17-1.2307_FC6PAE/kernel/fs/ext3/ext3.ko'
[elf32-i386] to `/tmp/initrd.qW9233/lib/ext3.ko' [elf32-i386]
copy from `/lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/md/dm-mod.ko'
[elf32-i386] to `/tmp/initrd.qW9233/lib/dm-mod.ko' [elf32-i386]
copy from `/lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/md/dm-mirror.ko'
[elf32-i386] to `/tmp/initrd.qW9233/lib/dm-mirror.ko' [elf32-i386]
copy from `/lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/md/dm-zero.ko'
[elf32-i386] to `/tmp/initrd.qW9233/lib/dm-zero.ko' [elf32-i386]
copy from `/lib/modules/2.6.17-1.2307_FC6PAE/kernel/drivers/md/dm-snapshot.ko'
[elf32-i386] to `/tmp/initrd.qW9233/lib/dm-snapshot.ko' [elf32-i386]
/sbin/lvm.static -> /tmp/initrd.qW9233/bin/lvm
/etc/lvm -> /tmp/initrd.qW9233/etc/lvm
`/etc/lvm/lvm.conf' -> `/tmp/initrd.qW9233/etc/lvm/lvm.conf'
Adding module scsi_mod
Adding module sd_mod
Adding module libata
Adding module sata_via
Adding module jbd
Adding module ext3
Adding module dm-mod
Adding module dm-mirror
Adding module dm-zero
Adding module dm-snapshot
Comment 1 Dwaine Garden 2006-07-16 00:01:18 EDT
Is anyone looking at this bug?

Dwaine
Comment 2 Jack Holden 2006-07-22 20:14:03 EDT
I have this problem too.  I installed FC5 on my system:
  ASUS A8N32-SLI Deluxe MB
  AMD FX-60 (dual core AMD 64) CPU
  2 x nVidia 7800 GTX 512 (SLI)
  Creative Labs Sound Blaster X-Fi Fatal1ty (not supported)
  2 x WD Raptor 10k rpm 150 GB (nVRAID 0)

The kernel that is installed during set-up works fine.  However, when I upgrade
to the latest kernel (2.6.17-1.2157) using yum or yumex, the init script in the
initrd does not set up the raid array.  It loads the modules, but it doesn't
perform these steps:
  rmparts sdb
  rmparts sda
  dm create nvidia_xxxxxxx 0 586093312 striped 2 128 8:0 0 8:16 0
  dm partadd nvidia_xxxxxxx

I don't remember the actual name given to the array...

Initially, I copied the corresponding lines from the init stript in the
installed initrd.  This generated the "stripe size not a multiple of chunk size"
error.  I did the math and corrected the problem  (I think).  Now I get the
following error upon boot:

init[1] trap divide error rip:4296d7 rsp:7fff23c9d070 error:0

I have no idea:
  1) why yum didn't generate the proper init script in the initrd
  2) whether or not I corrected the chunk size problem properly
  3) what the current error means
  3) how to proceed

Can anyone help?
Comment 3 Hans de Goede 2006-08-19 14:32:13 EDT
The adding of the nescesarry dm lines, like these:
rmparts sdb
rmparts sda
dm create nvidia_dabhfihh 0 976562432 striped 2 128 8:0 0 8:16 0
dm partadd nvidia_dabhfihh
is done correctly by rescent mkinitrd versions. However there is a bug in nash
where it doesn't create the nescesarry /dev/dm-x nodes. I've submitted a
seperate bug for this see bug 203241, which includes a patch fixing this.

Since the problem reported here (the generating of the nescesarry dm lines) is
fixed, this bug can be closed afaik.
Comment 4 Dwaine Garden 2006-08-22 23:08:07 EDT
Good news.  Just syncd with rawhide and the new kernel booted with dm raid0
without any modifications.

I'm using the via_sata driver.

Dwaine
Comment 5 Jarkko 2007-02-25 06:04:44 EST
> The adding of the nescesarry dm lines
> is done correctly by rescent mkinitrd versions.

I'm sorry to inform you that kernels > 2.6.19-1.2914.fc7 have this bug (dm lines
are _not_ added). Also kernel-xen-2.6.19-1.2898.2.3.fc7 has this. The dm related
devices are missing from /dev/mapper/ after booting with a buggy initrd.

Here's a diff between  initrd-2.6.19-1.2914.fc7/init (working one) and
initrd-2.6.20-1.2942.fc7/init (non-working one):

--- initrd-2.6.19-1.2914.fc7/init       2007-02-24 22:19:23.000000000 +0200
+++ initrd-2.6.20-1.2942.fc7/init       2007-02-24 22:19:43.000000000 +0200
@@ -76,10 +76,7 @@
 echo "Loading dm-snapshot.ko module"
 insmod /lib/dm-snapshot.ko
 mkblkdevs
-rmparts sdb
-rmparts sda
-dm create ddf1_4c534920202020201000005500000000330a535300000a28 0 974608384
mirror core 2 131072 nosync 2 8:0 0 8:16 0
-dm partadd ddf1_4c534920202020201000005500000000330a535300000a28
+resume LABEL=swap
 echo Creating root device.
 mkrootdev -t ext3 -o defaults,ro dm-2
 echo Mounting root filesystem.

I added those missing lines manually to initrd-2.6.19-1.2898.2.3.fc7xen.img and
managed to get kernel-xen-2.6.19-1.2898.2.3.fc7 working properly.

So, as I said: dm related lines are missing from initrd "init" scripts after
running mkinitrd with kernel-2.6.20-1.2932.fc7 up to kernel-2.6.20-1.2942.fc7
(that's the latest kernel at the moment in the development repository). Also
kernel-xen-2.6.19-1.2898.2.3.fc7 has this bug (it was kernel-xen's initrd which
I manually managed to get working).
Comment 6 Jarkko 2007-02-25 06:08:15 EST
*** Bug 229158 has been marked as a duplicate of this bug. ***
Comment 7 Jarkko 2007-02-25 06:11:35 EST
*** Bug 229161 has been marked as a duplicate of this bug. ***
Comment 8 Jarkko 2007-10-16 04:22:39 EDT
Just a reminder that this issue is still valid. ;)

I still need to add those four lines manually to initrd-*/init every time there
has been a kernel update.

I'm using F7 x86_64, so the Hardware field in this bug should actually be "All"
(I wasn't allowed to change that). I assume this will also happen in F8 (so
Version as "devel" is justified) because there has not been any activity in this
bug. The version of mkinitrd in the F7 host: mkinitrd-6.0.9-7.1

Do you know why this happens at least? :)
Comment 9 Bug Zapper 2008-04-03 13:30:42 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 10 Dwaine Garden 2008-04-03 20:13:39 EDT
This bug was addressed a long time ago.  Updating to the latest dmraid resolved
the issue.  This bug should be closed.
Comment 11 Jarkko 2008-04-04 03:56:12 EDT
dmraid-1.0.0.rc14-4.fc7 does not help and based on that I guess
dmraid-1.0.0.rc14-4.fc8 doesn't either.

I still need to add those four lines manually to initrd-*/init every time there
has been a kernel update.

Development seems to have dmraid-1.0.0.rc14-6.fc9. Are you saying, that updating
from rpm release 4 to 6 will fix this issue? I'm really sceptical, because the
actual package version is not newer in the development repository.
Comment 12 John Poelstra 2008-05-05 21:53:28 EDT
Peter should this remain open or closed... see comment #10 and comment #11 ?
Comment 13 Bug Zapper 2008-05-06 20:34:03 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp
Comment 14 Jarkko 2008-05-07 02:37:03 EDT
My server is F7 x86_64. It runs (as Domain-0): kernel-xen-2.6.21-7.fc7.x86_64

I updated it to dmraid-1.0.0.rc14-6.fc7.x86_64 from updates-testing. The latest
dmraid is 1.0.0.rc14-6.fc9, so that is the latest dmraid. It's just build for
F7, but it's exactly the same version.

Still missing these lines from initrd image after mkinitrd:

rmparts sdb
rmparts sda
dm create ddf1_4c534920202020201000005500000000330a535300000a28 0 974608384
mirror core 2 131072 nosync 2 8:0 0 8:16 0
dm partadd ddf1_4c534920202020201000005500000000330a535300000a28

--> This bug is not fixed. Or if it is, updating to the latest dmraid doesn't
resolve the issue.

Do I need newer mkinitrd? I'm running mkinitrd-6.0.9-7.1 and rawhide has
mkinitrd-6.0.52-1.fc9 - F8 has mkinitrd-6.0.19-4.fc8.
Comment 15 Jarkko 2008-05-07 14:03:55 EDT
mkinitrd-6.0.15-1 has a changelog comment: "Fix dmraid on x86_64."

Perhaps that version and up works? Unfortunately I can't update to that version
on the F7 host and actually test that - too many failed dependencies.

But if you can confirm that indeed that version fixed this bug, then you can
change the resolution to RAWHIDE and say this bug is really fixed.

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