Bug 1172740 - Unable to enter passphrase for encrypted rootfs when no 'console=' is included on aarch64
Summary: Unable to enter passphrase for encrypted rootfs when no 'console=' is include...
Keywords:
Status: CLOSED DUPLICATE of bug 1344141
Alias: None
Product: Fedora
Classification: Fedora
Component: plymouth
Version: 24
Hardware: aarch64
OS: Linux
high
unspecified
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARM64, F-ExcludeArch-aarch64
TreeView+ depends on / blocked
 
Reported: 2014-12-10 16:17 UTC by Paul Whalen
Modified: 2019-07-24 14:07 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-18 09:13:16 UTC


Attachments (Terms of Use)
Added 'plymouth.debug=stream:/dev/kmsg' (15.74 KB, text/plain)
2015-08-18 17:09 UTC, Paul Whalen
no flags Details
Added 'plymouth.debug=stream:/dev/ttyS0', no console in kernel cmdline (41.14 KB, text/plain)
2015-08-18 19:30 UTC, Paul Whalen
no flags Details
Added 'plymouth.debug=stream:/dev/AMA0', no console in kernel cmdline (40.18 KB, text/plain)
2015-09-24 21:39 UTC, Jeff Bastian
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1103393 None CLOSED plymouth takes LUKS password only from VT, not serial console 2019-07-24 14:04:11 UTC

Internal Links: 1103393

Description Paul Whalen 2014-12-10 16:17:09 UTC
Description of problem:
Unable to enter passphrase for encrypted rootfs when no 'console=' is included in the kernel args on aarch64 F21 RC6. 

Version-Release number of selected component (if applicable):
3.17.4-301.fc21.aarch64

How reproducible:
Everytime

Steps to Reproduce:
Autopart install + encrypted

Comment 1 Kyle McMartin 2014-12-11 19:29:04 UTC
3.17.4-302 should be fixed in this version.

Comment 2 Paul Whalen 2014-12-16 06:45:09 UTC
Still happening with RC7 which includes 3.17.4-302.fc21.aarch64

Comment 3 Kyle McMartin 2014-12-16 14:35:23 UTC
looks like some interaction between systemd-tty-ask-password and plymouth... trying to debug it now.

Comment 4 Justin M. Forbes 2015-01-27 14:59:33 UTC
*********** 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.

Comment 5 Fedora Kernel Team 2015-02-24 16:14:21 UTC
*********** 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.

Comment 6 Paul Whalen 2015-03-27 14:11:22 UTC
Reopening for F22, 'console=' is required in Alpha when using an encrypted filesystem.

Comment 7 Mark Salter 2015-04-02 19:30:51 UTC
Is this happening on both mustang and seattle?

Comment 8 Paul Whalen 2015-04-02 22:17:20 UTC
(In reply to Mark Salter from comment #7)
> Is this happening on both mustang and seattle?

It is (just confirmed seattle).

Comment 9 Mark Salter 2015-04-21 13:51:43 UTC
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.

Comment 10 Marcin Juszkiewicz 2015-04-21 13:55:11 UTC
Fedora 22 Beta RC1 installed in VM also has same problem. Had to add console=ttyAMA0,115200 to be able to enter passphrase.

Comment 11 Laszlo Ersek 2015-04-21 14:36:58 UTC
Possibly related: bug 1103393.

Comment 12 Mark Salter 2015-04-21 15:21:07 UTC
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.

Comment 13 Mark Salter 2015-05-19 14:54:11 UTC
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.

Comment 14 Laura Abbott 2015-05-19 16:28:04 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1087528 might be related as well?

Comment 15 Ray Strode [halfline] 2015-08-06 15:01:45 UTC
can you put

plymouth.debug=stream:/dev/kmsg

on the kernel command line and post the output?

Comment 16 Ray Strode [halfline] 2015-08-06 15:07:08 UTC
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

Comment 17 Paul Whalen 2015-08-18 17:09:01 UTC
Created attachment 1064381 [details]
Added 'plymouth.debug=stream:/dev/kmsg'

Comment 18 D. Marlin 2015-08-18 17:25:20 UTC
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

Comment 19 Ray Strode [halfline] 2015-08-18 18:49:34 UTC
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.

Comment 20 Paul Whalen 2015-08-18 19:30:21 UTC
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.

Comment 21 Jeff Bastian 2015-09-24 21:39:06 UTC
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.

Comment 22 Justin M. Forbes 2015-10-20 19:24:41 UTC
*********** 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.

Comment 23 Paul Whalen 2015-10-30 13:31:40 UTC
Reopening, this is still happening in 23_RC6, 4.2.3-300.fc23.aarch64.

Comment 24 Peter Robinson 2016-03-30 17:58:04 UTC
Re-assigning to plymouth which is the actual problem component.

Comment 25 Peter Robinson 2016-03-30 17:58:28 UTC
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.

Comment 26 Peter Robinson 2016-06-18 09:13:16 UTC
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 ***


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