Bug 1087528 - Boot with 'init=/bin/bash' fails if root partition is encrypted (decryption prompt is never shown, boot gets stuck)
Summary: Boot with 'init=/bin/bash' fails if root partition is encrypted (decryption p...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: plymouth
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-14 14:20 UTC by Andy Lutomirski
Modified: 2016-07-19 11:21 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1098332 (view as bug list)
Environment:
Last Closed: 2016-07-19 11:21:43 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1098332 None None None Never

Internal Links: 1098332

Description Andy Lutomirski 2014-04-14 14:20:15 UTC
It seems that dracut can't handle init=/bin/bash.  My system uses LVM on LUKS as root, but if I boot with init=/bin/bash, nothing happens, not even a plymouth password prompt.

Presumably the init option should work by running dracut as usual but then launching /bin/bash instead of systemd once the real root is mounted.

I'm happy to debug, but I've never been very good at figuring out what systemd is thinking when it's just sitting there blinking at me.

Comment 1 Andy Lutomirski 2014-04-14 15:17:50 UTC
It looks like this is supposed to work.  systemctl (at least the upstream version) has explicit support for init= in /proc/cmdline, and initrd-switch-root.service executes that code.  So the problem is that the boot process isn't getting that far.

Comment 2 Adam Williamson 2014-04-17 20:02:35 UTC
Can you check with an initramfs from an older dracut? This may have been broken by the recent dracut update (along with other things).

Comment 3 Adam Williamson 2014-04-17 22:06:44 UTC
so far I've tested it works without encrypted partitions with both old and new dracut, will test with encrypted partitions next.

Comment 4 Adam Williamson 2014-04-17 22:23:53 UTC
seems to be broken even with the original F20 dracut, if you have encrypted / partition. whether you boot with 'rhgb' or not, boot sequence reaches "Started Forward Password Requests to Plymouth." and then just sits there.

Comment 5 Harald Hoyer 2014-05-12 10:32:36 UTC
This might be plymouth failing?

Reassigning to plymouth to get a comment, if "init=.." is special for plymouth and why it influences the behaviour in the initrd.

Question for the reporter: Does it work, if you add "rd.plymouth=0 plymouth.enable=0" to the kernel cmdline?

Comment 6 Adam Williamson 2014-05-13 00:43:59 UTC
just to confirm harald's theory - yes, that does make it work. Seems to be plymouth at fault here.

Comment 7 Ray Strode [halfline] 2014-05-14 19:29:25 UTC
hmm, tricky.  plymouth normally takes over the keyboard during boot (to handle password requests and escape to toggle between splash and details). if 

init=/bin/sh

is on the kernel command line, we don't take over the keyboard since we want the keyboard to be available for /bin/sh.  I guess there are two possible fixes:

1) treat init=/bin/sh like plymouth.enable=0
2) take the keyboard like usual, but relinquish right before switching out of the initrd.

Comment 8 Adam Williamson 2014-05-15 20:23:12 UTC
note  you'd at least want to handle 'init=/bin/bash' and 'init=/bin/sh' if you wanted to go the 'special treatment' route - you'll find both commonly used, in Google searches. I don't know if you want to be nice to zsh fans. =)

Comment 9 Ray Strode [halfline] 2014-05-16 17:02:58 UTC
the code at the moment looks for init= on the front and sh on the back.

Comment 10 Jonathan Mainguy 2015-03-16 17:56:24 UTC
Just confirmed this bug is still present in RHEL7 and Fedora21 if full disk encryption is enabled. The work around is to add init=/bin/bash plymouth.enable=0 to the end of the line. If you do not see the prompt for the password, hold backspace for a few seconds and you will see the prompt, type in luks password.

Comment 11 Fedora End Of Life 2015-05-29 11:34:03 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora  'version'
of '20'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 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 this bug is closed as described in the policy above.

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 12 Fedora End Of Life 2015-06-29 20:05:37 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.

Comment 13 Adam Williamson 2015-06-29 23:00:55 UTC
Per #c10, this is still valid at least for 21, very likely still in Rawhide.

Comment 14 Jonathan Mainguy 2015-06-29 23:47:10 UTC
Can confirm, this is still present in Fedora22 which I used fedup to get to. Work around still works the same.

init=/bin/bash plymouth.enable=0

Comment 15 Fedora End Of Life 2016-07-19 11:21:43 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.


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