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
