This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 470692 - Interactive Startup does not happen
Interactive Startup does not happen
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: plymouth (Show other bugs)
11
x86_64 Linux
high Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F11Target
  Show dependency treegraph
 
Reported: 2008-11-08 17:41 EST by A. Mani
Modified: 2010-06-28 06:48 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 06:48:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
dmesg after login in runlevel3 (27.10 KB, text/plain)
2008-11-11 16:53 EST, A. Mani
no flags Details
boot log (2.55 KB, text/plain)
2008-11-11 16:54 EST, A. Mani
no flags Details

  None (edit)
Description A. Mani 2008-11-08 17:41:46 EST
Description of problem:  Pressing 'I' for interactive startup does not work in Fedora 10 preview (Full Install without server components). 


The main difference is 



Version-Release number of selected component (if applicable):

Fedora 10 Preview Release X86_64

How reproducible:


Steps to Reproduce:
1. Boot without kernel parameters 'rhgb quiet'
2. Press 'esc' on the splash screen, and press 'I', 'i' just as the  'press 'I for interactive startup' appears'.
3. 
  
Actual results:
No Y/N prompt ever appears subsequently for each of the services

Expected results:
services will need to be manually enabled.

Additional info:
\home is on an encrypted xfs partition, so I
get the password prompt for that after
the "Press I for interactive startup" and 'udev  OK' messages.

No keyboard problems. All of the 'i's and 'I's get printed on the screen too.
Comment 1 Bill Nottingham 2008-11-10 12:33:01 EST
What happens if you hit 'I' *after* decrypting the filesystem?
Comment 2 A. Mani 2008-11-11 12:06:39 EST
Does not work as well. It boots in non-interactive mode.

Same when the boot time kernel parameter 'runlevel 3' is used.

More info from dmsetup

Name:              luks-7f32b688-3cfd-4b26-ad02-37d69d058c1b
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      253, 0
Number of targets: 1

luks-7f32b688-3cfd-4b26-ad02-37d69d058c1b: 0 39181440 crypt
Comment 3 Bill Nottingham 2008-11-11 13:59:35 EST
I can't reproduce this here - hitting 'i' (or holding it down) once the encryption setup is done does the right thing for me.

There's definitely some display weirdness, but it does start correctly.
Comment 4 A. Mani 2008-11-11 16:53:03 EST
Created attachment 323262 [details]
dmesg after login in runlevel3
Comment 5 A. Mani 2008-11-11 16:54:10 EST
Created attachment 323263 [details]
boot log
Comment 6 A. Mani 2008-11-11 17:02:42 EST
I am attaching boot.log and dmesg

Replaced 'rhgb quiet' with 'runlevel 3' for the boot. Did not work even after 10 'i's. and immediately after entering passphrase 

Install media is perfect too.
Comment 7 Bill Nottingham 2008-11-11 19:45:21 EST
What happens if you *don't* hit escape?
Comment 8 A. Mani 2008-11-12 16:21:43 EST
Yes, then it works.
Comment 9 Ray Strode [halfline] 2008-11-13 13:12:56 EST
So this seems pretty randomly working in general:

{
...
    while :; do
        pid=$(/sbin/pidof getkey)
        [ -n "$pid" -o -e /var/run/getkey_done ] && break
        usleep 100000
    done
    [ -n "$pid" ] && kill -TERM "$pid" >/dev/null 2>&1
...
} &
...
/sbin/getkey i && touch /var/run/confirm
...
wait

Which, if i'm not reading it wrong says:

- start getkey and have it block until someone presses i or it gets killed
- meanwhile check if getkey is running.  if it is, then kill it, otherwise wait a 10th of a second and repeat

That means in some cases i won't be checked for at all, and in most cases it will only get checked for very briefly.

Bill, am I missing something?

We should probably have plymouth listen for i instead.
Comment 10 Bill Nottingham 2008-11-13 15:31:21 EST
It's reading from the console; it will catch any keypresses that happen to be in the buffer at that point. So it actually has a fairly long reach, unless something else is reading from the buffer.

My question is why does switching to details mode make it not work?
Comment 11 Ray Strode [halfline] 2008-11-13 16:19:41 EST
plymouth is reading from the buffer...

won't the above code run into:

start getkey
kill getkey

before getkey does it's read?

in my brief testing I was able to switch to details mode and do interactive mode some of the time.  I think this problem is a combination of

