Bug 881670 - Provide fedup hook to add x-systemd.device-timeout=0 to mount options for encrypted file systems that need a passphrase from the user
Summary: Provide fedup hook to add x-systemd.device-timeout=0 to mount options for enc...
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 18
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedNTH
: 921096 (view as bug list)
Depends On:
Blocks: F18-accepted, F18FinalFreezeExcept
TreeView+ depends on / blocked
Reported: 2012-11-29 10:14 UTC by Kamil Páral
Modified: 2014-11-10 12:35 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-02-05 22:53:38 UTC
Type: Bug
harald: needinfo-
harald: needinfo-

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 861123 0 unspecified CLOSED Please add x-systemd.device-timeout=0 to mount options for encrypted file systems that need a passphrase from the user 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 868421 0 high CLOSED Dracut should not time out and fail waiting for LUKS decryption 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 894242 0 unspecified CLOSED upgrade process hangs with encrypted /home (no graphical unlock dialog) 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 896010 0 unspecified CLOSED SELinux gets in the way of systemd-ask-password trying to use cached passwords during system upgrade 2021-02-22 00:41:40 UTC

Internal Links: 861123 868421 894242 896010

Description Kamil Páral 2012-11-29 10:14:44 UTC
Description of problem:
This is a follow-up of bug 861123. It's not just the fresh installs that need the "x-systemd.device-timeout=0" mount option. It's also the upgraded systems that need to be taken care of. Systemd guys should write a script that "does the right thing" and provide it as an upgrade hook for fedup, so that users that upgrade don't end up in dracut shell every time their fingers are not fast enough.

Comment 1 Kamil Páral 2012-11-29 10:21:58 UTC
Please note that while anaconda fixes are finished in bug 861123 and just some bug in systemd remains, this bug is something that _can't_ be fixed with an upgrade, IIUIC. Systemd bugs can be fixed later, yes, but this mount option has to be present, because it might be very hard to add it afterwards.

Proposing as F18 Final blocker:
" For each one of the release-blocking package sets ('minimal', and the package sets for each one of the release-blocking desktops), it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using all officially recommended upgrade mechanisms. The upgraded system must meet all release criteria "
" Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied "

I would like to emphasize _without unintended user intervention_. Entering dracut shell when you're not fast enough IS an unintended user intervention.

Comment 2 Michal Schmidt 2012-11-29 12:32:49 UTC
You're interpreting the criterion too widely, IMHO.

If intended intervention is performed (i.e. the password is entered when prompted), the system boots. The time window is not that short.

The timeout can be annoying, but I don't think this is a blocker.

Comment 3 Kamil Páral 2012-11-29 13:35:34 UTC
When I was testing this "feature", I wasn't able to type in password two times (when you first input is incorrect), because it timed out before my second attempt was complete. I don't call that long timeout, but maybe that changed. How long is the timeout now?

Also, I doubt that majority of Fedora users know how to exit dracut shell.

Comment 4 Tim Flink 2012-11-30 20:31:10 UTC
If you don't enter the LUKS password in time, can you reboot and try again? I assume that the upgrade process hasn't been started if the disks weren't mounted.

While it is rather user-unfriendly, I think we could get away with documentation on this instead of blocking release.

-1 blocker, +1 NTH unless I'm misunderstanding something here.

Comment 5 Kamil Páral 2012-12-03 09:08:34 UTC
Tim, this is not related to booting into the upgrade process (one-time activity). This concerns the upgraded system (all its boot-ups in the future). fedup needs to modify /etc/fstab, otherwise the upgraded system won't wait for disk unlocking.

Comment 6 Kamil Páral 2012-12-03 10:19:18 UTC
This is worth quoting from IRC, I just saw it:
(mel- started the system upgrade)
<mel-> so when i came back to the computer in the morning i saw some error message about booting failure related to encypted harddisk.

This nicely illustrates the problem. You start the upgrade, return back and see the dracut shell. What should a general user make out of it? Either "The upgrade has failed" or "The system is broken", with a bit of vulgar expressions on top of that.

Comment 7 Adam Williamson 2012-12-03 19:24:56 UTC
Discussed at 2012-12-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-12-03/f18final-blocker-review-1.2.2012-12-03-17.25.log.txt . There was some disagreement about the seriousness of this bug and the various scenarios which can and can't be fixed. We agreed to delay the decision on its status for some time to see if more clarity can be reached.

Comment 8 Kamil Páral 2012-12-03 19:25:51 UTC
Lennart, could you please comment here whether there is a possibility to fix this with a systemd update (that would modify /etc/fstab), if we don't have the fedup-dracut hook available in time for F18 release? Thanks.

