Bug 891786

Summary: No prompt for LUKS password during upgrade dumps to dracut emergency shell
Product: [Fedora] Fedora Reporter: Tim Flink <tflink>
Component: fedup-dracutAssignee: Will Woods <wwoods>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: awilliam, blakerohde, nonamedotc, wwoods
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-04 08:15:54 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:
Attachments:
Description Flags
console logs from failed upgrade attempt none

Description Tim Flink 2013-01-04 00:44:10 UTC 
Created attachment 672271 [details]
console logs from failed upgrade attempt

When upgrading an F17 system installed to encrypted disks, there is no prompt to enter the LUKS password when the 'System Upgrade' GRUB entry is booted.

The fedup plymouth splash is shown and the progress bar advances a little. Eventually, you're dumped to the dracut emergency shell because the system disks could not be mounted.

I've been using a fully updated F17 VM with a single disk, encrypted LVM and a French AZERTY keyboard layout for my testing thus far.

I built a new upgrade.img from fedup-dracut git HEAD (equivalent to fedup-dracut-0.7.2-1) and F18 stable as of 2013-01-03. The images are available in repo form at:

http://tflink.fedorapeople.org/fedup/f18-upgrade-testing/

I've attached the serial console output from the failed upgrade with rd.debug systemd.log_level=debug systemd.log_target=console
Comment 1 Tim Flink 2013-01-04 01:02:19 UTC 
I did another upgrade on the same VM using the F18 beta repo for instrepo. I was prompted for a LUKS password and the upgrade completed as successfully.

So, something changed between beta and now to cause this. Still digging into what could have caused this.

I've been able to do upgrades on non-encrypted systems using the same upgrade.img listed in the description and so have other people, so I don't think that there was a build problem with the images.
Comment 2 Mukundan Ragavan 2013-01-04 01:42:26 UTC 
I can reproduce the bug in the bug description. My system is a fully updated F17 gnome with a /boot partition and encrypted / and swap partitions.

The last error message I can see is not /dev/mapper/encrypted_partition_uuid does not exist.
Comment 3 Adam Williamson 2013-01-04 02:39:17 UTC 
See also https://bugzilla.redhat.com/show_bug.cgi?id=890677 . Seems like everyone's having trouble with LUKS upgrades one way or another.

Have you tried pointing --instrepo to TC4 to see how that behaves, Tim?
Comment 4 Tim Flink 2013-01-04 08:15:54 UTC 
It turns out that this was a build issue with the upgrade.img in that repo. I still don't understand why but the upgrade.img is missing a whole bunch of binaries including cryptsetup and the systemd targets for unlocking encrypted disks.

The upgrade.img that I built with fedup-0.7.2-1 as part of smoke 13 does work, though (x86_64 only):

http://dl.fedoraproject.org/pub/alt/qa/20130103_f18-smoke13/fedup/
Comment 5 Blake R 2014-02-03 07:21:47 UTC 
Hi,

I am running into this problem too. I just tried to upgrade my F19 system to F20 via fedup and when the system auto-rebooted I didn't get my normal LUKS HD encryption password prompt and the system doesn't boot. It eventually goes to this dracut emercency console. Luckily I can still boot to the F19 kernels from GRUB. Is this related to the original bug?

Regards,
Blake