Bug 620202

Summary: LUKS partition unreadable under F14 kernel
Product: [Fedora] Fedora Reporter: Adam Huffman <bloch>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: anton, bruno, dougsland, gansalmon, itamar, jlaska, jonathan, kernel-maint, madhu.chinakonda, maxiberta, prajnoha
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-08-26 19:21:34 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:
Attachments:
Description Flags
Photo of error during boot
none
Photo of kernel error none

Description Adam Huffman 2010-08-01 14:25:04 UTC 
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:
Comment 1 Adam Huffman 2010-08-01 14:26:19 UTC 
Created attachment 435868 [details]
Photo of error during boot
Comment 2 Bruno Wolff III 2010-08-01 14:49:54 UTC 
I have an F14 system with encrypted root (and swap and home) and it works.
Comment 3 Adam Huffman 2010-08-01 15:00:04 UTC 
Did you create the encrypted partition in F14?  Mine was created in F13, before the upgrade.
Comment 4 Bruno Wolff III 2010-08-01 15:12:06 UTC 
No. I did a yum upgrade from F13 to rawhide and then later switched to the F14 branch.
Comment 5 James Laska 2010-08-02 13:53:04 UTC 
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
Comment 6 Chuck Ebbert 2010-08-02 19:04:26 UTC 
More aesni brokenness, I guess. Try adding "rdblacklist=aesni-intel" to the kernel command line.
Comment 7 Adam Huffman 2010-08-02 23:14:30 UTC 
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).
Comment 8 Adam Huffman 2010-08-08 12:49:36 UTC 
Created attachment 437436 [details]
Photo of kernel error
Comment 9 Maximiliano Bertacchini 2010-08-09 18:40:48 UTC 
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?
Comment 10 Chuck Ebbert 2010-08-10 02:35:29 UTC 
(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.
Comment 11 Peter Rajnoha 2010-08-12 16:13:38 UTC 
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...
Comment 12 Josh Boyer 2011-08-26 19:21:34 UTC 
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.