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: 1. 2. 3. Actual results: Boot failed and kicked to a busybox prompt Expected results: Boot w/o failing Additional info:
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.
Created attachment 326250 [details] requested /tmp/init file
[root@x2 Download]# cryptsetup luksUUID /dev/mapper/VGSys-LVHome d8590a73-6fd0-46e5-8135-3ad739f58f6c Let me know if there is anything else. Thanks, Jason
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 06055928-2fa5-4f8f-bdce-3f0122100cbf [root@note etc]# cryptsetup luksUUID /dev/sda9 e9c8e277-04f5-4eea-bf57-835a46bc3b2d [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. Jon
Just installed F11 on this, it's still there. same results as before. Jon
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).
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. Jon
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...
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
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.