Bug 474710

Summary: LUKS will not mount if System Hardware profile has changed.
Product: [Fedora] Fedora Reporter: Q5sys <SrAPennington>
Component: mkinitrdAssignee: Peter Jones <pjones>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: agk, dcantrell, dwysocha, hdegoede, lsof, lvm-team, mbroz, opensource, pjones, prockai, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-12-18 07:10:01 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:

Description Q5sys 2008-12-04 22:43:43 UTC
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.4) Gecko/2008111217 Fedora/3.0.4-1.fc10 Firefox/3.0.4

I use a Lenovo Y510 Laptop.  I swap several SATA drives into the chassis.  I installed F10 to a 8GB USB Drive.  So that no matter what drive I have in my system I can boot into Fedora.  I am using LUKS to encrypt the partition on the USB Drive. My problem is that whatever HD was in the system when I installed to the USB Drive, has to be present or I cannot boot Fedora.  For example, if I installed F10 to my USB with my 250gb HD in the system, I can ONLY boot into Fedora (through Post Bios selection) with the 250gb drive.  If I put my 320gb and try to boot to the USB, It will not mount the encrypted volume on my USB Drive.  The same applies if I install to my USB drive with the 320gb hd in my laptop.  Furthermore, If I install F10 to my USB drive with NO drive in the system, I can only boot into F10 sucessfully if I do not have a drive isntalled in my system.  If I try to install with any drive attached, I will get a mount error for my LVM on the USB Drive.

Reproducible: Always

Steps to Reproduce:
1.Install F10 to USB drive with HD "A" in chassis
2.Replace HD "A" with any other HD.
3.Try to Boot into F10 from USB drive through Bios Boot order override.
Actual Results:  
If I try to boot into F10 on my USB Drive with any difference in internal hardware, regardless of typing my password correctly so it can decrypt the encrypted volume.  System will not boot, and will return Boot error.

Expected Results:  
Since I am booting from a USB drive, there should be no affect from the hardware (internal HD) on the machine I am using. The internal HD inside my laptop should not have bearing on being able to mount the volume in my USB drive, since I am trying to boot from the USB drive.
Due to this error, I can only access F10 from this system and only with a certian internal drive.  I am restricted from using this F10 install on any other computer as well as not being able to run F10 and access the files on my other internal drives. (being a laptop I can only use one internal drive at a time)


Im unsure if my component selection above is correct.  It was the only thing I could find that seemed close.

Comment 1 Till Maas 2008-12-05 09:48:19 UTC
I guess the problem is, that mkinitrd uses /dev/sd* in the initramfs file with cryptsetup. You can check this with:

lsinitrd /boot/initrd* | grep cryptsetup

Afaik it is not even guaranteed that the same drives get the same device files even if the overall drive configuration is not changed, unless only one device is used of course. Therefore I assign this to mkinitrd.

Comment 2 Till Maas 2008-12-05 09:54:07 UTC
*** Bug 465660 has been marked as a duplicate of this bug. ***

Comment 3 Q5sys 2008-12-06 17:42:52 UTC
I'm rather new to Linux, so Im not very strong with using Command line, unless I am told exactly what to use and when.  I know Dos commands very well, but thats of no use here.  I entered the line you posted above and this is the what I got:

[System@localhost ~]$ lsinitrd /boot/initrd* | grep cryptsetup
gzip: /boot/initrd-2.6.27.5-117.fc10.x86_64.img: Permission denied
cpio: premature end of archive
gzip: /boot/initrd-2.6.27.5-117.fc10.x86_64.img: Permission denied
cpio: premature end of archive

Is there any particular time I Should be using the command you posted?  I assumed you wanted me to enter it in a command line window once the system has booted.  Is there a way that I can do this prior to fully booting?

I'll gladly do anything I can to help, I will just need clear instructions.

Comment 4 Bug Zapper 2009-11-18 09:38:33 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 '10'.

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 10'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 10 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

Comment 5 Bug Zapper 2009-12-18 07:10:01 UTC
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.