The splash_geninitramfs from media-gfx/splashutils-220.127.116.11-r3 does not copy the initrd.splash script into the initrd (no matter if -a, -g or -c options are used). This way, when in early space a switch to console is needed for user input, it does not happen ('cause the splash() function in the initrd's init script just returns 0) - see bug #268468.
If the splash theme is added through the genkernel --splash option this problem does not exist.
Steps to Reproduce:
1. Append your splash theme to the initramfs file you use (for example):
splash_geninitramfs --verbose --res 1024x768 --append /boot/initramfs-genkernel-x86_64-2.6.37-gentoo my_theme
2. Reboot or gunzip + cpio your initramfs-genkernel-x86_64-2.6.37-gentoo
The /etc/initrd.splash script is missing in the initramfs file, thus switching to verbose when a user input is needed in early space, does not happen.
The /etc/initrd.splash script should be present in the initramfs file.
There a couple of other problems in splashutils except this one... :
1. If one uses the --splash option in genkernel and no SPLASH_THEME is set (neighter in /etc/genkernel.conf nor in /etc/conf.d/splash nor on command line), genkernel uses the name "default" for the splash theme. This theme is not present in /etc/splash at all, even when all existing splash themes from the Gentoo tree are emerged. This way genkernel drops without adding any splash support. This should be fixed.
2. In order the splash support to be added by genkernel there should be at least one theme installed. So the ebuild should depend at least on media-gfx/splash-themes-gentoo
Anyway i am adding a new fixed ebuild - splashutils-18.104.22.168-r4.ebuild and the patch it uses to the splash_geninitramfs (the one that exists in the tree now is modified).
Changelog is in the attachment description....
Created attachment 261883 [details]
The fixed splashutils ebuild revision 4
This ebuild fixes:
1. Missing initrd.splash script in the prepared by splash_geninitramfs initramfs image
2. Added dependency on media-gfx/splash-themes-gentoo because genkernel needs at least one "default" theme to be present.
3. Symlinking the "gentoo" theme from media-gfx/splash-themes-gentoo to "default" theme so genkernel to be able to work as expected with splash support.
Created attachment 261885 [details, diff]
The modified patch needed for splashutils-22.214.171.124-r4.ebuild that fixes the copying of initrd.splash where necessary
This is the actual patch to the splash_geninitramfs fixing the initrd.splash copying problem.
Created attachment 261927 [details, diff]
splashutils-126.96.36.199-r4.ebuild of PhobosK turned into a patch against splashutils-188.8.131.52-r3.ebuild
Turning ebuild into a patch...
Thanks for the patches.
I don't think splashutils should install the theme package and set up the symlink. What I think should happen instead is that genkernel should print an error if a splash theme is not selected. Long time ago splashutils followed a pattern of using the "default" theme everywhere. I would like to migrate away from that in favor of specifying the theme name explicitly.
Also, why do you need to append the initramfs image generated by splashutils to an image built by genkernel? Shouldn't genkernel already include the contents of what splash_geninitramfs produces, as well as the initrd.splash file?
splash_geninitramfs is a generic, distro-neutral utility meant to provide a basic initramfs containing core binary files and the theme config, not shell scripts. This is a job for a distro-specific system, such as genkernel.
Well you are right that probably best behaviour is genkernel to show a message/bring an error if a theme is not selected, but the problem is that splashutils without installed themes is actually useless... In all other distroes (Debian, Mandriva etc.) any splashutils like package depends on at least one theme to be installed... I think this is a good way to work the things out. One should not depend on the user to read the ewarn so he can install additionally themes... Anyway it is a matter of choice...
About the adding of the initrd.splash script by genkernel... yeah it has been added in the initrfs but only if the appropriate option has been set in genkernel and the docs do not say much about that and it is a kinda hidden option in genkernel.conf. Besides... that function should go to splashutils (when installed on gentoo it stops to be a distro independent software anyway...).
On the other hand splashutils is already installed on gentoo, so it should act as a distro specific already... if one wants to add a theme to the initrfs he should be able to do it the right way both by genkernel and splashutils itself...
The reason I brought this bug up is that I have been using splash_geninitrfs for adding themes for a long time till i discovered it actually did not use/add the splash script... That is not a good behaviour, it is not distro tweaked and not to mention that it leads to confusion...
Anyway as i said it is a matter of choice if you will change anything in splashutils ebuild etc... I made my choice already as I am using my own ebuild for both genkernel and splashutils.... The bad thing is that most users do not have this kinda choice :)
Thanks for your detailed reply. I agree that the current situation is suboptimal, I'm just not sure yet what is the right way to fix it..
(In reply to comment #5)
> About the adding of the initrd.splash script by genkernel... yeah it has been
> added in the initrfs but only if the appropriate option has been set in
> genkernel and the docs do not say much about that and it is a kinda hidden
> option in genkernel.conf.
Could you please point me to the docs that you're referring to? This will help me decide where the fixes should applied (splashutils/genkernel/docs).
Well the docs i refer to are the genkernel.conf itself and the man page of genkernel.... And that is not much... there is a separate wiki for splashutils (it needs change but that change depends on the changes that will be made in splash utils) - http://en.gentoo-wiki.com/wiki/Fbsplash.
Another thing that bothers me is that the current splashutils is not "eye candy" enough... If you compare it to the usplash of Ubuntu for example, it misses some functionality.... for example when there is a need of input (password for LUKs encrypted volumes etc) it brings back the console, while the usplash has a nice text box where you enter the pass... some other things are different too but i know it takes much more for adding these options in the source code tree... Anyway that was just an idea...