Summary: | media-gfx/splashutils-1.5.4.3 - console=tty1/silent prevents inittab to initialize startx | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | hal <laservader> |
Component: | Current packages | Assignee: | Michal Januszewski (RETIRED) <spock> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
profile fadein/fadeout disabled, x coming up
profile fadein/fadeout (<- automatically) enabled, x coming not up |
Description
hal
2009-12-08 02:11:43 UTC
addon: what i just discovered in my logs: "/var/log/everything/current:Dec 8 03:33:21 [kernel] [ 2.762173] Warning: unable to open an initial console." (In reply to comment #1) > addon: > > what i just discovered in my logs: > > "/var/log/everything/current:Dec 8 03:33:21 [kernel] [ 2.762173] Warning: > unable to open an initial console." > ah forget it. this was just because of some tryouts with console=xyz (In reply to comment #2) > (In reply to comment #1) > > addon: > > > > what i just discovered in my logs: > > > > "/var/log/everything/current:Dec 8 03:33:21 [kernel] [ 2.762173] Warning: > > unable to open an initial console." > > > ah forget it. this was just because of some tryouts with console=xyz > heh. :) the only thing that is fixed is the error in the log, not the problem itself. my last two posts should have been a sidenote/further information. another piece of information, not sure if this is relevant: " ~ # ls -la /lib/splash/ bin/ cache/ sys/ tmp/ ~ # ls -la /lib/splash/bin total 32 drwxr-xr-x 2 root root 4096 Dec 8 01:14 . drwxr-xr-x 6 root root 4096 Dec 8 01:16 .. -rw-r--r-- 1 root root 0 Dec 8 01:14 .keep_media-gfx_splashutils-0 -rwxr-xr-x 1 root root 5384 Dec 8 01:14 fbres -rwxr-xr-x 1 root root 5384 Dec 8 01:14 fgconsole -rwxr-xr-x 1 root root 5356 Dec 8 01:14 usleep ~ # ls -la /lib/splash/cache/ total 8 drwxr-xr-x 2 root root 4096 Dec 8 00:37 . drwxr-xr-x 6 root root 4096 Dec 8 01:16 .. -rw-r--r-- 1 root root 0 Dec 8 00:36 .keep_media-gfx_splashutils-0 ~ # ls -la /lib/splash/sys/ total 8 drwx------ 2 root root 4096 Dec 8 01:16 . drwxr-xr-x 6 root root 4096 Dec 8 01:16 .. ~ # ls -la /lib/splash/tmp/ total 8 drwxr-xr-x 2 root root 4096 Dec 8 01:14 . drwxr-xr-x 6 root root 4096 Dec 8 01:16 .. -rw-r--r-- 1 root root 0 Dec 8 01:14 .keep_media-gfx_splashutils-0 XBMC ~ # " another testcase: i stumpled upon these bugs: 1. http://bugs.gentoo.org/show_bug.cgi?id=253758 2. http://bugs.gentoo.org/show_bug.cgi?id=97413 there i saw the usage of "luxisri.ttf" as a consolefont. so i changed my font: #consolefont="default8x16" consolefont="luxisri.ttf" "~ # ls -la /etc/splash/ total 80 drwxr-xr-x 3 root root 4096 Dec 8 01:14 . drwxr-xr-x 53 root root 4096 Dec 8 11:37 .. -rw-r--r-- 1 root root 66372 Dec 8 01:14 luxisri.ttf drwxr-xr-x 6 root root 4096 Oct 21 13:19 xbmc" having done this, chvt is obviously processed resulting in a successfull startx, which is strange since it was working normally the last weeks with having set the default font. the downside of this experiment: consolefont cant't get started anymore. "consolefont |Cannot open font file luxisri.ttf" (In reply to comment #5) > another testcase: > i stumpled upon these bugs: > > 1. http://bugs.gentoo.org/show_bug.cgi?id=253758 > 2. http://bugs.gentoo.org/show_bug.cgi?id=97413 > > there i saw the usage of "luxisri.ttf" as a consolefont. so i changed my font: > #consolefont="default8x16" > consolefont="luxisri.ttf" > > "~ # ls -la /etc/splash/ > total 80 > drwxr-xr-x 3 root root 4096 Dec 8 01:14 . > drwxr-xr-x 53 root root 4096 Dec 8 11:37 .. > -rw-r--r-- 1 root root 66372 Dec 8 01:14 luxisri.ttf > drwxr-xr-x 6 root root 4096 Oct 21 13:19 xbmc" > > having done this, chvt is obviously processed resulting in a successfull > startx, which is strange since it was working normally the last weeks with > having set the default font. > the downside of this experiment: consolefont cant't get started anymore. > > "consolefont |Cannot open font file luxisri.ttf" > forget my last comment, this has nothing to do with splashutils. guess i was a bit tired at this time...what a brainfart. XD nevertheless x comes up if consolefont is not loaded. but i found out something different. "console=tty1" is set in bootloader. if i set fadein and fadeout, then it fades in and out, just like one would expect. if i only set fadein it still fades out, ignoring that fadeout was not set in the bootloader. i took a look at "/etc/conf.d/splash" (didn't know that this exists at all): "# Which special effects should be used? # This should be a comma separated list. Valid items: fadein, fadeout SPLASH_EFFECTS="fadein,fadeout"" if i comment out (#) the line above, then it's possible to switch off fadeout, too. in this case my bootloader entry looks like this: "... video=uvesafb:ywrap,mtrr:3,1280x720-32 splash=silent,theme:xbmc console=tty1 ..." as soon as i would set fadin in my bootloader again, while "#SPLASH_EFFECTS="fadein,fadeout" is still disabled, fadeout gets enabled automatically at the same time. the result is, that x won't come up as soon as fadeout is enabled. if it is disabled x comes up properly, but showing the verbose console for about 1-2 seconds. Created attachment 212515 [details]
profile fadein/fadeout disabled, x coming up
Created attachment 212516 [details]
profile fadein/fadeout (<- automatically) enabled, x coming not up
Bump (In reply to comment #9) > Bump > Bump again. ;) just played around again to see if i could workaround the issue somehow. on my research i found the following: http://dev.gentoo.org/~spock/projects/fbsplash/changelog.php "10 Sep 2007 * <spock@gentoo.org> * splashutils-1.5.2 - Make sure chvt requests are not processed during fadeout." it feels like this does not happen on version 1.5.4.3. like described above fadout seems to prevent chvt working correctly because xorg is started in the background and is up & running (top told me so). after initializing chvt manually, everything continues working like it should. so an actual workaround is to put chvt in local.start. on this way xorg would come up correctly, but would also interrupt the fadeout process showing the console with boot information for about a second. the behaviour is just like disabling fadeout completely. (In reply to comment #12) > so an actual workaround is to put chvt in local.start. on this way xorg would > come up correctly, but would also interrupt the fadeout process showing the > console with boot information for about a second. the behaviour is just like > disabling fadeout completely. Sorry for my late reply to this, I just didn't have enough time lately to take a closer look at the problem. It looks there are three issues here: - the fadeout problem is a genuine problem, which I have just fixed in CVS. - you're starting X from a custom (i.e. other than 'xdm') init script, yet your SPLASH_XSERVICE in /etc/conf.d/splash is not set accordingly. This is what is most likely causing the main problem of the boot process ending at tty1. - additionally, it is possible that the splash daemon was not processing all signals correctly, resulting in some chvt requests not working. This should be fixed now as well. Please let me know if the problems you experienced are gone after syncing, reinstalling splashutils, and fixing the settings in /etc/conf.d/splash. hi michael, no problem, i was busy during the last weeks, too. ;) > - you're starting X from a custom (i.e. other than 'xdm') init script, yet your > SPLASH_XSERVICE in /etc/conf.d/splash is not set accordingly. This is what is > most likely causing the main problem of the boot process ending at tty1. i'm starting my xsession via inittab. it calls a custom script from "/usr/local/bin" called "xbmc-gentoo" and consists of the following: inittab entry: "c6:2345:respawn:/usr/bin/openvt -fwec 7 -- /bin/su - xbmc -l -c "/bin/bash --login -c /usr/bin/startx >/dev/null 2>&1"" /usr/local/bin/xbmc-gentoo: "#!/bin/bash /usr/bin/xsetroot -cursor /opt/.modResources/xcursor/emptyCursor.xbm /opt/.modResources/xcursor/emptyCursor.xbm ; /usr/local/bin/WiiUse_WiiRemote >/dev/null 2>&1 & /usr/bin/dbus-launch --exit-with-session /usr/bin/xbmc --standalone" so basically inittab is responsible to fire up X. i guess it's not really possible to put an entry for inittab into "/etc/conf.d/splash"? maybe i could/should extend my "xbmc-gentoo" script with the startx command and call the entire script from inittab which i could setup in "/etc/conf.d/splash". > Please let me know if the problems you experienced are gone after syncing, > reinstalling splashutils, and fixing the settings in /etc/conf.d/splash. would you recommend to completely unmerge splashutils in first place or is a "re-emerge" just fine? (In reply to comment #14) > i'm starting my xsession via inittab. it calls a custom script from > "/usr/local/bin" called "xbmc-gentoo" and consists of the following: > > inittab entry: > "c6:2345:respawn:/usr/bin/openvt -fwec 7 -- /bin/su - xbmc -l -c "/bin/bash > --login -c /usr/bin/startx >/dev/null 2>&1"" > > /usr/local/bin/xbmc-gentoo: > "#!/bin/bash > /usr/bin/xsetroot -cursor /opt/.modResources/xcursor/emptyCursor.xbm > /opt/.modResources/xcursor/emptyCursor.xbm ; > /usr/local/bin/WiiUse_WiiRemote >/dev/null 2>&1 & > /usr/bin/dbus-launch --exit-with-session /usr/bin/xbmc --standalone" > > so basically inittab is responsible to fire up X. i guess it's not really > possible to put an entry for inittab into "/etc/conf.d/splash"? > maybe i could/should extend my "xbmc-gentoo" script with the startx command and > call the entire script from inittab which i could setup in > "/etc/conf.d/splash". I can see three possible solutions to this problem (listed in order of increasing complexity): - create a dummy init script (e.g. '/etc/init.d/startx') and add it to the default level, set SPLASH_XSERVICE=startx. This way, fbsplash won't try to switch to tty1 when the system is finished booting. - modify your xmbc-gentoo script to make it an actual initscript started by openrc and not from inittab. - modify your xmbc-gentoo script so that it can be started like xdm/gdm/kdm using the /etc/init.d/xdm initscript. > would you recommend to completely unmerge splashutils in first place or is a > "re-emerge" just fine? A simple re-emerge should be fine -- you just need to make sure you have the latest commits after the sync (there should be a splashutils ChangeLog entry dated yesterday). ok, what i did so far (a bit of experimenting): 1. reinstalled splashutils (latest patches were applied) 2. removed "chvt 7" from "/etc/conf.d/local.start" 3. didn't change "SPLASH_XSERVICE=xyz" yet. (btw, do the fadein/fadeout options in the splash configuration file override the settings in the kernel commandline? at least it looks like...) 4. disabled fadein/fadeout in the splash configuration and kernel commandline. -> result: x starts correctly, but the verbose mode is visible for about a second before x starts. 5. enabled both fadein/fadeout, but only in the splash config. -> result: ending up in tty1 6. only enabled fadein: -> result: same as 4. 7. only enabled fadeout: -> result: same as 5. now i'm going to try your proposals. what i like about the inittab method is the respawn possibility. my system is an htpc without a keyboard. so in case that xbmc would crash the gui would respawn without user interaction. is there a way to achieve a respawn behaviour with your methods? (In reply to comment #16) > 3. didn't change "SPLASH_XSERVICE=xyz" yet. (btw, do the fadein/fadeout options > in the splash configuration file override the settings in the kernel > commandline? at least it looks like...) Yes, they sort of do. Basically, the effects that will be enabled during boot are the sum of the command line settings and the settings from the config file. So, for instance, if you boot with only fadein on the kernel command line, and only fadeout in the config file, both effects will be enabled. > now i'm going to try your proposals. what i like about the inittab method is > the respawn possibility. my system is an htpc without a keyboard. so in case > that xbmc would crash the gui would respawn without user interaction. is there > a way to achieve a respawn behaviour with your methods? I think this should be achievable with the standard xdm init script, which actually uses inittab to start the desktop manager. You would need to edit /etc/inittab and replace 'once' with 'respawn' in the startDM line though. > > now i'm going to try your proposals. what i like about the inittab method is
> > the respawn possibility. my system is an htpc without a keyboard. so in case
> > that xbmc would crash the gui would respawn without user interaction. is there
> > a way to achieve a respawn behaviour with your methods?
>
> I think this should be achievable with the standard xdm init script, which
> actually uses inittab to start the desktop manager. You would need to edit
> /etc/inittab and replace 'once' with 'respawn' in the startDM line though.
>
ok. that means i would have to create an e.g. gdm like startup script!? (method 3)
(In reply to comment #18) > ok. that means i would have to create an e.g. gdm like startup script!? (method > 3) Yeah, but it's not that complex. If you look at /etc/X11/startDM.sh, it basically executes a script/binary that it was pointed to by /etc/init.d/xdm. Usually that's gdm/kdm/xdm, but in your case, it could easily be xmbc-gentoo. michael, what do you think of the following: 1. scripts: - /usr/local/bin/xbmc-dm (symlinked to /usr/bin/xbmc-dm because xdm expects the binary/script to be located in /usr/bin): #!/bin/bash /bin/su xbmc -l -c "/bin/bash --login -c startx >/dev/null 2>&1" & - /usr/local/bin/xbmc-gentoo: #!/bin/bash /usr/bin/xsetroot -cursor /opt/.modResources/xcursor/emptyCursor.xbm /opt/.modResources/xcursor/emptyCursor.xbm ; /usr/local/bin/WiiUse_WiiRemote >/dev/null 2>&1 & /usr/bin/dbus-launch --exit-with-session /usr/bin/xbmc --standalone 2. configurations: - /etc/conf.d/xdm: DISPLAYMANAGER="xbmc-dm" - /etc/env.d/90xsession: XSESSION="/usr/local/bin/xbmc-gentoo" - /etc/inittab: x:a:respawn:/etc/X11/startDM.sh basically this seems to work, though respawning isn't working yet. i'm not quite sure what prevents a respawn at this point. (In reply to comment #20) > #!/bin/bash > /bin/su xbmc -l -c "/bin/bash --login -c startx >/dev/null 2>&1" & Is it necessary to put it into background (&) here? > basically this seems to work, though respawning isn't working yet. i'm not > quite sure what prevents a respawn at this point. When you kill X and are in a situation in which you'd expect a respawn, are you sure the xbmc-dm script is dead as well? If so, does X come back up if you run `telinit a` from a console? OK, I just did a simple test and I think putting xmbc into background is the cause of the problem. Check /var/log/messages for a 'respawning too fast' error from init. i'm just about to inspect the processes. but i think this is getting too far now for this bug report. :) what do you think? may i have a chance to meet you on irc in the fbsplash channel? (In reply to comment #23) > i'm just about to inspect the processes. but i think this is getting too far > now for this bug report. :) what do you think? may i have a chance to meet you > on irc in the fbsplash channel? Sure, feel free to join me there. Once we have solved this interactively, we can post a quick summary here. The problem was resolved by: - fixing a bug in /etc/X11/startDM.sh (bug #313287) - setting CHECKVT to 1 in /etc/conf.d/xdm - removing the '&' character from the end of the xbmc-dm script |