Bug 470692

What happens if you hit 'I' *after* decrypting the filesystem?

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

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.

Created attachment 323262 [details]
dmesg after login in runlevel3

Created attachment 323263 [details]
boot log

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.

What happens if you *don't* hit escape?

Yes, then it works.

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.

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?

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.

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.

true, okay so it's probably just 2) that's the problem here.

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.

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.

Harald, your issue is already fixed. See bug 471007 for details.

(In reply to comment #16)
> Harald, your issue is already fixed. See bug 471007 for details.

superb! :-)

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

Fixing version to align with rawhide again.  Sorry for the noise.

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

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.

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.

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.

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

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

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.