Bug 620202 - LUKS partition unreadable under F14 kernel
Summary: LUKS partition unreadable under F14 kernel
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 14
Hardware: All Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-01 14:25 UTC by Adam Huffman
Modified: 2011-08-26 19:21 UTC (History)
11 users (show)

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: ---


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

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.


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