[Splashy-devel] Bug#486400: a hack that WORKS !!!

Eric Doviak eric at doviak.net
Fri Jul 4 02:39:17 UTC 2008


Luis Mondesi wrote:
> When $resume is not set, does Splashy start from initramfs init-top? 
> Why does Splashy starts "late"?


Hi Luis,

I ran some diagnostics using the hack that I sent yesterday.

Specifically, I ran "splashy_config -s kubuntusplashy" but I did NOT run 
"update-initramfs -u". That enables me to see when Splashy is running 
from the initial RAM disk and when it is running from the regular file 
system. When I see "debian-moreblue," then I know that Splashy is 
running from the initial RAM disk. When I see "kubuntusplashy," then I 
know that Splashy is running from the regular file system.

Or more simply: "'Debian' is right. 'Kubuntu' is wrong." ;-)


When I pass the arguments "vga=791 splashy", I see:

* Start-up  -- Debian
* Shut-down -- Kubuntu

* Hibernate -- Kubuntu
* Resume    -- Debian  -- and then it freezes


When I pass the arguments "vga=791 splashy laptop", I see:

* Start-up  -- Kubuntu
* Shut-down -- Kubuntu

* Hibernate -- Kubuntu
* Resume    -- Debian  -- resumes successfully


==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==


IMPLICATION #1

Those tests tell me that the line:

test $LAPTOP != "true" || if [ ! -z "${resume}" ]; then SPLASH=false ; fi

always evaluates to "SPLASH=false" because "${resume}" is never zero in 
length. Then when the script reads:

test $SPLASH = "true" || exit

it exits.

When the "laptop" kernel argument is passed during start-up, Splashy 
starts when the initial RAM disk quits and the regular file system takes 
over. The Kubuntu splash screen at start-up confirms this.

For further confirmation, I also paid very close attention to the boot 
messages that I saw during start-up. Here (more or less) are the last 
lines that I saw prior to Splashy starting:

Running scripts/init-bottom
Done.
INIT version 2.86 Booting
* (Re)generating splash steps for
* rc2.d ...
* rc0.d ...
* rc6.d ...
Starting boot manager Splashy
Splashy ERROR connection refused
Splashy ERROR connection refused

I think the "connection refused" messages occur because it's trying to 
connect to a running version of Splashy (but none is running, of course).


==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==


IMPLICATION #2

OK, so what does this mean in terms of the "resume bug?" Why doesn't 
Splashy allow my computer to resume from hibernation without my hack?

In my amateur opinion, there are two ways of finding a "real solution."

One way is to determine what "${resume}" should look like when the 
system is starting-up and what it should look like when it is resuming. 
Once we determine that, we can have the "init-top/splashy" script 
perform the appropriate tests. My hack simply doesn't perform the 
correct test. "${resume}" is always non-zero in length.

The other way is to fix the connection between the part of Splashy that 
runs immediately upon boot and the part of Splashy that runs when the 
resume process begins. The fact that the Debian splash screen always 
appeared during resume (i.e. when I passed "vga=791 splashy" and when I 
passed "vga=791 splashy laptop") indicates that this connection occurs 
entirely within the initial RAM disk.


==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==


That's about all I can think of. I hope this helps and I apologize if 
I'm driving you nuts about this bug.

Have a great weekend,
- Eric


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/splashy-devel/attachments/20080703/dca74ca1/attachment.htm 


More information about the Splashy-devel mailing list