Bug 473521 - Post install F10, unable to boot, fsck error, LUKS/LVM
Post install F10, unable to boot, fsck error, LUKS/LVM
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2008-11-28 22:09 EST by Jason Smith
Modified: 2014-03-16 23:16 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-18 02:01:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
requested /tmp/init file (2.25 KB, text/plain)
2008-12-08 21:16 EST, Jason Smith
no flags Details

  None (edit)
Description Jason Smith 2008-11-28 22:09:50 EST
Description of problem:
Was running F9 with an encrypted / and /home using LVM. The F9 install was rather stock. Volumes and encryption were setup during the F9 install. Performed an install of F10, not an upgrade, and chose to format /, swap and /boot, but not /home. Install went fine. Computer rebooted and boot failed complaining about fsck not being able to check partitions. fsck checking to make sure things are clean is normal. fsck.ext3 complained that it couldn't read the partition information for /dev/mapper/luks-d8590a73-6fd0-46e5-8135-3ad739f58f6c. It would then kick to a busybox prompt. Some digging led me to make a change to /etc/crypttab. The original file had the following:

luks-ce0e45d5-c705-4fde-8f7d-a17172c39aae UUID=ce0e45d5-c705-4fde-8f7d-a17172c39aae none
luks-d8590a73-6fd0-46e5-8135-3ad739f58f6c UUID=d8590a73-6fd0-46e5-8135-3ad739f58f6c none

Changed /etc/crytpttab to 
luks-ce0e45d5-c705-4fde-8f7d-a17172c39aae /dev/mapper/VGSys-LVRoot none
luks-d8590a73-6fd0-46e5-8135-3ad739f58f6c /dev/mapper/VGSys-LVHome none

To get the machine to boot.

Version-Release number of selected component (if applicable):

How reproducible:
It wouldn't boot everytime until I changed /etc/crypttab

Steps to Reproduce:
Actual results:
Boot failed and kicked to a busybox prompt

Expected results:
Boot w/o failing

Additional info:
Comment 1 David Lehman 2008-12-08 14:43:11 EST
What is the UUID of your home LV? (cryptsetup luksUUID /dev/mapper/VGSys-LVHome)

Also, please attach your initrd's init script. If you know which initrd image in /boot you are using, run (as root):

  zcat /boot/<initrd> | (cd /tmp ; cpio -iv init)

Then attach /tmp/init to this report.
Comment 2 Jason Smith 2008-12-08 21:16:58 EST
Created attachment 326250 [details]
requested /tmp/init file
Comment 3 Jason Smith 2008-12-08 21:17:50 EST
[root@x2 Download]# cryptsetup luksUUID /dev/mapper/VGSys-LVHome

Let me know if there is anything else.

Comment 4 Jon 2008-12-27 17:30:48 EST
I am also having the same problem as above on two of my encrypted partitions. 

When I boot the rescue system and comment out the two partitions in the fstab and reboot, the system booted up just fine. When I do the setting up and mounting of the partitions, mounts are ok.

Here is my setup.....

[root@note etc]# cryptsetup luksUUID /dev/sda8
[root@note etc]# cryptsetup luksUUID /dev/sda9
[root@note etc]# cat crypttab 
luks-e9c8e277-04f5-4eea-bf57-835a46bc3b2d UUID=e9c8e277-04f5-4eea-bf57-835a46bc3b2d none
luks-06055928-2fa5-4f8f-bdce-3f0122100cbf UUID=06055928-2fa5-4f8f-bdce-3f0122100cbf none
[root@note etc]# cat fstab

# /etc/fstab
# Created by anaconda on Sun Dec 21 20:53:22 2008
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or vol_id(8) for more info
UUID=3bea92bc-f5de-41e0-ae62-bcdb0c121604 /                       ext3    defaults        1 1
#  UUID=278a4c3a-6416-4802-a8dc-75d66c079283 /extra                  ext3    defaults        1 2
UUID=a7b522f1-cae3-483e-af67-6cb489207a72 /oldroot                ext3    defaults        1 2
#  UUID=eeb82b05-484e-4543-bbac-ac83a3ff845a /home1                  ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
UUID=a3eefbbd-7455-47ef-945c-942c5aecf6eb swap                    swap    defaults        0 0

Please contact me if you have any questions or comments.

Comment 5 Jon 2009-06-11 12:59:08 EDT
Just installed F11 on this, it's still there. same results as before. 

Comment 6 David Lehman 2009-09-03 17:57:41 EDT
Jon, can you please post the output of the command 'blkid' from your F11 system, along with /etc/fstab and /etc/crypttab? It would also help to know which device fsck is failing to find (the exact error message).
Comment 7 Jon 2009-09-12 13:38:41 EDT
Hello Dave... took a bit to get to this.. been busy lately.

As for the message... I get this..

fsck.ext3: No such file or directory while trying to open /dev/mapper/luks-06055928-2fa5-4f8f-bdce-3f0122100cbf 

I also get the same message for the other luks device. 

Output from the blkid command....

/dev/sda7: TYPE="swap" LABEL="SWAP-sda7" UUID="a3eefbbd-7455-47ef-945c-942c5aecf6eb" 
/dev/sda2: UUID="2C88743C8874071C" LABEL="HP_RECOVERY" TYPE="ntfs" 
/dev/sda1: UUID="505ACFBB60A0226C" TYPE="ntfs" 
/dev/sda5: UUID="01c72812-8eca-4890-88dc-bf6bb306b28f" TYPE="ext3" SEC_TYPE="ext2" 
/dev/sda6: LABEL="/newroot" UUID="3bea92bc-f5de-41e0-ae62-bcdb0c121604" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda8: LABEL="HOME1" UUID="6368746f-2074-616b-6f65-207575696400" TYPE="ext2" 
/dev/sda9: LABEL="EXTRA" UUID="6368746f-2074-616b-6f65-207575696400" TYPE="ext2" 

From  the crypttab file....
luks-06055928-2fa5-4f8f-bdce-3f0122100cbf UUID=06055928-2fa5-4f8f-bdce-3f0122100cbf none 
luks-e9c8e277-04f5-4eea-bf57-835a46bc3b2d UUID=e9c8e277-04f5-4eea-bf57-835a46bc3b2d none 

From the fstab file....

# /etc/fstab
# Created by anaconda on Wed Jun 10 19:58:57 2009
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or vol_id(8) for more info
/dev/mapper/luks-06055928-2fa5-4f8f-bdce-3f0122100cbf /home1                  ext3    defaults        1 2
/dev/mapper/luks-e9c8e277-04f5-4eea-bf57-835a46bc3b2d /extra                  ext3    defaults        1 2
UUID=01c72812-8eca-4890-88dc-bf6bb306b28f /                       ext3    defaults        1 1
UUID=3bea92bc-f5de-41e0-ae62-bcdb0c121604 /oldroot                ext3    defaults        1 2
UUID=a3eefbbd-7455-47ef-945c-942c5aecf6eb swap                    swap    defaults        0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  defaults        0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

As always, contact me if you need more infomation. 

Comment 8 David Lehman 2009-09-12 19:49:21 EDT
Ok, so these are encrypted LVs that end p mounted as /home and /extra. This certainly is not related to anaconda, or even mkinitrd. This is an initscripts issue. Reassigning...
Comment 9 Bug Zapper 2009-11-18 04:03:23 EST
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: 
Comment 10 Bug Zapper 2009-12-18 02:01:09 EST
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.

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