/sbin/splash-functions.sh and libfbsplash.c mount ${spl_cachedir} with mode=644, which doesn't make sense for a directory. Also suggest adding noexec,nosuid,nodev to this and similar mounts, to be compatible with the mount options used by OpenRC. /etc/init.d/fbcondecor: uses ${RC_TTY_NUMBER}, whereas OpenRC defines ${rc_tty_number}. Suggest using ttyn=${rc_tty_number:-${RC_TTY_NUMBER:-12}}, similar to other OpenRC init.d scripts. Also, request propagating these and other (#339767) splashutils updates to the portage tree.
Also, the ebuild should create the /lib/splash/sys directory (in addition to others).
I am also having a problem with programmatically switching to the silent frame, and as far as I noticed, the problem only appeared with OpenRC. That is, switching between verbose and silent with F2 during boot or when running "splash_manager -c demo" works just fine. Moreover, just switching between VCs with Alt-Left/Right (during boot) gets to the verbose/silent frames fine. Running "splash svc_input_begin svcname" / "splash_verbose" during init.d/svcname gets to the verbose frame just fine (and I can then see the silent VC with Alt-*). But, trying to restore the silent frame programmatically ("splash svc_input_end svcname" / "splash_silent") doesn't work at all, and I am completely at loss for the reason. I guess that just executing chvt with the correct argument might work, but that doesn't sound right.
"chvt ${SPLASH_TTY}" (in addition to splash_silent) indeed works. By the way, if booting without splash enabled on kernel cmdline, but still running the fbcondecor init.d service, libfbsplash.c mounts /lib/splash/cache, and it stays that way (unlike when splash is enabled on cmdline).
This cannot block the openrc stabilization since it is already done on amd64/x86.
(In reply to comment #0) > /sbin/splash-functions.sh and libfbsplash.c mount ${spl_cachedir} with > mode=644, which doesn't make sense for a directory. Also suggest adding > noexec,nosuid,nodev to this and similar mounts, to be compatible with the mount > options used by OpenRC. Done (in git). > /etc/init.d/fbcondecor: uses ${RC_TTY_NUMBER}, whereas OpenRC defines > ${rc_tty_number}. Suggest using ttyn=${rc_tty_number:-${RC_TTY_NUMBER:-12}}, > similar to other OpenRC init.d scripts. Fixed in git, will be included in a new release. -12 doesn't really make sense in the fbcondecor script, so I dropped that. > Also, request propagating these and other (#339767) splashutils updates to the > portage tree. The updates in the bug you mentioned should already be included in the main portage tree in the form of patches.
(In reply to comment #5) > > Also, request propagating these and other (#339767) splashutils updates to the portage tree. > > The updates in the bug you mentioned should already be included in the main > portage tree in the form of patches. Ah, I see it now - splashutils-1.5.4.3-splash-functions.patch. It's a wrong fix, because my initial comment (#1) in that bug had a typo (fixed in #2). And "mode" variable is not fixed either (it just runs splash_util, although maybe it works with splash_util.static - I tested with dynamic executable). This works: local ctty=$(${spl_bindir}/fgconsole) local mode=$(${spl_util} -c getmode)
(In reply to comment #6) > (In reply to comment #5) > > > Also, request propagating these and other (#339767) splashutils updates to the portage tree. > > > > The updates in the bug you mentioned should already be included in the main > > portage tree in the form of patches. > > Ah, I see it now - splashutils-1.5.4.3-splash-functions.patch. > > It's a wrong fix, because my initial comment (#1) in that bug had a typo (fixed > in #2). And "mode" variable is not fixed either (it just runs splash_util, > although maybe it works with splash_util.static - I tested with dynamic > executable). > > This works: > > local ctty=$(${spl_bindir}/fgconsole) > local mode=$(${spl_util} -c getmode) Ah, sorry about not spotting the typos earlier :/ This is now fixed in git.
I've just pushed the official release of 1.5.4.4, which include the typo fixes in splash-functions.sh, fixes in the initscript and sys directory creation in the ebuild. I couldn't reproduce the problems splash_svc_end and the hanging /lib/splash/cache mount. Thanks for reporting all these problems.
(In reply to comment #9) > I've just pushed the official release of 1.5.4.4, which include the typo fixes > in splash-functions.sh, fixes in the initscript and sys directory creation in > the ebuild. Thanks! I checked, it works great. One comment: you wrote that you will drop :-12, but currently it's still in /etc/init.d/fbcondecor, and in wrong form: ${rc_tty_number:-${RC_TTY_NUMBER}:-12} should be ${rc_tty_number:-${RC_TTY_NUMBER:-12}} if defaulting to 12 if neither var is set. > I couldn't reproduce the problems splash_svc_end This problem seems to be gone in 1.5.4.4. > and the hanging /lib/splash/cache mount This problem still persists in my tests (when using real VGA console, and not loading uvesafb), but I guess it's not worth to invest too much time into investigating it, since starting fbcondecor service on non-fb console is an edge case.
(In reply to comment #10) > One comment: you wrote that you will drop :-12, but currently it's still in > /etc/init.d/fbcondecor, and in wrong form: > ${rc_tty_number:-${RC_TTY_NUMBER}:-12} > should be > ${rc_tty_number:-${RC_TTY_NUMBER:-12}} > if defaulting to 12 if neither var is set. Sorry, stupid typo :/ Just added a patch to fix this. > > and the hanging /lib/splash/cache mount > > This problem still persists in my tests (when using real VGA console, and not > loading uvesafb), but I guess it's not worth to invest too much time into > investigating it, since starting fbcondecor service on non-fb console is an > edge case. OK, I will then ignore it for now. Please let me know if this somehow becomes more of a problem.
> and the hanging /lib/splash/cache mount Just discovered that this problem (hanging mount when booting in text mode yet starting fbcondecor service) is gone when "splash=off" is added to the kernel's cmdline. This appears to be somewhat contrary to the documentation, which says that "splash=off" is the default behavior.
What is the current status of this with 1.5.4.4-r2?
(In reply to comment #13) > What is the current status of this with 1.5.4.4-r2? I don't know, sorry. I stopped using splashutils.