Created attachment 442759 [details] diff showing text-related changes between initramfs-2.6.33.3-85.fc13.i686.img and initramfs-2.6.34.6-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-2.6.33.3-85.fc13.i686.img and initramfs-2.6.34.6-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! :-) Jason
(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
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 Jason
Hi there I'm back So the situation is: 2.6.33.3-85.fc13.i686 - system boots off dm-crypto spanned HDD 2.6.34.6-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 Jason
you might want to try: https://admin.fedoraproject.org/updates/udev-153-4.fc13
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.