Send plymouth mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freedesktop.org/mailman/listinfo/plymouth
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of plymouth digest..."
Today's Topics:
1. serial console detection (Daniel Drake)
2. using plymouth for a little more than boot animations
(Daniel Drake)
3. Re: using plymouth for a little more than boot animations
(Charlie Brej)
4. plymouth performance (Daniel Drake)
5. Re: serial console detection (Ray Strode)
6. Re: serial console detection (Daniel Drake)
----------------------------------------------------------------------
Message: 1
Date: Thu, 11 Jun 2009 17:16:51 +0100
From: Daniel Drake <[email protected]>
Subject: serial console detection
To: [email protected]
Message-ID: <1244737011.2344.9.ca...@polyethylene>
Content-Type: text/plain
Hi,
I'm investigating running plymouth on the F11 distribution we're making
for the XO-1.5.
The first problem I'm facing is with the check_for_consoles() function
in main.c.
OLPC boots with console=ttyS0,115200 console=tty0 with the intention of
sending boot messages over the serial console if it is plugged in, and
also booting as normal with tty0 being the primary console.
However, plymouth bails out with these parameters present, even if we
just have console=tty0 alone (the comment in that function suggests that
its trying to disable itself on a serial console, but it didn't even
check the console that it was being asked to work with...)
Why is it doing this?
Even if a serial console is present, surely you would still want to run
plymouth on the regular tty? (Well, OLPC would really like this at
least, as we specify on the kernel command line)
I'm happy to hack on this but need to understand the intentions first!
cheers,
Daniel
------------------------------
Message: 2
Date: Thu, 11 Jun 2009 17:41:38 +0100
From: Daniel Drake <[email protected]>
Subject: using plymouth for a little more than boot animations
To: [email protected]
Message-ID: <1244738498.2344.34.ca...@polyethylene>
Content-Type: text/plain
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
------------------------------
Message: 3
Date: Thu, 11 Jun 2009 18:15:23 +0100
From: Charlie Brej <[email protected]>
Subject: Re: using plymouth for a little more than boot animations
To: Daniel Drake <[email protected]>, [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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.
------------------------------
Message: 4
Date: Thu, 11 Jun 2009 19:13:29 +0100
From: Daniel Drake <[email protected]>
Subject: plymouth performance
To: [email protected]
Message-ID: <1244744009.2344.56.ca...@polyethylene>
Content-Type: text/plain
Hi,
I've done some timings of plymouth vs non-plymouth boots on my XO
laptops, to see how much of an impact it has on boot time.
I took each measurement 3 times and then averaged. All recorded times
were without much variance; these timings were reliable.
I measured by pausing OFW during boot, entering "boot", and then
starting a stopwatch at the same time as pressing enter to execute the
boot command.
On the XO-1 I stopped the stopwatch as soon as I saw the mouse cursor
(just before gdm comes up).
On the XO-1.5 I stopped the stopwatch as soon as I saw the text at the
center of the gdm login screen.
For the "without" tests, I removed the rhgb kernel parameter parameter
and added console=tty0
On the XO-1:
Without plymouth: 61.53 seconds bootup time
With plymouth: 79.82 seconds bootup time
+18.29 seconds increase, or 30% regression
On the XO-1.5:
Without plymouth: 24.78 seconds bootup time
With plymouth: 27.07 seconds bootup time
+2.29 seconds increase, or 10% regression
We have a similar problem with OLPC's boot animation code on the XO-1.
We recently found out that it slows down boot by about 15 seconds with
just a simple animation.
However, two superheroes came along and implemented an awesome new
algorithm which only redraws the parts of the screen that have changed
from the last frame. This completely cuts out the 15-second regression
to the point where when you measure timings like the above tests, it
often appears that it is tiny bit faster to boot *with* the animation...
I wonder if that could be implemented in plymouth. The code is here:
http://dev.laptop.org/git/users/bobbyp/bootanim/
Daniel
------------------------------
Message: 5
Date: Thu, 11 Jun 2009 14:30:28 -0400
From: Ray Strode <[email protected]>
Subject: Re: serial console detection
To: Daniel Drake <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
> I'm investigating running plymouth on the F11 distribution we're making
> for the XO-1.5.
>
> The first problem I'm facing is with the check_for_consoles() function
> in main.c.
>
> OLPC boots with console=ttyS0,115200 console=tty0 with the intention of
> sending boot messages over the serial console if it is plugged in, and
> also booting as normal with tty0 being the primary console.
>
> However, plymouth bails out with these parameters present, even if we
> just have console=tty0 alone (the comment in that function suggests that
> its trying to disable itself on a serial console, but it didn't even
> check the console that it was being asked to work with...)
>
> Why is it doing this?
There aren't particularly good reasons for doing it this way. The
main motivation was just that normally a user who wants a serial
console doesn't want a boot splash (say kernel developers or
whatever). It probably makes sense to tell people who don't splashes
to remove "splash" (or "rhgb") from their kernel command lines
instead.
Fixing it will require updating the splash plugins to support multiple
"windows". A window is just an abstraction over a serial console or
vt. Right now, only the details splash plugin has support.
If you want to look into it great! Otherwise file a bug at
bugs.freedesktop.org and I'll look into it.
--Ray
------------------------------
Message: 6
Date: Thu, 11 Jun 2009 19:42:07 +0100
From: Daniel Drake <[email protected]>
Subject: Re: serial console detection
To: Ray Strode <[email protected]>
Cc: [email protected]
Message-ID: <1244745727.2344.58.ca...@polyethylene>
Content-Type: text/plain
On Thu, 2009-06-11 at 14:30 -0400, Ray Strode wrote:
> Fixing it will require updating the splash plugins to support multiple
> "windows". A window is just an abstraction over a serial console or
> vt. Right now, only the details splash plugin has support.
>
> If you want to look into it great! Otherwise file a bug at
> bugs.freedesktop.org and I'll look into it.
OK, filed at.
https://bugs.freedesktop.org/show_bug.cgi?id=22239
Thanks,
Daniel
------------------------------
_______________________________________________
plymouth mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/plymouth
End of plymouth Digest, Vol 9, Issue 2
**************************************
