Red Hat Bugzilla – Bug 901917
rescue a fedora system mode doesn't recognize luks installation
Last modified: 2013-10-08 08:13:32 EDT
Description of problem: the rescue option of the fedora 18 install dvd does not recognize a luks encrypted installation, it does not setup and mount automatically Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. install fedora 18 encrypted 2. boot into rescue mode of the install dvd 3. Actual results: anaconda says it does not find a linux system Expected results: anaconda sets up the luks patition automatically Additional info:
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.