Bug 620202 - LUKS partition unreadable under F14 kernel
LUKS partition unreadable under F14 kernel
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-01 10:25 EDT by Adam Huffman
Modified: 2011-08-26 15:21 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-26 15:21:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Photo of error during boot (1.54 MB, image/jpeg)
2010-08-01 10:26 EDT, Adam Huffman
no flags Details
Photo of kernel error (2.60 MB, image/jpeg)
2010-08-08 08:49 EDT, Adam Huffman
no flags Details

  None (edit)
Description Adam Huffman 2010-08-01 10:25:04 EDT
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 10:26:19 EDT
Created attachment 435868 [details]
Photo of error during boot
Comment 2 Bruno Wolff III 2010-08-01 10:49:54 EDT
I have an F14 system with encrypted root (and swap and home) and it works.
Comment 3 Adam Huffman 2010-08-01 11:00:04 EDT
Did you create the encrypted partition in F14?  Mine was created in F13, before the upgrade.
Comment 4 Bruno Wolff III 2010-08-01 11:12:06 EDT
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 09:53:04 EDT
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 15:04:26 EDT
More aesni brokenness, I guess. Try adding "rdblacklist=aesni-intel" to the kernel command line.
Comment 7 Adam Huffman 2010-08-02 19:14:30 EDT
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 08:49:36 EDT
Created attachment 437436 [details]
Photo of kernel error
Comment 9 Maximiliano Bertacchini 2010-08-09 14:40:48 EDT
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-09 22:35:29 EDT
(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 12:13:38 EDT
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 15:21:34 EDT
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.

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