[SOLVED] No up-to-date bootsplash packages? (splashy & fbsplash...)

Question

Not sure if this should go here, but this is my first post, so I'm putting it in the Newbie Corner.
The bootup is probably the buggiest/half-finished-looking part of the OS after following the beginner's installation guide, so I think it would be good to have a way to make a decent working bootsplash maintained somewhere (from what I've read, these sorts of things stay in the AUR because they are rather arch specific, so not arguing for something put into the main repos).  So I checked the wiki page about bootsplash: https://wiki.archlinux.org/index.php/Bootsplash
There's four listed, but unfortunately none of them seem like solid candidates.  Splashy has a couple of errors that have gone unfixed (last comment about what I'm going to cover was listed about a month ago), fbsplash suffers from a similar problem (again, last report about a month ago), and plymouth is said to be "under heavy development and may contain bugs."  I haven't tried the xsplash-bzr, but it's several years old and has no documentation, not to mention that the short description of it suggests it is ubuntu-specific.
SPLASHY
On splashy I tried to patch the file for automake-1.14 (the pkg looks exclusively for automake-1.13, which doesn't seem to be in the AUR).  Overriding the checksum seemed to at least make that part functional, but then I got the following error:
checking for automake >= 1.13...
  testing automake-1.13... not found.
***Error***: You must have automake >= 1.13 installed
  to build Package.  Download the appropriate package for
  from your distribution or get the source tarball at
    http://ftp.gnu.org/pub/gnu/automake/aut … .13.tar.gz
I'm not sure if this was ultimately fatal.  The problem is, it kept running until reaching the following:
Checking for forbidden M4 macros...
***Error***: some autoconf macros required to build Package
  were not found in your aclocal path, or some forbidden
  macros were found.  Perhaps you need to adjust your
  ACLOCAL_FLAGS?
I'm really not sure how to fix this, and moreover even if I do, that's another thing I'm overriding the checksum for.  Doesn't sound like a very clean or simple workaround.
FBSPLASH
On this one, the error is not the file itself, but rather one of its dependencies.  The issue comes in with '/usr/lib/libfreetype.a' not existing, though I have all the dependencies in and up-to-date.
==> Starting build()...
make[1]: Entering directory `/home/patrick/.build/miscsplashutils/src/miscsplashutils-0.1.8/fbtruetype'
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -I/usr/include/freetype2 -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/lib -o fbtruetype -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/lib fbtruetype.o messages.o console.o ttf.o luxisri.o -lfreetype -lm
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -I/usr/include/freetype2 -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/lib -static -o fbtruetype.static -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/lib fbtruetype.o messages.o console.o ttf.o luxisri.o /usr/lib/libfreetype.a /usr/lib/libz.a /usr/lib/libbz2.a -lm
gcc: error: /usr/lib/libfreetype.a: No such file or directory
make[1]: *** [fbtruetype.static] Error 1
make[1]: Leaving directory `/home/patrick/.build/miscsplashutils/src/miscsplashutils-0.1.8/fbtruetype'
make: *** [all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
I'm not sure what exactly is going on here, but according to the latest comment...
"Since freetype2 doesn't provide the static libs anymore, the compilation fails:
... [error I got]...
Note that patching fbtruetype/Makefile once again, removing the static compilation, is enough for this package but it doesn't seem a good workaround because fbsplash doesn't compile anymore always 'cause freetype2. I think you need to provide a static version of freetype2."
I'm not really sure which is easier, which would lead to the more sophisticated result, which is more supported, etc., so excuse the rather diffuse presentation.  The main issue is that I don't know how to get a working bootsplash, and not for wont of trying.  That said, I would also like to know whether it'd be appropriate to make the bootsplash issue more integrated with the rest of the basic installation (like with post installation issues regarding window managers or something).
Last edited by dy acedia (2013-07-31 15:44:41)

Answer 1

If you want a totally silent boot, you just need to have the "quiet" boot parameter.  Then you need to tell the [email protected] to log to the journal instead of the console.  Though it is probably a good idea to have it push the output to the console when there are errors.  So to achieve that, you would do something like:
$ cat /etc/systemd/system/[email protected]/silent.conf
[Service]
StandardOutput=journal
StandardError=journal+console
You may need to do something similar with systemd-fsck-root.service.
After that the only thing that should be logging to your console would be the fsck inside the initramfs.  Unfortunately, I don't think that silencing this is quite as straight forward as the rest. This is because the "fsck" mkinitpcio hook (which you should be using BTW... unless you use btrfs) is just a shell script.  So you would have to modify the hook itself in /usr/lib/initcpio.  But I guess if you just redirected stdout (1) to /dev/null and not stderr (2), then you should achieve the same sort of effect as with the modification to the [email protected] where it will only show you if there is something wrong.
Honestly, I don't really see all this as being totally worth the time and effort, especially since that initcpio hook is going to be overwritten by any mkinitpcio update.  But just in case you wanted to get going on making a silent boot, there is how to get started.  Honestly, I think a silent boot is much more sane than a boot splash that shows for a split second.
Oh yeah, and I'm not sure how the coming changes to mkinitpcio might affect what I just told you above.  The version in [testing] gives the option to use systemd in the initramfs.  So I'm not sure how the "fsck" hook would play into that.  In any case, I use btrfs, so I don't use the "fsck" hook anyway...