Bug 891786 - No prompt for LUKS password during upgrade dumps to dracut emergency shell
Summary: No prompt for LUKS password during upgrade dumps to dracut emergency shell
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: fedup-dracut
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Will Woods
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-04 00:44 UTC by Tim Flink
Modified: 2014-02-03 07:21 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-01-04 08:15:54 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
console logs from failed upgrade attempt (646.02 KB, text/plain)
2013-01-04 00:44 UTC, Tim Flink
no flags Details

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


Note You need to log in before you can comment on or make changes to this bug.