Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1172740

Summary: Unable to enter passphrase for encrypted rootfs when no 'console=' is included on aarch64
Product: [Fedora] Fedora Reporter: Paul Whalen <pwhalen>
Component: plymouthAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: high    
Version: 24CC: 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:
Embargoed:
Bug Depends On:    
Bug Blocks: 922257    
Attachments:
Description Flags
Added 'plymouth.debug=stream:/dev/kmsg'
none
Added 'plymouth.debug=stream:/dev/ttyS0', no console in kernel cmdline
none
Added 'plymouth.debug=stream:/dev/AMA0', no console in kernel cmdline none

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 ***