Bug 196828
| Summary: | Recent kernels do not generate dm for initrd images | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dwaine Garden <dwainegarden> |
| Component: | mkinitrd | Assignee: | Peter Jones <pjones> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | David Lawrence <dkl> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | grinnz, hdegoede, hoover, jeholden, jval, triage |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | bzcl34nup | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-05-07 00:34:06 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Dwaine Garden
2006-06-27 03:04:56 UTC
Is anyone looking at this bug? Dwaine 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? 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. 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 > 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).
*** Bug 229158 has been marked as a duplicate of this bug. *** *** Bug 229161 has been marked as a duplicate of this bug. *** 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? :) 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. This bug was addressed a long time ago. Updating to the latest dmraid resolved the issue. This bug should be closed. 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. Peter should this remain open or closed... see comment #10 and comment #11 ? 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 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. 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. |