Thanks for sending me your initrd. I'm getting closer to fixing this
bug. It looks like the changes in the path for themes and default
theme has something to do with this and other crashes. We are now
using /usr to store themes and this is a separate partition for most
people. Also, the directory wasn't properly link in cpio when running
from initramfs.
We will need to ensure that splashy does read from the right path once
changed.
Expect a fix this weekend.
On Dec 9, 2008, at 7:10, tim richardson <[EMAIL PROTECTED]> wrote:
Tim,
Is it possible that your problem is related to /etc/splashy/
config.xml ?
Try copying this file to /root/config.xml and purging Splashy 0.3.10
(dpkg --purge splashy) (from Lenny) and installing the Sid version
(0.3.12), then copy your config.xml back to /etc/splashy.
Luis, I think you are following a false lead. See below for my
"clues", but first, I followed your request:
1) I reverted to 0.3.10 and verified that it worked.
Then, I copied config.xml as you suggested
2) I purged and went back to Sid. libsplashy and uswsusp were also
updated.
After the updgrade, I verified that the bug reappeared (splashy
flashes momentarily, and then it disappears, as described earlier in
the bug report)
Then I copied the saved config.xml to /etc/splashy
(Of course, bug 504389 appeared after going back to 0.3.12, for
which I have submitted a patch http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504389
)
3) The saved config file made no difference. The startup behavious
of 0.3.12 is still broken.
I actually see this on all three machines running Debian, one of
them being an AMD desktop with Nvidia video so it has nothing to do
with intel graphics.
**** My clues: **** :-)
It is very strange that a very simple fix solves the problem:
creating /etc/directfbrc and putting in a path to the log-file as I
described earlier.
That is, this content in /etc/directfbrc solves the problem.
log-file=/tmp/directfb.log
Move that file, and the bug reappears. 100% guaranteed. It also
fixes it on all three of my machines.
Clue part 2: change the log-file path to be /root/directfb.log and
the bug reappears.
So it only fixes the problem when /tmp is used
There is not actually any log file created in /tmp.
I hope this is a huge clue, but I don't know enough about directfb
to make any sense of it.
My wild guess is that without /etc/directfbrc, directfb falls back
to a default location that is not writable.
Why would that affect this new version of splashy? Change of
execution to premount, maybe?
Also strange: I can not duplicate the error on any virtualbox
machines. I even made a virtual machine with a separate /home
partition.
Couldn't reproduce it.
The new file calls the themes from /usr/share/splashy/themes/. I just
want to rule out that this is not the cause of your problem. Can you
send a copy of your initrd (/boot/initrd.img-`uname -r`) and
/etc/fstab to my email?
I will send my initrd.img via yousendit.com
/etc/fstab is:
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/hda1 / ext3 errors=remount-ro 0 1
/dev/hda6 /home ext3 defaults 0 2
/dev/hda5 none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
