Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 467100 - switching to service starting messages and back to plymouth causes progressbar to restart
Summary: switching to service starting messages and back to plymouth causes progressba...
Alias: None
Product: Fedora
Classification: Fedora
Component: plymouth
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F10Target F10DesktopTarget
TreeView+ depends on / blocked
Reported: 2008-10-15 18:19 UTC by Adam Pribyl
Modified: 2008-10-29 07:02 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-10-28 05:03:56 UTC

Attachments (Terms of Use)

Description Adam Pribyl 2008-10-15 18:19:42 UTC
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 18:35:41 UTC

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 19:36:50 UTC
(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 20:15:42 UTC
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 21:36:08 UTC
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 20:10:32 UTC
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 15:23:38 UTC
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 15:47:39 UTC
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 16:23:03 UTC
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) 

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 16:57:53 UTC
those are already sprinkled.

Comment 10 Ray Strode [halfline] 2008-10-22 18:05:03 UTC
i built what Charlie mentioned commiting in comment 5.


Comment 11 Adam Pribyl 2008-10-25 18:04:22 UTC
I have all the updates as of today but this is still not fixed..

Comment 12 Charlie Brej 2008-10-25 18:14:01 UTC
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 05:03:56 UTC
I just verified that this is fixed.

Comment 14 Adam Pribyl 2008-10-28 21:10:43 UTC
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 21:31:47 UTC
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 07:02:40 UTC
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.