| Summary: | Unable to enter passphrase for encrypted rootfs when no 'console=' is included on aarch64 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Paul Whalen <pwhalen> |
| Component: | plymouth | Assignee: | Ray Strode [halfline] <rstrode> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | high | ||
| Version: | 24 | CC: | dmarlin, elad, fedora, gansalmon, itamar, jbastian, jonathan, kernel-maint, labbott, lersek, madhu.chinakonda, mchehab, mclasen, mjuszkie, msalter, pbrobinson, peterm, rstrode, rwf |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | aarch64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-06-18 09:13:16 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: | |
| Bug Depends On: | |||
| Bug Blocks: | 922257 | ||
| Attachments: | |||
|
Description
Paul Whalen
2014-12-10 16:17:09 UTC
3.17.4-302 should be fixed in this version. Still happening with RC7 which includes 3.17.4-302.fc21.aarch64 looks like some interaction between systemd-tty-ask-password and plymouth... trying to debug it now. *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs. Fedora 21 has now been rebased to 3.18.3-201.fc21. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those. *********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously. Reopening for F22, 'console=' is required in Alpha when using an encrypted filesystem. Is this happening on both mustang and seattle? (In reply to Mark Salter from comment #7) > Is this happening on both mustang and seattle? It is (just confirmed seattle). I started looking at this last week. systemd uses systemd-tty-ask-plymouth and systemd-tty-ask-console services to get the password. systemd-tty-ask-plymouth is run first and systemd-tty-ask-console is conditioned on plymouth not running. If I add plymouth.enable=0 to cmdline, then I can enter the password from serial console without needed console= on cmdline. This leads me to believe plymouth is the problem and I'm looking into that now. I suspect plymouth bails if it sees the console= but hangs on tty0 is console= is not present. Just a suspicion at this point. I wouldn't rule out a logic issue in systemd just yet. Fedora 22 Beta RC1 installed in VM also has same problem. Had to add console=ttyAMA0,115200 to be able to enter passphrase. Possibly related: bug 1103393. Yes. Almost certainly the same root issue. But to fix things so password could come from either keyboard or serial would need some changes to systemd logic. I suppose you'd need to poll for input from both until user makes the choice over which one to use. I tried sorting this out some more but didn't make much progress. I can't find any place in systemd or plymouth code where console= would make a difference, so maybe I'm missing something. Someone more familiar with those packages and how they interact should have a look. https://bugzilla.redhat.com/show_bug.cgi?id=1087528 might be related as well? can you put plymouth.debug=stream:/dev/kmsg on the kernel command line and post the output? also, what's the output of # cat /sys/class/tty/console/active after you've booted ? my guess is, (before seeing logs), is we're hitting fallback paths here: http://cgit.freedesktop.org/plymouth/tree/src/main.c#n1958 and ttyAMA0 isn't in that list so, fail. I think that code should be dropped and instead we should look at /sys/class/tty/console/active to find the tty Created attachment 1064381 [details]
Added 'plymouth.debug=stream:/dev/kmsg'
I have F23 running on an APM Mustang system (no encryption), and it shows: # uname -a Linux mustang-10.farm.hsv.redhat.com 4.2.0-0.rc5.git0.2.fc23.aarch64 #1 SMP Tue Aug 4 10:10:31 UTC 2015 aarch64 aarch64 aarch64 GNU/Linux # cat /sys/class/tty/console/active tty0 ttyS0 so actually the logs show the working case and I need to see the failing case. so i guess, instead, what i need is plymouth.debug=stream:/dev/ttyS0 with no console= lines on the kernel command line. Created attachment 1064435 [details]
Added 'plymouth.debug=stream:/dev/ttyS0', no console in kernel cmdline
The above logs were from a 'fail', I was unable to enter the passphrase. New logs attached using /dev/ttyS0 and including the entire boot.
Created attachment 1076727 [details]
Added 'plymouth.debug=stream:/dev/AMA0', no console in kernel cmdline
Here is similar debug output from an AMD Seattle B0 system with plymouth.debug=stream:/dev/AMA0. I was unable to enter the LUKS passphrase.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs. Fedora 22 has now been rebased to 4.2.3-200.fc22. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23. If you experience different issues, please open a new bug report for those. Reopening, this is still happening in 23_RC6, 4.2.3-300.fc23.aarch64. Re-assigning to plymouth which is the actual problem component. Ray: what's the status on this, was it you were going to rebase plymouth, or you had a fix? I can't remember from when we last discussed this. Marking this as a dupe of Adam's even though this one has been open longer and it should have been used. Meh, just happy it's getting some attention *** This bug has been marked as a duplicate of bug 1344141 *** |