Bug 629789 - dm-crypt system failed to boot after yum kernel upgrade
dm-crypt system failed to boot after yum kernel upgrade
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-09-02 20:27 EDT by Jason Haar
Modified: 2011-06-28 09:30 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-06-28 09:30:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
diff showing text-related changes between initramfs- and initramfs- (5.52 KB, text/plain)
2010-09-02 20:27 EDT, Jason Haar
no flags Details

  None (edit)
Description Jason Haar 2010-09-02 20:27:27 EDT
Created attachment 442759 [details]
diff showing text-related changes between initramfs- and initramfs-

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- and initramfs- 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! :-)

Comment 1 Harald Hoyer 2010-09-03 03:25:53 EDT
(In reply to comment #0)
> Thanks - it was soooo close! :-)
> Jason

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
Comment 2 Jason Haar 2010-09-05 21:24:31 EDT
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

Comment 3 Jason Haar 2010-09-12 18:39:29 EDT
Hi there I'm back

So the situation is: - system boots off dm-crypto spanned HDD - 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

Comment 4 Harald Hoyer 2010-09-22 08:23:14 EDT
you might want to try:
Comment 5 Bug Zapper 2011-05-31 10:38:14 EDT
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: 
Comment 6 Bug Zapper 2011-06-28 09:30:50 EDT
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.

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