Bug 473521
| Summary: | Post install F10, unable to boot, fsck error, LUKS/LVM | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jason Smith <jvsmith> | ||||
| Component: | initscripts | Assignee: | Bill Nottingham <notting> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 10 | CC: | notting, rvokal, sirlight | ||||
| Target Milestone: | --- | Keywords: | Triaged | ||||
| 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:01:09 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: | |||||||
| Attachments: |
|
||||||
|
Description
Jason Smith
2008-11-29 03:09:50 UTC
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. |