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): udev-127-1.fc10.x86_64 How reproducible: It happens 100% of the time. Steps to Reproduce: 1.Reboot a system with a nonroot nonswap encrypted file system. 2. 3. 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:
This should actually be fixed with initscripts in tomorrow's rawhide.
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. Thanks.
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.
The fix is in initscripts
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.
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.
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.
lxo, which version of plymouth do you have installed in the initrd you're using? You need at least version: 0.5.0-0.2008.09.05.1 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.
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.
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.
Thanks for verifying Bruno. Alexandre, if you continue to have issues after rebuilding the mkinitrd, file a new bug and we'll investigate.
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.
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.
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...)
nope that's plymouth too :-)