Bug 467100
| Summary: | switching to service starting messages and back to plymouth causes progressbar to restart | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Pribyl <covex> |
| Component: | plymouth | Assignee: | Ray Strode [halfline] <rstrode> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | fedora, krh, mclasen, notting, rstrode |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-10-28 05:03:56 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 438944, 465130 | ||
|
Description
Adam Pribyl
2008-10-15 18:19:42 UTC
Hi, 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. (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 i guess we could devolve to a pulsing progress bar when we mount the root filesystem if the boot time isn't there. 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. 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? I think that sort of heuristic is probably overkill, and fragile with respect to what services get started, string changes, etc. 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. 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. those are already sprinkled. i built what Charlie mentioned commiting in comment 5. Closing... I have all the updates as of today but this is still not fixed.. plymouth-scripts-0.6.0-0.2008.10.23.2.fc10.i386 plymouth-plugin-spinfinity-0.6.0-0.2008.10.23.2.fc10.i386 plymouth-plugin-solar-0.6.0-0.2008.10.23.2.fc10.i386 plymouth-plugin-label-0.6.0-0.2008.10.23.2.fc10.i386 plymouth-utils-0.6.0-0.2008.10.23.2.fc10.i386 plymouth-gdm-hooks-0.6.0-0.2008.10.23.2.fc10.i386 plymouth-libs-0.6.0-0.2008.10.23.2.fc10.i386 plymouth-0.6.0-0.2008.10.23.2.fc10.i386 Did you rebuild the initrd?
> rm -f /boot/initrd-{kernelversion}.img
> mkinitrd /boot/initrd-{kernelversion}.img {kernel version}
I just verified that this is fixed. 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 2.6.27.4-58 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? 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" 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. |