Hide Forgot
Description of problem: I'm trying to get Fedora running on a new Vaio Z11X9E/B. It has two graphics chipsets - Intel and Nvidia with a switch to move between them. I put F13 on using the text mode installer and then yum-upgraded to F14 so as to have a newer kernel with the vga_switcheroo enabled. The root partition was LUKS-encrypted under F13. When I tried booting to the F14 kernel, there was a problem mounting the LUKS root partition, as shown in the attached screenshot. With the F13 kernel (after trying the F14 one), the LUKS password was no longer accepted. This isn't a big problem as I don't have anything significant saved on it yet. However, this would be a serious bug if it happened to someone upgrading normally. Version-Release number of selected component (if applicable): 2.6.35-rc6 kernel - can't tell exact version as the OS is now unbootable How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 435868 [details] Photo of error during boot
I have an F14 system with encrypted root (and swap and home) and it works.
Did you create the encrypted partition in F14? Mine was created in F13, before the upgrade.
No. I did a yum upgrade from F13 to rawhide and then later switched to the F14 branch.
If this issue also surfaces on fresh installed F14-Alpha systems, I believe it impacts the following Alpha release criteria [1]: The installer must be able to complete an installation using the entire disk, existing free space, or existing Linux partitions methods, with or without encryption enabled [1] https://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria
More aesni brokenness, I guess. Try adding "rdblacklist=aesni-intel" to the kernel command line.
With that addition the boot proceeds further. However, it can't find the root partition and so exits to an emergency shell (I'll attach a photo of this tomorrow).
Created attachment 437436 [details] Photo of kernel error
I experienced the same symptoms as in comments 7-8, i.e. a LUKS partition not being found, after today's update to latest updates-testing. Short version: solved it by updating the initramfs (i.e. running dracut --force). Long version: at first sight I noticed that the problem was caused by file "/lib/udev/rules.d/10-dm.rules" in device-mapper-1.02.53-4.fc13, and just overwriting that file with the previous version (device-mapper-1.02.44-1.fc13) fixed the issue. Finally I could boot with the latest version of that file after updating the initramfs. kernel-2.6.34.2-34.fc13 was installed in the same yum transaction, but before device-mapper, so I guess the initramfs needed an extra update. Maybe I should report this bug against device-mapper?
(In reply to comment #9) > I experienced the same symptoms as in comments 7-8, i.e. a LUKS partition not > being found, after today's update to latest updates-testing. > > Short version: solved it by updating the initramfs (i.e. running dracut > --force). > > Long version: at first sight I noticed that the problem was caused by file > "/lib/udev/rules.d/10-dm.rules" in device-mapper-1.02.53-4.fc13, and just > overwriting that file with the previous version (device-mapper-1.02.44-1.fc13) > fixed the issue. Finally I could boot with the latest version of that file > after updating the initramfs. kernel-2.6.34.2-34.fc13 was installed in the same > yum transaction, but before device-mapper, so I guess the initramfs needed an > extra update. Maybe I should report this bug against device-mapper? Yes, I'd report that. They may have their RPM requires wrong.
There's a fix for 10-dm.rules: http://sourceware.org/git/?p=lvm2.git;a=commit;h=f3645e3f4ba4d3c9b42eebd9a9db0b050ba9a03b The problem was in combining old dm udev rules in initramfs and new udev rules in the system itself. We need to include this one in the build...
I'm fairly sure this is resolved now, and it didn't seem like a kernel issue in the end anyway. Closing this out. Please open a new bug if similar issues are seen on f15 or newer.