using plymouth for a little more than boot animations
Charlie Brej
plymouth at brej.org
Thu Jun 11 10:15:23 PDT 2009
Daniel Drake wrote:
> Hi,
>
> How heavily is plymouth tied into the standard boot process, from both
> the technical and design-level standpoints?
>
> We're considering using it for OLPCs boot animation but we have some
> extra requirements.
>
> We have a security system implemented in the initramfs, and one part of
> this is tasked with retreiving an activation lease (which basically is a
> signature which allows the system to boot for a certain number of days).
> It takes a little while to obtain this lease and has a
> (framebuffer-based) GUI on top of it.
>
> I'll try to explain in more detail:
> All this happens very early in the boot sequence -- before starting the
> boot animation, before starting any init scripts etc.
>
> The GUI comes up, with an XO icon in the center of the screen. The
> serial number of the laptop is printed immediately below.
> On the next "line" there are 3 icons, greyed out to begin with:
> 1. USB
> 2. SD
> 3. Wireless
>
> The system starts looking for a lease on any attached USB storage
> devices. While doing this, it blinks the USB icon on and off.
> If not found on USB, it then tries to look for a lease on a SD card, and
> blinks the SD card icon during this process.
> If not found on USB or SD, it then tries to find a lease from a school
> server connected to an open wireless access point, or from a lease
> server running on the OLPC mesh channels, blinking the LEDs in the
> process.
>
> If a lease was not found, it then paints a new screen with the XO figure
> removed and the message "activation lease not found" and shuts down
> after about 2 minutes.
>
> If a lease was found, it is installed to the appropriate location and
> then the system boot process is started (init is started, standard boot
> animation is started, etc).
>
>
> How feasible would it be to implement this with plymouth? Would drastic
> changes be needed to the core?
> I suppose it's not a showstopper for using plymouth if this isn't
> possible, as the 2 processes are effectively separate.. we could use our
> old bootanim code for activation GUI, and then finish up and execute
> plymouth once we're done.
>
> Thoughts?
>
> Thanks,
> Daniel
If you have a custom plugin then it can be done relatively easily. During the
boot progress the boot status is regularly updated with strings signifying what
is happening. The plugins can listen to these if they choose to but they are
generally ignored in the current plugins, and are only used for calculating the
boot time estimation (see /var/lib/plymouth/boot-duration for string examples).
All you need to do is to send a status update with something like:
plymouth --update=Waiting_For_USB
plymouth --update=Waiting_For_SD
plymouth --update=Waiting_For_WiFi
plymouth --update=Waiting_Finished
plymouth --update=Waiting_Failed
and in the plugin fill the "update_status" function with the response in the
plugin you want depending on the update string.
More information about the plymouth
mailing list