UbuntuWiki:UsplashInitramfs

{{#ifexist: :UbuntuWiki:UsplashInitramfs/zh | | {{#ifexist: UbuntuWiki:UsplashInitramfs/zh | | {{#ifeq: {{#titleparts:UbuntuWiki:UsplashInitramfs|1|-1|}} | zh | | }} }} }} {{#ifeq: {{#titleparts:UbuntuWiki:UsplashInitramfs|1|-1|}} | zh | | }}

• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/usplash-initramfs
• Created: Date(2005-11-03T16:46:13Z) by AdamConrad
• Contributors: AdamConrad
• Packages affected:

Summary

initramfs currently doesn't output to the progress bar in usplash, only to the text output area. We would prefer it if it would do both.

Rationale

This will become more important if usplash grows a quiet/notext option, and you lose all text feedback. It's also just prettier and shinier to do this "right".

Use cases

• Bob boots his computer and sees feedback, and this makes him happy. Go Bob.
• Jane boots a LiveCD and is terribly excited about all the wonderful progress bar feedback while she waits for it to load.

Implementation

We will dedicate an arbitrary ganularity of percentage ticks (probably just one percent per tick) to each output step (both quiet and not) in initramfs, incrementing a tick counter each time, then pass that count to init/rc when we hand off control (by dumping our current state in /dev/initramfs/), so it knows where to begin from and the bar won't accidentally jump.

This way, we get more ticks in initramfs as it is asked to perform more actions (dmsetup, very long livecd boot process, etc), rather than only dedicating a specific percentage of the boot process to initramfs.

MattZimmerman: this approach is sensitive to the number of actions performed in initramfs. Currently, there are only a small number of logical steps, so the amount of progress displayed will be very small. If the number of steps were to grow dramatically, this would then require that the progress indication be scaled accordingly anyway.

What does this approach buy us over the existing one used in userland? It already addresses the two points you mention above (where to begin, no jumping), and is much simpler.

A simple interface will also be provided so that things that don't want to use LSB-style output (which may be the case for the LiveCD) can arbitrarily tick the progress bar without having to worry about tracking the current progress, as initramfs will keep track of this internally for you. According to ColinWatson, the LiveCD won't really want/need more than 20 or 30 ticks, so while this hack isn't ideal, it will server our purposes well for now, avoiding a usplash rewrite during a short feature implementation cycle.

MattZimmerman: likewise here, the same mechanism would work equally well for the live CD without additional considerations.

Outstanding issues

For dapper+1, usplash will need some deeper hacking, involving making it actually aware of what a progress bar IS (currently, it just draws the bar at the length you tell it to; simple, but not very bright), so it can save its own state, and never accidentally go backwards if we mess up. For now, we're more interested in making things pretty and functional than rewriting them to make them "right".

---