Bug 467100 - switching to service starting messages and back to plymouth causes progressbar to restart
switching to service starting messages and back to plymouth causes progressba...
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:
Blocks: F10Target F10DesktopTarget
  Show dependency treegraph
Reported: 2008-10-15 14:19 EDT by Adam Pribyl
Modified: 2008-10-29 03:02 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-28 01:03:56 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 Adam Pribyl 2008-10-15 14:19:42 EDT
Description of problem:
When rawhide is booting and text plymouth progress bar appears on the screen you can press esc to see messages from starting services. Pressing esc once more returns you to plymouth, however progress bar starts from the beginnig like if it just started booting.

Version-Release number of selected component (if applicable):
rawhide... (do not have it now)

How reproducible:

Steps to Reproduce:
1. start boot at either intel on nvidia without KMS
2. press esc key when in the "middle" of the boot
3. press esc key again
Actual results:
progress bar restarts from "0"

Expected results:
progress bar continues even thou you interrupt its drawing

Aditional info:
I personaly would not draw any progress bar, but just animated line (cursor going left to right and back). If we do not have any realiable mechanism to find how far in boot process we are, then drawing progress is meaningless. My plymouth experience says, that even this progress bar is "finished" system is still not booted.
Comment 1 Ray Strode [halfline] 2008-10-15 14:35:41 EDT

This is a known issue, but there was no bug report about it before.  Thank you for filing one.

The progress bar should be pretty reliable because it actually times boot up and uses that time for gauging the progress bar on the next boot up.

We definitely need to fix the bug where the progress bar restarts though.
Comment 2 Jeremy Katz 2008-10-15 15:36:50 EDT
(In reply to comment #1)
> The progress bar should be pretty reliable because it actually times boot up
> and uses that time for gauging the progress bar on the next boot up.

A perhaps trickier question, though, is what to do for the live image case where someone is booting it for the first time.  And if they're not using persistence (and possibly even if they are, I'd have to double check) then the time is going to consistently be wrong
Comment 3 Ray Strode [halfline] 2008-10-15 16:15:42 EDT
i guess we could devolve to a pulsing progress bar when we mount the root filesystem if the boot time isn't there.
Comment 4 Adam Pribyl 2008-10-15 17:36:08 EDT
Then I would vote for a pulsing bar until you know, you have or do not have the time. If you do not find it in root, continue pulsing, otherwise start the "progressive" progress bar.
Comment 5 Charlie Brej 2008-10-18 16:10:32 EDT
I committed a patch to correct the original problem of the progress resetting upon change of splash. It should now retain the progress when switching between splash plugins.

The second issue of not having a reasonable time for the first boot can be solved by looking at the arrival time of messages. The boot duration file could contain not just the time of the full boot, but also the times of individual service announcement [OK/FAIL]s. By comparing the current boot message times and the ones from another boot, you can determine how much slower/faster the current boot is.

This would mean the live CD/USB images come with a boot duration file which was created by a random machine boot. Does that seem sensible?
Comment 6 Bill Nottingham 2008-10-22 11:23:38 EDT
I think that sort of heuristic is probably overkill, and fragile with respect to what services get started, string changes, etc.
Comment 7 Adam Pribyl 2008-10-22 11:47:39 EDT
I agree, it is not needed to complicate the boot time calculation. I'd consider a good improvement if it is pulsing bar when there is no time available, but it is something that we can live without. BTW: Looking into Windows world, they gave up to use boot progress bar a long time ago, probably for a similar reason.
Comment 8 Charlie Brej 2008-10-22 12:23:03 EDT
I have now coded it up and there is little complication. Even with issues like failed services and repeated lines, all that happens is that it doesn't match that message and you get a hit on the next message that is in common with the previous boot. (mailing list) http://lists.freedesktop.org/archives/plymouth/2008-October/000001.html 

Ray was saying he could additionally sprinkle "plymouth
--update="some-unique-id" around the boot sequence so we can estimate from these reather than the messages which could change.
Comment 9 Ray Strode [halfline] 2008-10-22 12:57:53 EDT
those are already sprinkled.
Comment 10 Ray Strode [halfline] 2008-10-22 14:05:03 EDT
i built what Charlie mentioned commiting in comment 5.

Comment 11 Adam Pribyl 2008-10-25 14:04:22 EDT
I have all the updates as of today but this is still not fixed..
Comment 12 Charlie Brej 2008-10-25 14:14:01 EDT
Did you rebuild the initrd?

> rm -f  /boot/initrd-{kernelversion}.img
> mkinitrd  /boot/initrd-{kernelversion}.img {kernel version}
Comment 13 Matthias Clasen 2008-10-28 01:03:56 EDT
I just verified that this is fixed.
Comment 14 Adam Pribyl 2008-10-28 17:10:43 EDT
Ok.. then I would like to know what am I doing wrong. initrd should be rebuild with every kernel install, nevertheless I rebuild the initrd for and I do not see any change. Just to be sure - plymouth 0.6.0-0 is the version with fix? What is fixed is a text based version of plymouth? (I do not have a graphical one - nvidia GFX.) Would it make a difference to use a different version of GRUB than this supplied with rawhide?
Comment 15 Charlie Brej 2008-10-28 17:31:47 EDT
Are you sure grub.conf points to the newest kernel? 
Does it work with vga=0x340 in the kernel line?
What is the full package name? e.g. "plymouth-0.6.0-0.2008.10.24.2.fc10"
Comment 16 Adam Pribyl 2008-10-29 03:02:40 EDT
Fixed.. the kernel was the right one, but the initrd was the old one, generated before plymouth in new version was installed. Have no idea how system can boot with modules from older kernel version, but it can. Well I have one - plymouth suppresses the "could not find <version>.dep" kernel message... but this is different story. Sorry for the reopen here.

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