1) the above code being buggy
2) plymouth and the above code competing for access to the tty for input.
Comment 12 Bill Nottingham 2008-11-13 17:16:15 EST
It's racy, but for the race to fail (ignoring other things reading the input as well), the following:

- writing to two files
- removing cruft in /tmp
- removing all sorts of things in /var
- setting up swap
- dumping dmesg to /var/log

would all have to finish before getkey does its first read.
Comment 13 Ray Strode [halfline] 2008-11-13 17:29:05 EST
true, okay so it's probably just 2) that's the problem here.
Comment 14 Ray Strode [halfline] 2008-11-13 17:38:20 EST
So fixing this right isn't going to happen for F10.  Given more time and testing, we should be able to get something reasonable for F11.

A workaround is to put "confirm" on the kernel command line from grub before booting.
Comment 15 Harald Hoyer 2008-11-14 04:42:38 EST
plymouth is a PITA, if you want to debug things with init=/bin/sh .. you have to kill it first and double input every letter. I hope you will find another solution for plymouth.
Comment 16 Ray Strode [halfline] 2008-11-14 09:29:40 EST
Harald, your issue is already fixed. See bug 471007 for details.
Comment 17 Harald Hoyer 2008-11-18 12:42:14 EST
(In reply to comment #16)
> Harald, your issue is already fixed. See bug 471007 for details.

superb! :-)
Comment 18 Bug Zapper 2008-11-26 00:04:25 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Jon Stanley 2008-11-26 14:13:37 EST
Fixing version to align with rawhide again.  Sorry for the noise.
Comment 20 Mateusz M. 2008-12-13 23:45:28 EST
sorry not at all runlevel 3 and interactive when i shutdown system in interactive mode i can press keys y, n, c, but when i press enter it show ^M
Comment 21 Jeremy Faith 2009-03-03 12:40:12 EST
Any program that requires input during boot suffers from plymouth getting the keyboard input. In the worst case this can make it very difficult to boot the machine.

For example while testing drbd/heartbeat with Fedora 10 I found the following problem. When booting a machine and the other node is not available drbd requires the user to abort waiting by entering 'yes'. But plymouth is messing with the input so drbd does not get the correct input. The machine is then stuck waiting for the user to enter yes and no matter how many times the user does this drbd does not get the input(or at least not the correct input!).

Booting into single user mode and exiting works ok, as plymouthd is not running during rc3.d startup in this case.

The best workaround I have found is to add 'plymouth --quit' to the start(or end) of /etc/rc.sysinit after which drbd works fine. But it took me a day to realise that it was plymouth that was causing the problem and how to get rid of it.

Note that even if rhgb is removed from the kernel options this problem still occurs.

Until a proper solution to this problem is found may I suggest adding a line to rc.sysinit to call 'plymouth --quit' if not in graphical boot mode. This will at least prevent people who disable graphical boot from experiencing this issue.

Indeed until a proper solution is found maybe all systems should call plymouth --quit at the end of /etc/rc.sysinit as not being able to boot is a serious problem.
Comment 22 Ray Strode [halfline] 2009-03-04 11:12:00 EST
plymouth is still used for boot logging. plymouth --quit in rc.sysinit doesn't make sense.

A work around would be for the init scripts to do

 plymouth --hide-splash
before asking for input and 
 plymouth --show-splash

after getting the input.
Comment 23 Jeremy Faith 2009-03-04 12:37:24 EST
hmm, you are correct --hide-splash works.
I guess hide-splash does more than just not showing the progress bar. I thought
hide-splash would be similar to not using rhgb.

I noticed hide-splash was used quite a bit in rc.sysinit itself, before things that required input, so I suppose I should have figured it was the better option.

I will add plymouth --hide-splash to the end of rc.sysinit from now on, this will cover all init scripts that may need input. For me this is fine. I'm still a bit worried that other people will run into this problem though.

I don't think it's a good idea to change init scripts that may require input to  work with plymouth(except rc.sysinit). There are lots of packages that people install from source that should not have to know about plymouth. If individual init scripts are changed to use --hide-splash and --show-splash that would interfere with the simple rc.sysinit --hide-splash solution.

Thanks.
Comment 24 Bug Zapper 2009-06-09 05:51:29 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 25 Bug Zapper 2010-04-27 08:19:21 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  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 '11'.

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 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 26 Bug Zapper 2010-06-28 06:48:18 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.

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.