Bug 461797 - Home without clear for password prompt is confusing
Home without clear for password prompt is confusing
Product: Fedora
Classification: Fedora
Component: plymouth (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-09-10 13:20 EDT by Bruno Wolff III
Modified: 2008-10-22 21:24 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-20 17:36:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bruno Wolff III 2008-09-10 13:20:23 EDT
Description of problem:
In rawhide before first prompting for the password of a file system (other than /root or swap) the cursor is homed without clearing the screen. The prompt only overwrites some of the previous text and it makes it hard to both notice and read the prompts.

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

How reproducible:
It happens 100% of the time.

Steps to Reproduce:
1.Reboot a system with a nonroot nonswap encrypted file system.
Actual results:
The first prompt is displayed at the top of the screen.

Expected results:
My preference would be continued scrolling, but if you can't clearing the screen would be an improvement over the current behavior.

Additional info:
Comment 1 Ray Strode [halfline] 2008-09-10 19:28:06 EDT
This should actually be fixed with initscripts in tomorrow's rawhide.
Comment 2 Bruno Wolff III 2008-09-10 20:06:51 EDT
I'll test it tomorrow morning. I need to reboot to test a video driver issue as well, so I can kill two bugs with one reboot.
I'll give feedback and close the ticket if it is fixed for me as well.
Comment 3 Bruno Wolff III 2008-09-11 10:26:48 EDT
I sort of tested this. I couldn't yum update to all of the new rawhide updates due to conflicts. I did upgrade plymouth to plymouth-0.6.0-0.2008.09.10.1.fc10.x86_64, but I still saw the same problem.
I have to run now, but when i get back I'll check plymouth in koji and see if i can get some more of the rawhide updates installed. If there are any key packages I need to see the changed behavior, please let me know.
Comment 4 Ray Strode [halfline] 2008-09-11 12:08:41 EDT
The fix is in initscripts
Comment 5 Bruno Wolff III 2008-09-11 12:42:43 EDT
Well I sort of tested this. It turns out there is another new feature that blocks the test. I use the same pass phrase on all of the file systems so I don't get prompted again after udev starts any more.
I don't really want to mess with those right now, but I can probably come up with a test using my usb drive which has a different pass phrase. I might not get that done today though.
Comment 6 Bruno Wolff III 2008-09-12 16:30:59 EDT
I didn't have much luck trying to get an encrypted usb drive to get mounted during boot. I think it will be easier to mess with the pass phrases and I'll try that out early next week.
Comment 7 Alexandre Oliva 2008-09-14 13:57:44 EDT
I had trouble after updating my previously-functional encrypted-home setup to initscripts-8.82.  It would ask for the passphrase twice (not letting me know what passphrase it was asking for), with rhgb disabled for diagnostics it would *print* the passphrase to the screen (bad!), and it would fail to fsck the encrypted filesystem.  When it dropped down to the command prompt for manual fixes, /dev/mapper existed and contained the expected logical volumes, but no sign of the luks device.  Running cryptsetup luksOpen enabled me to even mount the filesystem, but that didn't help me get a working system, because rc.sysinit would reboot after I "fixed" things up.  I had to downgrade to initscripts-8.81.
Comment 8 Ray Strode [halfline] 2008-09-15 11:02:09 EDT
lxo, which version of plymouth do you have installed in the initrd you're using?

You need at least version:


to work with the newest initscripts

Make sure you have the latest plymouth installed, and try:

/sbin/mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r)

to see if that fixes things up.
Comment 9 Bruno Wolff III 2008-09-15 11:46:36 EDT
I have plymouth-0.6.0-0.2008.09.10.1.fc10.x86_64 installed.
The issue I was having with retesting was that it appeared that a new feature was added to cache the pass phrases entered for / and or swap and try them on other file systems after udev starting mounting file systems. So I wasn't getting asked for a pass phrase in the spot I was seeing the problem any more. (That the pass phrases are being cached raises some concerns, but aren't relevant to this bug.) I need to change one of the pass phrases in order to force a prompt. I was hoping to avoid this by having my usb drive mounted during the boot process, but doing that wasn't as simple as I had hoped, so I'll do the pass phrase change. I should have this retested by the end of the day.
Comment 10 Bruno Wolff III 2008-09-15 13:49:23 EDT
I changed a pass phrase on one of the file systems and was able to verify that no "home" is done. Things worked nicely. Changing the pass phrase didn't turn out to be a big deal either; I just needed to do a little reading.
Comment 11 Ray Strode [halfline] 2008-09-15 14:00:03 EDT
Thanks for verifying Bruno.

Alexandre, if you continue to have issues after rebuilding the mkinitrd, file a new bug and we'll investigate.
Comment 12 James Ralston 2008-10-14 11:45:43 EDT
I'm running 0.6.0-0.2008.10.08.2, and this bug is most definitely NOT fixed (at least when booting without "rhgb quiet", which is what I prefer). When plymouth starts, it still homes the cursor, and does not clear the screen.

Also, IMHO, the real bug here is that plymouth homes the cursor in the first place (not that it fails to clear the screen when doing so), because homing the cursor overwrites the boot messages printed up to that point (if plymouth doesn't clear the screen) or clears them entirely (if plymouth clears the screen). These messages are critical for debugging problems that prevent system startup (e.g., bug 466867).

When plymouth starts, it should simply continue scrolling the display.
Comment 13 Ray Strode [halfline] 2008-10-20 17:36:44 EDT
Hi, we should be good to go now.

We no longer put the cursor at 0, 0 when opening the tty, so the details plugin should continue where the kernel messages pre-plymouth left off.
Comment 14 James Ralston 2008-10-22 15:56:36 EDT
Confirmed (re: comment 13).

However, as an aside, now the kernel itself is clearing the screen (see bug 468100).  Yay.  :(

(Most... stomp... all... screen... clears...)
Comment 15 Ray Strode [halfline] 2008-10-22 21:24:08 EDT
nope that's plymouth too :-)

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