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.
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 " https://fedoraproject.org/wiki/Fedora_18_Final_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 " https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria I would like to emphasize _without unintended user intervention_. Entering dracut shell when you're not fast enough IS an unintended user intervention.
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.
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.
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.
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.
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.
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.
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.
Cc'ing a more widely-spread out e-mail alias.
(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?
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.
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).
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.
Harald can you please provide some information from dracut point of view?
dracut-024-15.git20121218.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/dracut-024-15.git20121218.fc18
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: https://admin.fedoraproject.org/updates/FEDORA-2012-20580/dracut-024-15.git20121218.fc18 then log in and leave karma (feedback).
(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.
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.
*** Bug 921096 has been marked as a duplicate of this bug. ***
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.
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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.