Bug 901917
| Summary: | rescue a fedora system mode doesn't recognize luks installation | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | James <sh1v4_0h> |
| Component: | anaconda | Assignee: | Vratislav Podzimek <vpodzime> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | awilliam, chemobejk, daniell1, g.kaviyarasu, jonathan, pb, pschindl, robatino, sbueno, sysoutfran, vanmeeuwen+fedora, vpodzime |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | AcceptedBlocker AcceptedFreezeException | ||
| Fixed In Version: | anaconda-20.19-1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-10-08 12:13:32 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 980650, 980651 | ||
|
Description
James
2013-01-19 23:18:35 UTC
Can confirm the issue Ugly workaround: boot in rescue mode, skip anaconda step, do all manually on shell, e.g. search with "blkid" for encrypted partition, open it with "cryptsetup luksOpen /dev/something", start VolumeGroup by "vgchange -a y". Mount at least root partition to /mnt/sysimage, mount then (when existing) the /boot partion and /dev and /proc via bind mount. Then a "chroot" should be possible. Reproduced with F19. This is *NASTY* beyond words. I consider this a showstopper bug, considering that users might be in "panic mode" when they have to use the rescue mode to revive their machine! Example: a broken grub2 update, like bug 976768, where the machine doesn't even reach the grub menu anymore and rescue is your only option... It seems to me that the new anaconda/anaconda storage module doesn't scan anything. Here is what I tried when the Continue/Read-Only/Skip dialog is up - ALT-F2 to go into the shell - run "cryptsetup open /dev/sda luks" - verified that the unlocked partitions appear in /dev/mapper - ALT-F1 to go back to dialog - select "Continue" Even now anaconda tells me that there are no Linux installations on the disk! Note to self for future reference: cryptsetup open /dev/sda luks mount /dev/mapper/VolGroup00-LogVol00 /mnt/sysimage mount /dev/sda1 /mnt/sysimage/boot mount --bind /dev /mnt/sysimage/dev mount --bind /proc /mnt/sysimage/proc mount --bind /run /mnt/sysimage/run mount --bind /sys /mnt/sysimage/sys mount --bind /tmp /mnt/sysimage/tmp chroot /mnt/sysimage Following the advice from #fedora-qa I'm assigning this as blocking bug to F20, so that it gets the proper attention (hopefully) in the F20 time frame. Discussed at 2013-08-21 blocker review meeting. This is rejected as an Alpha blocker but accepted as a Beta blocker: the Alpha criterion reads "The rescue mode of the installer must start successfully and be able to detect and mount an existing default installation." - https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Rescue_mode - and the Beta criterion reads "The rescue mode of the installer must be able to detect and mount any installation performed according to the applicable criteria, and provide a shell with access to utilities capable of performing typical recovery operations." - https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Rescue_mode - so that seems pretty clear. Accepted as Alpha freeze exception issue too, as this is clearly something it'd be a good idea to fix if we can. *** Bug 908118 has been marked as a duplicate of this bug. *** Bug is fixed in anaconda-20.21-1. Closing this bug. |