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):
Steps to Reproduce:
1. install fedora 18 encrypted
2. boot into rescue mode of the install dvd
anaconda says it does not find a linux system
anaconda sets up the luks patition automatically
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
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.