Tiny Core Linux
Tiny Core Base => TCB Bugs => Topic started by: thane on April 14, 2017, 11:37:59 AM
-
I'm having an intermittent issue in TC 8.0 with there being no wallpaper after boot. Wbar is there but the rest of the screen is black. If I go to the Control Panel/Wallpaper and select the jpg, it works fine. Maybe some sort of timing issue? There don't appear to be any other problems associated with it.
I'll be away from TC for a few days so no rush. Thanks.
-
I'm seeing the same thing on my end with the same fix.
-
I booted TC 8.0 in Qemu 10 times, every time the core logo showed. Try to redirect the messages into a file in /tmp (in .setbackground, add >/tmp/bg.log 2>&1 at the end).
-
<bump>
I've had a couple recurrences of this, but it's very infrequent, maybe once every 100 boots at most. I haven't been able to capture any info on it in the log. However a possible clue is that I get the same screen if opt/background is pointing to a non-existent file (i.e. you set opt/background to a file and then delete it).
-
<bump 2>
After upgrading to TC 9.0, there is consistently no wallpaper after boot. Control Panel/Wallpaper works fine. Was there a change to .setbackground or .xsession that might account for this? I've seen this in some earlier upgrades but IIRC it hasn't been a factor recently. Note that what I did was an actual upgrade (installed TC from CD to existing USB partition, then rebooted and updated extensions). Everything else seems to work right. Suggestions?
Thane
< edit: since this is now occurring in 9.0, I guess the thread can be renamed or I can start a new one... >
-
No, there were no changes to .setbackground or .xsession in tc-8.x/9.x.
-
I did some more fiddling and it appears to be related to Xorg. When I removed Xorg and rebooted with just Xvesa the background was set, although the display was distorted because Xvesa doesn't have any settings that match my monitor. I'll keep checking. Thanks.
Thane
<edit> When I deleted the xf86-video-nv extension (which contains the correct drivers for my monitor) and rebooted, the background was set. When I reloaded the extension and rebooted the background was again black. Maybe try moving the entry for the extension around in the onboot list?
-
Hm, so -nv related, and now it's consistent. Please try to grab the errors from .setbackground, redirect to some file in /tmp.
-
#!/bin/sh
hsetroot -full /opt/backgrounds/seattle_4.jpg >/tmp/bg.log 2>&1
[ $(which wbar.sh) ] && wbar.sh
tmp/bg.log shows:
Segmentation fault
-
Can you build it with debug symbols, and try to get a core dump? "ulimit -c unlimited" allows core dumps.
-
I haven't been able to generate a core dump so far. The problem appears only on boot. This is in dmesg:
hsetroot[5610]: segfault at 88 ip 08049cb4 sp bf8c0670 error 4 in hsetroot[8048000+4000]
edit: Probably no longer relevant, but there is a long-ago thread about a similar issue
http://forum.tinycorelinux.net/index.php?topic=12988.0
-
A solution that appears to work (at least for a couple of tries):
I put "sleep 1" in /home/tc/.setbackground.sh just before the hsetroot command and the wallpaper now appears after boot. This reinforces my earlier impression that the occasional problems I had in TC 8.x and consistently in 9.0 were a timing issue. As for why it took me so long to act on that impression, I can only say "duh"...
Will let you know if this solution works reliably.
Thane
-
Hmm, looks like the change to .setbackground.sh is preserved between boots, but ControlPanel/Wallpaper/Install resets it...
-
Maybe in ~/.xsession something like
[ -x $HOME/.setbackground ] && { sleep 1 ; $HOME/.setbackground ; } &
-
Thanks Misalf, that works. I assume .xsession is only executed on boot? That seems to be where the problem was since setting the background from the control panel always worked. What you get for using 8 year old hardware I guess...
-
~/.xsession is exec'ed by startx . So every time the desktop starts.
I wonder if it's caused by the X server has not been started completely and if we can check if it has.
The sleep command always seems kind of a cheap compromise for me in those cases as it may bring in unnecessary delays or be too short depending on the hardware.
-
Hi Misalf
... I wonder if it's caused by the X server has not been started completely and if we can check if it has. ...
I thought that's what the waitforX call in .xsession was for.
-
Well, I'm just speculating without knowledge about X.
And I don't know what waitforX actually does (can't find the source offhand and not sure I could even make sense of it). If it reports true if X is running it may still be too soon for xsetroot to be able to set the wallpaper while X hasn't completely initialized.
Just fumbling about in the dark.
-
Hi Misalf
The source is available here:
http://distro.ibiblio.org/tinycorelinux/2.x/release/src/waitforX.c
Basically it tries to retrieve the current display. It will continue to try 50 times over the course of 10 seconds. If it succeeds, it
returns 0. If it fails, it returns 1.
-
Thanks for digging that out.
-
It does indeed wait for X to be ready, and at that point everything, including setting wallpapers, should work. Thus I believe it's a -nv driver bug, given other drivers do work.
-
I am also seeing this, on TC8, every one out of maybe 10 reboots, and I have Intel graphics, not Nvidia.
-
I'm also seeing this on various systems with Intel video. I haven't tested it on Nvidia but have seen it once or twice on ATI/AMD video as well. It's happened with every version since TC 8.0 including the current 9.0 but nothing before that seems to have the problem.
-
I have seen it, only a few times, before 8.x (I'm still on 7.x) but unfortunately can't tell on what hardware or on what exact version of tinycore. However, the question for me is, while the wallpaper certainly doesn't kill my workflow, could it potentially be an issue that might affect other things (e.g. ~/.X.d).
-
Okay, thanks for the confirmations.