Comment 9 Bill Nottingham 2012-12-03 21:51:29 UTC
Cc'ing a more widely-spread out e-mail alias.

Comment 10 Kamil Páral 2012-12-04 12:47:56 UTC
(In reply to comment #9)
> Cc'ing a more widely-spread out e-mail alias.

I don't see any action in the history. Have you really added the CC?

Comment 11 Kamil Páral 2012-12-04 15:28:56 UTC
I have talked to Michal Schmidt, he will investigate this bug. Lennart is on vacation right now, for about 2 weeks.

I have measured the unlock timeout and it's exactly 2 minutes. After that you'll see the dracut shell.

These are the use cases where you receive a dracut shell:
1. Bob boots into System Upgrade on F17, he goes away because it is a long process. Bob return and he sees a screen full of text he doesn't understand. Bob assumes something went horribly wrong during the upgrade. He doesn't know what to do, so he power-cycles the machine.

2. Jane has an F17 upgraded to F18. Jane uses GNOME. The "offline updates" functionality in GNOME tells Jane that updates need to be installed. Jane confirms it, reboots the computers, and updates are being installed. Jane goes for a coffee. When Jane returns, he sees a dracut shell. She has no idea what just happened and what to do now. Jane assumes her computer is screwed and all her work lost. Jane is very angry. She doesn't know what to do, so she powers it off and calls her nephew who installed this computer.

3. Matthew has an F17 upgraded to F18. Matthew uses KDE. Matthew installs new updates using Apper and he's told he should reboot the computer. Matthew hits reboot. Because shutting down the system takes about 30 seconds on his slow machine, he starts chatting with a colleague in the next room. A 5 minutes later he returns and sees a dracut shell. He laughs loudly at Fedora low quality standards and issues "reboot".

From the three test cases only Matthew was not angry and only Matthew correctly rebooted the computer. If Bob and Jane had fully encrypted disk, they probably didn't lose any data, because root partition was not mounted. Probably. If they had just /home (or other partition) encrypted, some data might got corrupted, because root partition could have been mounted read/write at that time.

I believed that this bug was a bigger problem than bug 861123, because I believed this bug can't be fixed with an update (unless systemd maintainers want to incorporate a scriptlet that handles fstab transformation and are willing to maintain it for 2 release cycles), but bug 861123 can be fixed with an update (fstab is already transformed for clean installs). However, I'm not so sure anymore, please read bug 861123#c31. Maybe we can join the conversation.

The big question here is what can be fixed with an update and what cannot.

Comment 12 Kamil Páral 2012-12-05 16:02:15 UTC
I have talked to Harald, see bug 868421 comment 11 to 13. It seems that most of the problems people see is caused by bug 868421, which should be fixable in dracut (even with an update).

We still need to fix fedup the same way we fixed anaconda (fstab modification during the installation/upgrade process), but it does no longer seem so severe. The time out would be encountered only for other than the root partition. Still, having just /home encrypted (and not /) might be very common and it would be great to know whether the timeout issue would affect such users or not (currently it seems it would).

Comment 13 Adam Williamson 2012-12-05 17:31:59 UTC
Discussed at 2012-12-05 blocker review meeting - http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-05/f18final-blocker-review-2.2012-12-05-17.01.log.txt . Agreed there is still confusion as to the exact nature, effects and fixability of this bug, so we have delayed decision on its status again for now.

Comment 14 Lukáš Nykrýn 2012-12-10 15:19:03 UTC
Harald can you please provide some information from dracut point of view?

Comment 15 Fedora Update System 2012-12-18 15:57:23 UTC
dracut-024-15.git20121218.fc18 has been submitted as an update for Fedora 18.

Comment 16 Fedora Update System 2012-12-18 21:27:47 UTC
Package dracut-024-15.git20121218.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dracut-024-15.git20121218.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 17 Kamil Páral 2012-12-19 16:08:30 UTC
(In reply to comment #16)
I think this wasn't intended to fix this bug, but bug 868421 instead. Anyway, it doesn't fix anything, neither full disk encryption nor just /home encryption. The prompt still times out.

Comment 18 Adam Williamson 2012-12-21 21:07:42 UTC
Discussed at 2012-12-21 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-21/f18final-blocker-review-7.2012-12-21-18.33.log.txt . Rejected as a blocker: no-one seems to agree with Kamil that this is serious enough to block release for, even with the arguments in comment #0 and #1. Accepted as NTH, it is annoying enough that a fix would be considered through freeze.

Comment 19 Lennart Poettering 2013-04-09 11:06:05 UTC
*** Bug 921096 has been marked as a duplicate of this bug. ***

Comment 20 Fedora End Of Life 2013-12-21 15:13:02 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 21 Fedora End Of Life 2014-02-05 22:53:38 UTC
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

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