Bug#486400:
It seems that starting splashy later in the boot process caused other problems. After moving splashy script back to init-top, I had not experienced bug #505270, nor #505291 Also, I solved this bug on some of my machines (others resume perfectly) by setting 'early writeout' to 'no' in /etc/uswsusp.conf, so maybe it's not needed to start splashy so late. Best regards, Benoît Laniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#486400: splashy does or doesn't work with hibernation ??
On Sun, 2008-10-26 at 21:50 -0400, Eric Doviak wrote: Hi Luis, Tim and Yves-Alexis, [snip] Because I'm curious ... What change was made that corrected Splashy's behavior? Tim changed the order at which Splashy is executed during resume to allow uswsusp to start first. We will release 0.3.11 which is a complete fix for this issue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: it is working now
I confirm that on all three machines I could test on, this bug is no longer occuring. All three machines resumed successfully from suspend and hibernate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: splashy does or doesn't work with hibernation ??
Hi Yves-Alexis, I am the person who originally submitted the bug report on Splashy's troubles with hibernation. I encountered the problem a few months ago on a Dell Latitude. Shortly thereafter, several other people wrote in to say that they were experiencing similar difficulties. At the moment, I am away from home working on a (recently acquired) Compaq Evo N410c. I just installed Splashy on this machine and it works perfectly with kernels 2.6.25 and 2.6.26. To be more precise, I had no difficulty resuming after calling /usr/sbin/hibernate nor did I have any difficulty resuming after calling /usr/sbin/s2disk When I return home tomorrow, I will reinstall and test Splashy on my Dell Latitude, let you know if it works and provide you with some feedback. Hopefully, everything will work and you will get some cookies from the Bug Sprint! Cheers, - Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: splashy does or doesn't work with hibernation ??
Hi Luis, Tim and Yves-Alexis, I received the notice that the Splashy hibernate bug has been closed, but I promised to follow up, so I'm writing to follow up. I just reinstalled and tested Splashy on my Dell Latitude C510. It works fine now. Because I'm curious ... What change was made that corrected Splashy's behavior? Thanks for your time and attention to this issue and -- most importantly -- thanks for taking the time to add a touch of beauty to my Debian machines. - Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: Status for this bug?
Hi, I was “assigned” the RC bug as part of BugSprint (http://wiki.debian.org/BugSprint). Looking at the bug log, it seems there was a solution back in july, which was implemented in slashy 0.3.12. But this didn't fix the problem. What is the current status of the bug, and what are the conclusions? It seems some info went on private mails, could they be published so one can work on the issue? Cheers, -- Yves-Alexis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: Not reproducible
Ok, I fail to reproduce this on at least two boxes, a desktop and a laptop. In both case, resume from hibernation works perfectly. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#486400:
I will try again to reproduce it three machines I have running Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: [Splashy-devel] Bug#486400: Bug#486400: Splashy works with hibernation, but ...
On Mon, Oct 13, 2008 at 6:13 AM, Tim Dijkstra [EMAIL PROTECTED] wrote: Luis, Unfortunately I haven't looked at splashy (or any other FOSS project for that matter) for a while, but I noticed this bug is RC. The bug log shows you've been commenting on it, do you know the status? Hey Tim, We tried to fix this in various ways from Splashy's end but we were not successful. It looks like uswsusp starts (dfb init) the framebuffer again when resuming at boot. Meaning, /sbin/splashy starts from initramfs and later uswsusp starts libsplashy again. We weren't sure how to go about making both of them work. If you can point me in the right direction I can implement a fix. (Not sure about uswsusp as I have never seen the source code for it -- yet.) -- )(- Luis Mondesi Maestro Debiano - START ENCRYPTED BLOCK (Triple-ROT13) -- Gur Hohagh [Yvahk] qvfgevohgvba oevatf gur fcvevg bs Hohagh gb gur fbsgjner jbeyq. - END ENCRYPTED BLOCK (Triple-ROT13) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: [Splashy-devel] Bug#486400: Bug#486400: Splashy works with hibernation, but ...
Luis Mondesi schreef: On Mon, Oct 13, 2008 at 6:13 AM, Tim Dijkstra [EMAIL PROTECTED] wrote: We tried to fix this in various ways from Splashy's end but we were not successful. It looks like uswsusp starts (dfb init) the framebuffer again when resuming at boot. Meaning, /sbin/splashy starts from initramfs and later uswsusp starts libsplashy again. When I was first looking at this, I made uswsusp start resume (and libsplashy) from initramfs _before_ the regular splashy. That way, there would never be two initialisations. The only drawback is that we have to start splashy somewhat later in the boot process. So apparently splashy's initscript was moved up in priority since the last time I looked at it. We weren't sure how to go about making both of them work. If you can point me in the right direction I can implement a fix. (Not sure about uswsusp as I have never seen the source code for it -- yet.) I'm planning to look at this bug wednesday evening. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: [Splashy-devel] Bug#486400: Bug#486400: Splashy works with hibernation, but ...
Luis, Unfortunately I haven't looked at splashy (or any other FOSS project for that matter) for a while, but I noticed this bug is RC. The bug log shows you've been commenting on it, do you know the status? grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: splashy: hibernation broken in stock 2.6.26-686 or custom kernel with crypt mapper drives
Package: splashy Version: 0.3.10-2 Followup-For: Bug #486400 I also encounter the same problem using either the stock kernel for 2.6.26 or my own custom kernel when resuming from hibernation. The normal boot-up splash screen works fine and prompts me for the passwords to the encrypted partitions. (Wow that's cool.) But then it hangs. The progress bar is not filled out and does not do anything. The system does not respond. I did not try magic sysrq but all key combinations to restart or switch terminals or get verbose splashy output (f2) do not work. I end up having to power-cycle the machine to restart. This results in data corruption and fsck always has to clear one orphaned inode. Thanks. --mark-- -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages splashy depends on: ii initramfs-tools0.92f tools for generating an initramfs ii libc6 2.7-13GNU C Library: Shared libraries ii libdirectfb-1.0-0 1.0.1-9 direct frame buffer graphics - sha ii libgcc11:4.3.1-9 GCC support library ii libglib2.0-0 2.16.4-2 The GLib library of C routines ii libmagic1 4.25-1File type determination library us ii libsplashy10.3.10-2 Library to draw splash screen on b ii lsb-base 3.2-19Linux Standard Base 3.2 init scrip ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime splashy recommends no packages. Versions of packages splashy suggests: ii console-common0.7.79 basic infrastructure for text cons pn splashy-themesnone (no description available) pn upstart none (no description available) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: followup re slighly working condition
Also see 497313. When splashy was installed running under my custom kernel, initramfs for the stock kernel was not rebuilt due to that bug. So when I booted under the stock kernel, splashy never loaded until after I unlocked the encrypted drives and normal boot began. Resume from hibernation worked under this scenario. VESA console prompted for the drive passwords, then resume began, then the splashy resume screen loaded and the progress bar worked, then my gnome screensaver password prompt came up. So it seems like the boot splash needs to turn itself off and restore to the text console immediately before resume from hibernation begins. Then the hibernation screen will load correctly. Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: Still in 0.3.11
On Wed, Aug 6, 2008 at 1:36 PM, Fabio Pugliese Ornellas [EMAIL PROTECTED] wrote: Since you already know exactly what the problem is, please let me know where it is, so I won't waste time on something already known. Please drop me an email with it, and we keep in touch. Ok, I'll send you the information on a private email to keep the noise from hitting this bug report. -- )(- Luis Mondesi Maestro Debiano - START ENCRYPTED BLOCK (Triple-ROT13) -- Gur Hohagh [Yvahk] qvfgevohgvba oevatf gur fcvevg bs Hohagh gb gur fbsgjner jbeyq. - END ENCRYPTED BLOCK (Triple-ROT13) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: Still in 0.3.11
This is a very important bug; if you can get a fix for it, got for it. I have not been able to do any FOSS work these last weekends. I guess we will just miss Lenny... On Fri, Aug 1, 2008 at 2:35 PM, Fabio Pugliese Ornellas [EMAIL PROTECTED] wrote: If by any means I can help, please let me know. I was about to start debugging it today... -- )(- Luis Mondesi Maestro Debiano - START ENCRYPTED BLOCK (Triple-ROT13) -- Gur Hohagh [Yvahk] qvfgevohgvba oevatf gur fcvevg bs Hohagh gb gur fbsgjner jbeyq. - END ENCRYPTED BLOCK (Triple-ROT13) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: Still in 0.3.11
On Aug 1, 2008, at 12:47 AM, Fabio Pugliese Ornellas [EMAIL PROTECTED] wrote: Hello, I have just tested the newer 0.3.11 version asn my Asus EEE PC 900 still freezes if I use uswsusp + splashy, the bug still exists. If I find time on the following days, I'll post here my findings on the topic. Yeah we are working on a quick release of 0.3.12 to address this and other pesky bugs. Sit tight. So far it looks like removing chvt 8 from initramfs and Splashy fixes a few of this issues. Exiting when $resume is set proved not to be the right solution. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: Still in 0.3.11
I had a look at uswsusp suspend command (called from within initrd) and saw that it do interact with the framebuffer and makes some splash-related initialization. Would'nt that be messing up with splashy? Shouldn't its code get reviewed? Or you are sure the issue is splashy related only? Fabio Pugliese Ornellas E-Mail: [EMAIL PROTECTED] gTalk: [EMAIL PROTECTED] ICQ: 6516089 MSN: [EMAIL PROTECTED] WWW: http://ornellas.apanela.com/ On Fri, Aug 1, 2008 at 10:46, Luis Mondesi [EMAIL PROTECTED] wrote: On Aug 1, 2008, at 12:47 AM, Fabio Pugliese Ornellas [EMAIL PROTECTED] wrote: Hello, I have just tested the newer 0.3.11 version asn my Asus EEE PC 900 still freezes if I use uswsusp + splashy, the bug still exists. If I find time on the following days, I'll post here my findings on the topic. Yeah we are working on a quick release of 0.3.12 to address this and other pesky bugs. Sit tight. So far it looks like removing chvt 8 from initramfs and Splashy fixes a few of this issues. Exiting when $resume is set proved not to be the right solution.
Bug#486400: Still in 0.3.11
On Aug 1, 2008, at 11:55 AM, Fabio Pugliese Ornellas [EMAIL PROTECTED] wrote: I had a look at uswsusp suspend command (called from within initrd) and saw that it do interact with the framebuffer and makes some splash-related initialization. Would'nt that be messing up with splashy? Shouldn't its code get reviewed? Or you are sure the issue is splashy related only? Yes. We know exactly what the problem is. We are working on a solution for it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: Still in 0.3.11
If by any means I can help, please let me know. I was about to start debugging it today... Fabio Pugliese Ornellas E-Mail: [EMAIL PROTECTED] gTalk: [EMAIL PROTECTED] ICQ: 6516089 MSN: [EMAIL PROTECTED] WWW: http://ornellas.apanela.com/ On Fri, Aug 1, 2008 at 14:40, Luis Mondesi [EMAIL PROTECTED] wrote: On Aug 1, 2008, at 11:55 AM, Fabio Pugliese Ornellas [EMAIL PROTECTED] wrote: I had a look at uswsusp suspend command (called from within initrd) and saw that it do interact with the framebuffer and makes some splash-related initialization. Would'nt that be messing up with splashy? Shouldn't its code get reviewed? Or you are sure the issue is splashy related only? Yes. We know exactly what the problem is. We are working on a solution for it.
Bug#486400: Still in 0.3.11
Hello, I have just tested the newer 0.3.11 version asn my Asus EEE PC 900 still freezes if I use uswsusp + splashy, the bug still exists. If I find time on the following days, I'll post here my findings on the topic. Bye. Fabio Pugliese Ornellas E-Mail: [EMAIL PROTECTED] gTalk: [EMAIL PROTECTED] ICQ: 6516089 MSN: [EMAIL PROTECTED] WWW: http://ornellas.apanela.com/
Bug#486400: Grave bug
Laptop top users can't really use splashy because of this bug; I'm surprised this is not an RC bug. I wouldn't want this to be in a stable release because I'm a Debian enthusiast. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: [Splashy-devel] Bug#486400: Grave bug
This is fixed in Git and it will be released as 0.3.11 shortly. The debian package for it will follow shortly after that. On Fri, Jul 25, 2008 at 9:43 AM, Tim Richardson [EMAIL PROTECTED] wrote: Laptop top users can't really use splashy because of this bug; I'm surprised this is not an RC bug. I wouldn't want this to be in a stable release because I'm a Debian enthusiast. ___ Splashy-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/splashy-devel -- )(- Luis Mondesi Maestro Debiano - START ENCRYPTED BLOCK (Triple-ROT13) -- Gur Hohagh [Yvahk] qvfgevohgvba oevatf gur fcvevg bs Hohagh gb gur fbsgjner jbeyq. - END ENCRYPTED BLOCK (Triple-ROT13) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: resume fails due to splashy, uswsusp, gdm, intel graphics
Package: splashy Version: 0.3.10-2 Followup-For: Bug #486400 splashy works for a normal boot. it also displays during a suspend to disk (hibernate). But upon resume, the splash screen appears, and there is some disk activity, but then the resume just stops. I can get no response from the machine. It is a Dell D420 notebook with intel graphics. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages splashy depends on: ii initramfs-tools0.92e tools for generating an initramfs ii libc6 2.7-10GNU C Library: Shared libraries ii libdirectfb-1.0-0 1.0.1-9 direct frame buffer graphics - sha ii libgcc11:4.3.1-2 GCC support library ii libglib2.0-0 2.16.3-2 The GLib library of C routines ii libmagic1 4.24-4File type determination library us ii libsplashy10.3.10-2 Library to draw splash screen on b ii lsb-base 3.2-12Linux Standard Base 3.2 init scrip ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime splashy recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: a hack that WORKS !!!
On Jul 3, 2008, at 0:38, Eric Doviak [EMAIL PROTECTED] wrote:
Hi Luis,
After days of struggling with the resume bug, I have finally found
a hack that fixes the problem. It's not ideal, but it squashes the
bug and it provides laptop users with a boot splash without
compromising the quality that desktop users currently enjoy.
Specifically, I started by adding the following code after line 44
of the /usr/share/initramfs-tools/scripts/init-top/splashy file:
if [ ! -z ${resume} ]; then
SPLASH=false
fi
That condition allows me to resume from hibernation, but it causes
Splashy to start rather late in the boot sequence. Specifically, it
starts when the init-bottom scripts are run. Adding such a
condition to Splashy would be useful to laptop users, but the late
start would degrade Splashy in the eyes of desktop users.
I see no reason why desktop users should be penalized just to make
laptop users happy, so I created another condition that only runs
the condition above if laptop is passed as a kernel argument. The
code is below.
By creating a laptop kernel argument, desktop users would continue
to see a splash screen early in the boot sequence and laptop users
would get a user-space boot splash system that works during start-
up, shutdown, suspend and resume.
It certainly isn't the ideal solution that I had in mind a few days
ago (when I thought we could provide everyone with a splash screen
that starts early in the boot sequence), but it squashes the bug and
it makes Splashy usable for laptop users. Importantly, it achieves
those objectives without degrading Splashy's performance on desktop
computers.
Let me know if there's anything else I can do,
- Eric
SPLASH=false
LAPTOP=false
SINGLE=false
FBMODESET=false
for x in $(cat /proc/cmdline); do
case $x in
single)
SINGLE=true
;;
splash)
SPLASH=true
;;
laptop)
LAPTOP=true
;;
nosplash)
SPLASH=false
;;
vga=*|video=*)
FBMODESET=true
;;
esac
done
test $LAPTOP != true || if [ ! -z ${resume} ]; then
SPLASH=false ; fi
test $SINGLE = false || exit
test $SPLASH = true || exit
test $FBMODESET = true || exit
When $resume is not set, does Splashy start from initramfs init-top?
Why does Splashy starts late?
Bug#486400: a hack that WORKS !!!
Eric Doviak wrote:
Luis Mondesi wrote:
When $resume is not set, does Splashy start from initramfs init-top?
Why does Splashy starts late?
When $resume is not set, Splashy does not start from init-top. It
appears to start from init-bottom. My guess is that Splashy starts
late because the script is waiting for information about $resume.
I tried adding the case structure from local-premount/resume, but
I didn't have any luck.
- Eric
Just to clarify ... Simply testing this condition:
if [ ! -z ${resume} ]; then
SPLASH=false
fi
causes Splashy to start late. That's why I created the laptop kernel
argument.
When I tested my hack by not passing the laptop kernel argument,
Splashy starts from init-top (like it is supposed to), but I can only
start-up, shutdown and suspend. I cannot resume. The laptop kernel
argument fixes the resume bug, but it causes Splashy to start late on
start-up.
- Eric
Bug#486400: a hack that WORKS !!!
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
Bug#486400: a hack that WORKS !!!
On Thu, Jul 3, 2008 at 10:39 PM, Eric Doviak [EMAIL PROTECTED] wrote: 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: if you pass splashy then Splashy won't work. You need to pass splash as a kernel parameter. Is this a typo on this email or are you actually using this keyword? Back to the drawing board? Thanks for your help on this though. I'm trying to reproduce this on my own system. -- )(- Luis Mondesi Maestro Debiano - START ENCRYPTED BLOCK (Triple-ROT13) -- Gur Hohagh [Yvahk] qvfgevohgvba oevatf gur fcvevg bs Hohagh gb gur fbsgjner jbeyq. - END ENCRYPTED BLOCK (Triple-ROT13) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: a hack that WORKS !!!
Yet another typo! I forgot to send this to Debian Bugs! Sorry for the double email! - Eric Luis Mondesi wrote: if you pass splashy then Splashy won't work. You need to pass splash as a kernel parameter. Is this a typo on this email or are you actually using this keyword? Back to the drawing board? Thanks for your help on this though. I'm trying to reproduce this on my own system. Whoops! The typo was in my message. The typo was NOT in my /boot/grub/menu.lst I was passing vga=791 splash and vga=791 splash laptop when I ran the tests. - Eric here's the relevant section of my /boot/grub/menu.lst title Debian GNU/Linux, kernel 2.6.24-1-686 root(hd0,1) kernel /boot/vmlinuz-2.6.24-1-686 root=/dev/hda2 ro vga=791 splash laptop initrd /boot/initrd.img-2.6.24-1-686 title Debian GNU/Linux, kernel 2.6.24-1-686 (single-user mode) root(hd0,1) kernel /boot/vmlinuz-2.6.24-1-686 root=/dev/hda2 ro single initrd /boot/initrd.img-2.6.24-1-686 title Debian GNU/Linux, kernel 2.6.21.7-emd root(hd0,1) kernel /boot/vmlinuz-2.6.21.7-emd root=/dev/hda2 ro vga=791 splash laptop initrd /boot/initrd.img-2.6.21.7-emd title Debian GNU/Linux, kernel 2.6.21.7-emd (single-user mode) root(hd0,1) kernel /boot/vmlinuz-2.6.21.7-emd root=/dev/hda2 ro single initrd /boot/initrd.img-2.6.21.7-emd
Bug#486400: a hack that WORKS !!!
Hi Luis,
After days of struggling with the resume bug, I have finally found a
hack that fixes the problem. It's not ideal, but it squashes the bug and
it provides laptop users with a boot splash without compromising the
quality that desktop users currently enjoy.
Specifically, I started by adding the following code after line 44 of
the /usr/share/initramfs-tools/scripts/init-top/splashy file:
if [ ! -z ${resume} ]; then
SPLASH=false
fi
That condition allows me to resume from hibernation, but it causes
Splashy to start rather late in the boot sequence. Specifically, it
starts when the init-bottom scripts are run. Adding such a condition
to Splashy would be useful to laptop users, but the late start would
degrade Splashy in the eyes of desktop users.
I see no reason why desktop users should be penalized just to make
laptop users happy, so I created another condition that only runs the
condition above if laptop is passed as a kernel argument. The code is
below.
By creating a laptop kernel argument, desktop users would continue to
see a splash screen early in the boot sequence and laptop users would
get a user-space boot splash system that works during start-up,
shutdown, suspend and resume.
It certainly isn't the ideal solution that I had in mind a few days ago
(when I thought we could provide everyone with a splash screen that
starts early in the boot sequence), but it squashes the bug and it makes
Splashy usable for laptop users. Importantly, it achieves those
objectives without degrading Splashy's performance on desktop computers.
Let me know if there's anything else I can do,
- Eric
SPLASH=false
LAPTOP=false
SINGLE=false
FBMODESET=false
for x in $(cat /proc/cmdline); do
case $x in
single)
SINGLE=true
;;
splash)
SPLASH=true
;;
laptop)
LAPTOP=true
;;
nosplash)
SPLASH=false
;;
vga=*|video=*)
FBMODESET=true
;;
esac
done
test $LAPTOP != true || if [ ! -z ${resume} ]; then SPLASH=false ; fi
test $SINGLE = false || exit
test $SPLASH = true || exit
test $FBMODESET = true || exit
Bug#486400: [Splashy-devel] Bug#486400: Splashy works with hibernation, but ...
Just to clarify (in case my previous message was unclear) ... In the /usr/share/initramfs-tools/scripts/init-top file, the lines: for x in $(cat /proc/cmdline); do case $x in single) SINGLE=true ;; splash) SPLASH=true ;; nosplash) SPLASH=false ;; vga=*|video=*) FBMODESET=true ;; esac done should be immediately followed by a test to see if a resume image is available. If one is available, then SPLASH=false Hope this helps, - Eric
Bug#486400: [Splashy-devel] Bug#486400: Splashy works with hibernation, but ...
On Tue, Jul 1, 2008 at 1:48 AM, Eric Doviak [EMAIL PROTECTED] wrote:
I think I know how to fix this bug. ... Of course, knowing how to fix the
bug and being able to fix the bug are two totally different things.
If I understand correctly ... When the vga=791 splash arguments are passed
to the kernel, some of the first scripts that the initial RAM disk runs is a
script that starts the framebuffer (init-top/framebuffer) and a script
that checks to see if Splashy should start (init-top/splashy).
Later, the initial RAM disk checks to see if there's a hibernation image
from which to resume local-premount/{resume,uswsusp}. If it detects a
resume image, then it loads the resume image. The trouble then occurs
because the resume image also contains Splashy.
So if you could move (some of) the checks for the resume image into the the
init-top/splashy script and cause the init-top/splashy script to exit if
it detects a resume image, then:
on a boot following a complete shutdown, the init-top/splashy script would
start Splashy
on a boot following hibernation, the init-top/splashy script would exit
and allow the resume features to start Splashy
That would provide the best of both worlds! A userspace bootsplash that
starts early in the boot sequence and a bootsplash that is capable of
working with hibernation!
I hope this helps! Please let me know if there's anything else I can do!
This is perfect!
Thanks, I'll commit a fix to the repository today and ask the Debian
developers to upload this as 0.3.10-3.
You saved me a lot of time ;)
--
)(-
Luis Mondesi
Maestro Debiano
- START ENCRYPTED BLOCK (Triple-ROT13) --
Gur Hohagh [Yvahk] qvfgevohgvba oevatf gur fcvevg bs Hohagh gb gur
fbsgjner jbeyq.
- END ENCRYPTED BLOCK (Triple-ROT13) --
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: splashy doesn't work with hibernation
Package: splashy Version: 0.3.10-2 Followup-For: Bug #486400 Maybe I was wrong. I actually disabled splashy altogether for the moment. I remember that removing splashy from grub but leaving it on in uswsusp worked. I am not so sure anymore for the combination with splashy being on in grub but not in uswsusp. I might give it a second try when I find the time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: [Splashy-devel] Bug#486400: Splashy works with hibernation, but ...
I think I know how to fix this bug. ... Of course, knowing how to fix
the bug and being able to fix the bug are two totally different things.
If I understand correctly ... When the vga=791 splash arguments are
passed to the kernel, some of the first scripts that the initial RAM
disk runs is a script that starts the framebuffer
(init-top/framebuffer) and a script that checks to see if Splashy
should start (init-top/splashy).
Later, the initial RAM disk checks to see if there's a hibernation image
from which to resume local-premount/{resume,uswsusp}. If it detects a
resume image, then it loads the resume image. The trouble then occurs
because the resume image also contains Splashy.
So if you could move (some of) the checks for the resume image into the
the init-top/splashy script and cause the init-top/splashy script to
exit if it detects a resume image, then:
* on a boot following a complete shutdown, the init-top/splashy
script would start Splashy
* on a boot following hibernation, the init-top/splashy script
would exit and allow the resume features to start Splashy
That would provide the best of both worlds! A userspace bootsplash that
starts early in the boot sequence and a bootsplash that is capable of
working with hibernation!
I hope this helps! Please let me know if there's anything else I can do!
Thanks,
- Eric
Bug#486400: Splashy works with hibernation, but ...
This is interesting: Splashy really does work with hibernation! I have Splashy (almost) completely configured. I left the splash = y line in my /etc/uswsusp.conf file and I set the vga=791 argument -- but NOT the splash argument -- on the kernel line of my /boot/grub/menu.lst file. When shutting down and when starting after a complete shutdown, I obviously do not see the splash screen, but when I hibernate or when I resume from hibernation, I see the splash screen and it works rather well. I really hope you can fix this bug in time for Lenny's release and I'd like to help you if I can. I've been looking at Splashy and uswsusp's source code. I'm trying to understand it, but I don't know C, so it ain't easy. Nonetheless, if there's anything I can do to help, please let me know. Thanks, - Eric Here's my /etc/uswsusp.conf file: # /etc/uswsusp.conf(8) -- Configuration file for s2disk/s2both resume device = /dev/hda5 splash = y compress = y early writeout = y image size = 488091648 RSA key file = /etc/uswsusp.key shutdown method = platform and here are the relevant lines from my /boot/grub/menu.lst file: title Debian GNU/Linux, kernel 2.6.24-1-686 root(hd0,1) kernel /boot/vmlinuz-2.6.24-1-686 root=/dev/hda2 ro vga=791 initrd /boot/initrd.img-2.6.24-1-686
Bug#486400: splashy doesn't work with hibernation
Marcel Dischinger wrote: I have the same issue here. I found that the problem only occurs if splashy is activated in grub (add splash as a kernel parameter) _and_ in uswsusp. Then, splashy hangs while resuming from hibernation. If I either remove splashy from grub or uswsusp, it works just fine. What do you mean when you say: If I ... remove splashy from ... uswsusp, it works just fine. ??? I've tried adding splash = n to /etc/uswsusp.conf and regenerating the initial RAM disk, but that doesn't stop Splashy from hanging while resuming from hibernation. Thanks, - Eric
Bug#486400: splashy doesn't work with hibernation
Package: splashy Version: 0.3.10-2 Followup-For: Bug #486400 I have the same issue here. I found that the problem only occurs if splashy is activated in grub (add splash as a kernel parameter) _and_ in uswsusp. Then, splashy hangs while resuming from hibernation. If I either remove splashy from grub or uswsusp, it works just fine. BTW, Linux does not hang, resume actually works. I can log in using ssh, all processes are running normal. I do not know why the desktop (KDE in my case) does not come up again, but splashy stays (with no progress in the progress bar). Is splashy messing up the frame buffer somehow? Because I do not see a splash process running, though it is displayed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: [Splashy-devel] Bug#486400: splashy doesn't work with hibernation
On Thu, Jun 26, 2008 at 11:08 AM, Marcel Dischinger [EMAIL PROTECTED] wrote: Package: splashy Version: 0.3.10-2 Followup-For: Bug #486400 I have the same issue here. I found that the problem only occurs if splashy is activated in grub (add splash as a kernel parameter) _and_ in uswsusp. Then, splashy hangs while resuming from hibernation. If I either remove splashy from grub or uswsusp, it works just fine. BTW, Linux does not hang, resume actually works. I can log in using ssh, all processes are running normal. I do not know why the desktop (KDE in my case) does not come up again, but splashy stays (with no progress in the progress bar). Is splashy messing up the frame buffer somehow? Because I do not see a splash process running, though it is displayed. I do not know enough about uswsusp to be able to answer this but I'll try to get the attention of the people that does, especially Tim. It might be that libdirectfb is initialized twice (as somebody has already suggested). uswsusp needs to be recompiled against libsplashy1 and perhaps detect when Splashy is running before attempting to re-init the framebuffer... This is just a wild guess. -- )(- Luis Mondesi Maestro Debiano - START ENCRYPTED BLOCK (Triple-ROT13) -- Gur Hohagh [Yvahk] qvfgevohgvba oevatf gur fcvevg bs Hohagh gb gur fbsgjner jbeyq. - END ENCRYPTED BLOCK (Triple-ROT13) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: splashy doesn't work with hibernation
Package: splashy Version: 0.3.10-1 Same problem with my laptop using splashy and uswsusp. System freezes during resume if splashy is in graphical mode. If I press F2 in the very early stage of the resume, splashy goes to verbose mode and the system resumes well from hibernation. But If I wait too much in graphical mode then I can't get the control of the machine anymore and I have to shutdown brutally. Ask me for futher information if needed. Regards, CA --- System information. --- Architecture: i386 Kernel: Linux 2.6.24-1-686 Debian Release: lenny/sid 990 testing www.debian-multimedia.org 990 testing security.debian.org 990 testing debian.fastweb.it 500 unstabledebian.fastweb.it --- Package information. --- Depends (Version) | Installed =-+- libc6 (= 2.7-1) | 2.7-10 libdirectfb-1.0-0(= 1.0.1-9) | 1.0.1-9 libgcc1 (= 1:4.1.1-21) | 1:4.3.0-5 libglib2.0-0 (= 2.12.0) | 2.16.3-2 libmagic1 | 4.24-2 libsplashy1 | 0.3.10-1 zlib1g (= 1:1.1.4) | 1:1.2.3.3.dfsg-12 lsb-base | 3.2-12 initramfs-tools | 0.92b -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: splashy doesn't work with hibernation
Package: splashy Version: 0.3.10-1 Severity: normal I love watching Splashy's Debian-moreblue theme appear when I start my computer, but I'd also like to start my computer. Splashy works well on a clean boot, but it doesn't allow the computer to resume from hibernation. I've tried appending the line splash = y to my /etc/uswsusp.conf file and regenerating the initial RAM disk (with the update-initramfs -u command), but neither seem to work. For what it's worth, usplash appears to have the same bug (#468735 -- usplash does not work with hibernation). I do not know if they are related. Thanks, - Eric -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages splashy depends on: ii initramfs-tools0.92b tools for generating an initramfs ii libc6 2.7-10GNU C Library: Shared libraries ii libdirectfb-1.0-0 1.0.1-9 direct frame buffer graphics - sha ii libgcc11:4.3.0-5 GCC support library ii libglib2.0-0 2.16.3-2 The GLib library of C routines ii libmagic1 4.24-2File type determination library us ii libsplashy10.3.10-1 Library to draw splash screen on b ii lsb-base 3.2-12Linux Standard Base 3.2 init scrip ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime splashy recommends no packages. -- no debconf information -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages uswsusp depends on: ii debconf [debconf-2.0] 1.5.22 Debian configuration management sy ii libc6 2.7-10 GNU C Library: Shared libraries ii libgcc1 1:4.3.0-5 GCC support library ii libgcrypt11 1.4.1-1LGPL Crypto library - runtime libr ii liblzo2-2 2.03-1 data compression library ii libpci3 1:3.0.0-4 Linux PCI Utilities (shared librar ii libsplashy1 0.3.10-1 Library to draw splash screen on b ii libx86-1 0.99+ds1-2 x86 real-mode library Versions of packages uswsusp recommends: ii initramfs-tools 0.92b tools for generating an initramfs ii mount 2.13.1.1-1 Tools for mounting and manipulatin -- debconf information: uswsusp/suspend_loglevel: uswsusp/no_swap: uswsusp/resume_offset: uswsusp/early_writeout: true uswsusp/image_size: 121068584 uswsusp/snapshot_device: uswsusp/max_loglevel: uswsusp/shutdown_method: platform uswsusp/encrypt: false uswsusp/RSA_key_bits: 1024 * uswsusp/continue_without_swap: true uswsusp/compute_checksum: false uswsusp/no_snapshot: uswsusp/compress: true uswsusp/create_RSA_key: false uswsusp/RSA_key_file: /etc/uswsusp.key uswsusp/resume_device: /dev/hda5 uswsusp/splash: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
