Red Hat Bugzilla – Bug 629789
dm-crypt system failed to boot after yum kernel upgrade
Last modified: 2011-06-28 09:30:50 EDT
Created attachment 442759 [details]
diff showing text-related changes between initramfs-126.96.36.199-85.fc13.i686.img and initramfs-188.8.131.52-47.fc13.i686.img
Description of problem:
I had a bit of a play. Using other Linux boot tools, I partitioned my laptop harddisk with 4 partitions: boot, swap and 2 others. On those 2 I separately encrypted them with cryptseup, then used mdadm to stripe them together as /dev/md0 (ie I'm trying to get around dm-crypt's lack of multi-core support)
Then I installed F13 by booting off DVD. I chose the "custom" disk option and told F13 to install onto the md0 device (it was beautiful - it auto-detected the encrypted partitions, I entered the passphrase, then detected they were striped - great job people!).
I really didn't expect it to work - but it did! I rebooted, entered my passphrase and it booted just fine. Several times in fact
Then I did a "yum update" and down came a new kernel (ie it was a virgin F13). I wondered what would happen, but as "the system" was working, I'd assume any initrd trickery would be copied via mkinitrd onto any newer kernel install.
I was wrong. After rebooting, it asked for the passphrase, hung for 10 seconds and said it couldn't find the root device.
Booting back into the previous kernel (thankfully yum doesn't remove them!) worked just fine
I then unpacked the working and non-working initrd (initramfs-184.108.40.206-85.fc13.i686.img and initramfs-220.127.116.11-47.fc13.i686.img) and diff'ed them
The only script-related differences I can see are in /etc/udev/rules.d/ (attached). Could some change in there have lead to my problem?
Thanks - it was soooo close! :-)
(In reply to comment #0)
> Thanks - it was soooo close! :-)
Now, if you replace the udev rules in the new one with the old ones, does it boot?
There are several updates, which play into the game.
- kernel update
- mdadm update
- dracut update
- udev update
one of the is clearly causing regression.
To test for the kernel, you would have to create the initramfs for the old kernel (in a new testimage!!), add a grub entry for the old kernel with the new initramfs.
To test for mdadm, you have to downgrade mdadm, create a new initramfs image and test with that. Same for dracut and udev.
Please, please, do the downgrade tests for me, to help me finding the bug.
I would do the tests in the following order:
- kernel test
- dracut downgrade
- udev downgrade
- mdadm downgrade
Sorry, but as we've just survived the Christchurch earthquake, I don't think I'm going to be able to spend quality time on this for a while
Hi there I'm back
So the situation is:
18.104.22.168-85.fc13.i686 - system boots off dm-crypto spanned HDD
22.214.171.124-47.fc13.i686 - system cannot access root device
I have now unpacked the initrd from 2.6.33 and created a new test initrd for 2.6.34 from that - with /lib/modules/2.6.34 instead of 2.6.33 - no other changes
That boots and appears to work just fine - so the issue is in userspace - not the kernel
Then I tried downgrading dracut. Not an option - there have been no updates - so that's not it
So I moved onto udev (I do see a yum syslog for an update to that) and downgraded - yum worked fine on that action. However, downgrading udev doesn't magically build a new initrd - so that really doesn't help by itself. I rebooted to confirm - the non-test 2.6.34 still can't boot. Thankfully my test image still worked.
I think I need to reboot into 2.6.33, uninstall 2.6.34 and reinstall it - thus picking up the older udev into the new initrd? I did that (made sure I got the same version I had before) and rebooted. End result: it worked!
So the problem is in udev - more specifically something between udev-151-9 and udev-153-3 changed, causing this problem
Hope that helps
you might want to try:
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '13'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 13's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 13 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.