[kernel] gensplash framebuffer boot splash screens for 2.6.x

dtw · 2005-01-09 10:07:06

coming very, very soon....

if you haven't already, patch a kernel for fbsplash. i've got 2.6.10 with -nitro2 running just fine, you can grab my PKGBUILD and the patch here - start with the usual Arch config.

i have a complete splashutils PKGBUILD with added extras including scripts and sample configs. PLUS I have created initscripts patches for fbsplash and fbsplash/bkgdDaemon combined...and yes, i do have the silent progress bar working...

MWAHAHAHAHA - it's alive!

phrakture · 2005-01-10 16:32:17

what's the difference between nitro2/nitro3/nitro4? I actually was going to build nitro4-mm a few days ago, but didnt have time to bring my comp to a screeching halt 8)...
I'll build it tonight...

dtw · 2005-01-11 10:01:42

After much blood, sweat and tears (not too mention annoying comments from my girlfriend) I have finally managed to patch initscripts to work with silent gensplash! Better late than never, eh? I had some major headaches with this but I wanted to save it till it was completely ready.

So, here's the deal and the files - all stored here http://dtw.jiwe.org/share/gensplash

with a whole bunch of gensplash showcase pics here

First you need a patched kernel - I am using 2.6.10 and nitro2 - it works great - see the wiki on how to do that. I have a PKGBUILD and patch file on my server too.

Then you need a splashutils package - there are several about on the forums but I hope mine will provide everything you might need. Splashutils needs to link to your patched kernel source when you build it - so my PKGBUILD allows this. The PKGBUILD also uses a pack i put together containing some handy bits for gensplash. This includes examples for lilo and grub, a splash rc.d script to start the backgrounds on the virtual terminals (and a config file to support this), and it includes three themes: the ArchPool theme, ArchMetal (created by me but credit to the Arch wallpaper author tho!) and the emergence gentoo theme (which is a bit crap to be honest).

You can use the PKGBUILD and the gensplash-files pack to build splashutils.

Pre-built packages of both splashutils, initscripts-custom and initscripts-gensplash (see below) are in my repo – they should work perfectly but YMMV!

When you install splashutils you should get a handy introduction from the install script.

If you want to use silent splash you'll also need to patch your initscripts. You can use splashutils quite happily to add a verbose boot screen and vc backgrounds if you don't want to mess with your initscripts. I have a neat PKGBUILD which will grab and patch the latest initscripts from the current repo if you do - this one is for initscripts-gensplash

# Contributor: dibblethewrecker <dibblethewrecker@jiwe.org>
# This package is only a modified version of the arch initscripts package
# It allows you to easily checkout the latest initscripts and patch them
# (based on a pkg by Brice Carpentier <brice@daknet.org>)
# (incorporated a patch by Truls Becken <becken@stud.ntnu.no>)

pkgname=initscripts-gensplash
pkgver=0.6
pkgrel=1
pkgdesc="System initialization/bootup scripts with gensplash support"
url="http://dev.gentoo.org/~spock/projects/gensplash/"
backup=(etc/inittab etc/rc.conf etc/rc.local)
depends=('bash' 'mawk' 'grep' 'coreutils' 'sed' 'splashutils')
provides=('initscripts')
conflicts=('initscripts')
source=(initscripts-gensplash.diff)
md5sums=('f1770772913855d9539b12b384d9941f')

build() {
  # check the latest version of initscripts, grab it, copy and extract it to src
  latestver=`pacman -Ss initscripts | grep current | sed "s|current/initscripts ||g"`
  echo
  echo "  : Latest version in current repo is initscripts-$latestver"
  echo -n "  : Press any key to continue "
  read anykey
  pacman -Sw --noconfirm initscripts
  cp /var/cache/pacman/pkg/initscripts-$latestver.pkg.tar.gz $startdir/src

  cd $startdir/src
  gunzip -cd initscripts-$latestver.pkg.tar.gz | tar xf -

  # create the pkg - no compile required
  mkdir -p $startdir/pkg/etc/{rc.d,conf.d}

  cd $startdir/src/etc
  install -D -m644 inittab $startdir/pkg/etc/inittab
  install -D -m644 rc.conf $startdir/pkg/etc/rc.conf
  for i in rc.local rc.multi rc.shutdown rc.single rc.sysinit; do
    install -D -m755 $i $startdir/pkg/etc/$i
  done

  cd $startdir/src/etc/rc.d
  install -D -m755 network $startdir/pkg/etc/rc.d/network
  install -D -m755 netfs $startdir/pkg/etc/rc.d/netfs
  install -D -m644 functions $startdir/pkg/etc/rc.d/functions

  cd $startdir/src/sbin
  install -D -m755 minilogd $startdir/pkg/sbin/minilogd

  # apply your patches
  cd $startdir/pkg/etc
  patch -Np1 -i $startdir/src/initscripts-gensplash.diff
}

If you do want silent splash (you do – that's what all this work is for) i have 2 patches for this - the first simply patches for gensplash (initscripts-gensplash), the second patches for gensplash and the bkgdDaemons patch (combo-plus). The old initscripts-bootsplash patch is there for completeness and reference too

The patched initscripts allow you to run silent bootsplash and drop to verbose should errors (fails) occur. This can be overridden by an option has been added to rc.conf – however, it will ALWAYS drop to verbose if the fs check fails – at least it should – I don't know how to test that.

As I said the drop option has currently been added to rc.conf but the alternative is to use the conf.d/splash config file from the splashutil pkg (which is already set up to allow this). I would like feedback on this, for and against, whether you intend to us the package or not. Here is the way I see it:

FOR using rc.conf
You control the majority of boot options from rc.conf – this is a boot option
rc.conf is already sourced by the scripts by default
rc.conf is part of the initscripts package

AGAINST rc.conf
It is the main config file – do we want to pollute it with extraneous commands for eye candy?

FOR using conf.d/splash
It's not rc.conf – it is a gensplash related option in a dedicated gensplash config file

AGAINST using conf.d/splash
This file is not actually used for any config options that relate to boot (except to pre-empt a switch ), only for setting backgrounds on virtual consoles
This file is not part of the initscripts package – although my initscripts obviously depend on apps in splashutils (won't work without it) – cross dependent configs seem dodgy.
We have to source an extra file in the scripts

I have also separately packaged the ArchPool and ArchMetal themes but I will have to upload them later because I forgot them today

Problems and Bugs
I am having MAJOR problems with the splash rc.d script. It uses the conf.d/splash config file fine but i still CANNOT get it to work at boot BEFORE i log in - it works fine after - ideas PLEASE!

It now also seems to cause similar overlay problems to that are described in bug 2 below – with SOME themes you get a persistent progress bar on your vc after the boot process is finished and it seems to affect different themes depending on when you run the script in your daemons array – am baffled – it needs serious work! Bug 2 and this maybe related...more testing needed!

Last but not least - the bkgdDaemons patch. If we background a daemon how do we know if it failed or not? Has anyone thought of that? My initscripts consider a background daemon BKGD to be DONE for the purposes of displaying the progress bar although the bkgdDaemons patch functionality remains identical and BKGD still shows in verbose. If a BKGD daemon fails, this maybe as late as after login for DHCP failures, for example, we'll never know until we try to use the network.

Bugs
1. When udev starts you get message saying can't open /dev/fb0 and /dev/fbsplash for reading – no apparent ill effects tho? [FIXED]

2. If you switch to verbose with F2 at a very specific point – during the fs check I think – the background MIGHT corrupt a tiny bit as the verbose overlays the silent (correctly) but then when the fs check finishes I think it still thinks it is in silent mode (due to the mode being passed to it when it starts to execute) and overlays silent again – only for the next rc script to overlay verbose (again correctly). It's hardly terrible but someone might like to have a look – I can't be bothered right now as there is very little need to switch to verbose with F2 (cos it does it automatically on errors) and you do have to do it at just the right second to get the problem! Feel free to check it out tho.

TODO:

1) workaround the current symlink workaround – DONE (don't ask it was awful)
2) figure out how to drop out of silent if errors occur at startup - DONE
3) fix that f**king rc.d script – - SOMETIMES WORKS SOMETIMES NOT -SETTING IT AS THE LAST DAEMON SEEMS TO HELP
4) investigate the bugs - DONE
5) enable silent splash in ArchMetal – DONE
6) make lots of nice gensplash screens for Arch! – EVERYONE!

dtw · 2005-01-11 10:42:35

ummm - the patches are newer? nitro is just bits of loads of other patchsets thrown together - usually based on -ck i think, which is normally pretty stable

can we not have a discussion about -nitro in my lovely new thread tho please there are lots of nitro thread

MaceM · 2005-01-11 16:31:45

looks nice, i'll give it a try.
you're teh man

dtw · 2005-01-12 02:36:25

i did a bit more research - apparently it is not the rc.d/splash that cause the overlay probs when you login - as it happened when i had !'d it. It may be something to do with backgrounded daemons (i use the custom version with bkgd daemon) - or it may be the way that the progress bar is updated after stat functions in rc.d/functions - maybe that needs tweaking - i dunno

dtw · 2005-01-13 09:45:46

it is the backgrounded daemons causing the overlay issue - if a backgrounded daemon finishes at approx the same time as the login screen then appears (i.e.change to verbose) the daemons stat_done command still writes to the bootsplash progress bar - which causes the overlay. switching to verbose with f2 as a bkgd daemon finishes has much the same effect.

there is no easy solution to this - as you are unlikely to even see the stat_done or stat_failed messages created by BKGDed daemons anyway (with the vanilla daemon patch) it would ideal if every daemon included a bkgd) option which did the same as start) but with no output at all.

of course this is certainly not going to get implemented as it would require a re-write of all the daemons and highlights a further issue with simply redirecting the bkgd daemons output to null rather than altering how it is actually started -> it is not actually bkgd at all is it?

one way we could do it is to include a test in the stat_done and stat_fail function to see if the daemon was backgrounded and if it was supress any output at all - any ideas on that?

just to note in closing:

as far as i can tell you should not experience any overlay issues AT ALL when using the gensplash-initscripts but you may when using custom-initscripts (with the BKGD patch) ESPECIALLY if you have background daemons at the END of your daemon array

dtw · 2005-01-14 07:51:46

i have made a fix to the custom-initscripts page - you'll need to patch the vanilla initscripts to use it (you can use the pkgbuild further up the thread just change the patch name and source) - i'll post a pkg soon. when the rc.muti script identifies a BKGD daemon it exports a var that tells the stat functions not to write to the progress bar - it seems to work fine. there must be better ways of doing it tho!

EDIT: see next post

i also made a crappy patch to add an option to disable the shared lib updating in rc.conf

shared updated patch

I got an email from spook at gentoo today who gave me a link to the gentoo scripts but it is all bit too complicated for me!

i also add that since i made the above change to rc.multi the rc.d/splash script seems to be working finally too! hurrah

dtw · 2005-01-15 08:46:47

splashutils has been updated and renamed to gensplashutils so will need to do:

pacman -S gensplashutils

this will remove splashutils - gensplashutils includes the ArchMetal and ArchPool theme - no emergence because it is crap and massive!

new packages of both initscripts - patches in the same place

these patches include various fixes - drop to verbose is working fine (except if the daemon is backgrounded - natch), i have had no recent overlay problems when the login screen appears, i think i fixed this (the F2 switch instance still persists in some cases as before) and finally teh rc.d/splash script seems to be working perfectly.

i've also tried to simplify things a bit in the scripts

i strongly suggest you all (?) update to the latest versions - no updates for a while now i think!

i also added the DangerGirl theme to the fbsplash dir on the server cos i like it!

lucke · 2005-01-20 15:20:59

Dunno where exactly the problem is (at least yet), but your hacked rc.sysinit seems to cause console font on vc/1 revert to the original one, in place of the one defined in rc.conf. Other consoles' font is left intact.

Cheers,

lucke

dtw · 2005-01-21 05:27:14

ah - i have never messed about with changing the console fonts so that is not something i owuld have come across - are you sure you mean the rc.sysinit and not the rc.d/splash script? just to clarify i mean. do you have the wrong fonts during startup or when the login prompt appears? i know the gentoo scripts do provide some font changing option but i didn;t know what it was for - now i have an idea tho!

lucke · 2005-01-21 08:29:04

I've done some research. Here's what I've observed:

1. This isn't the doing of splash script - works the same with it started on boot and without.
2. It works well with genuine rc.sysinit.
3. When I manually add ' /usr/bin/setfont /usr/share/kbd/consolefonts/lat2-16.psfu.gz -C /dev/vc/1' at the end of your rc.sysinit, it still doesn't work.
4. However, if I add it to rc.local, it works perfectly.

Conclusion: problem lies somewhere between both rc.sysinit and rc.multi hacked by you.

It doesn't bother me much, one additional line in rc.local isn't a problem. But well, we want to get rid of all the bugs, don't we? :-)

Cheers,

lucke

ps. Still no solution to udev's fb0 not accesible problem?
ps2. You could add EvenNeverTux theme to the package. It was in the previous splashutils made by some other archer. IMHO it just rocks, especially the verbose screen - so discreet :-)

dtw · 2005-01-22 08:07:01

um - no luck on the udev - as you can see i have not had loads of feedback! i'll look in to the font thing - is that the one you set in CONSOLEFONT= in rc.conf?

as for more themes - i wanted to keep them strictly Arch - for loyalties sake i'll have a look

dtw · 2005-01-30 12:52:09

ok - i fixed loads - the new pkgs and gensplash files are up on the server. no more /dev/fbsplash errors when you are booting a non-fb kernel.

to fix the consolefont i made a quick patch which should be applied to the latest rc.d/splash file

http://dtw.jiwe.org/share/gensplash/spl … -font.diff

This basically resets the consolefont when the rc.d/splash script is run. also you want the font reset when you change the vc backgrounds anyway!

this saves you setting it in rc.local - just add the splash to your daemons and consolefonts will be set when splash runs

the consolefont problem can't be fixed in the rc.sysinit as far as i understand it fbsplash "refreshes" the vc everytime it is called so the font is lost - we could set it everytime fbsplash is called at start up but why bother if we can just run it at the end?

comments and testing please lucke! if it is ok i'll added officially

lucke · 2005-01-30 13:34:24

After brief testing, here's what I have to say:

1. Udev errors are really gone, how did you attain that?
2. Well, basically, your idea with setting the font in splash is good. However, $CONSOLEFONT (and other vars from rc.conf, actually) gets flushed somewhere before starting the daemons. Pasting actual font name there works well, as far as I have observed. We'd have to think about some workaround for that var.

Thanks for your work, dibble.

dtw · 2005-01-31 05:09:09

nah - $CONSOLEFONT is sourced from rc.conf at the start fo the splash script isn't it? How could it be being lost? Or did i mess the start of the script up? Maybe

The udev errors were easy to fix as it turned out, I was more inspired to fix it by the fact that booting a non-fb kernel was UUUGGGGLEEE!

I all had to do was add a if [ -e /dev/fbsplash ] to all the areas that called splash_util - dunno how i missed before, you'll see rc.dfunctions is tidied up a lot too!

lucke · 2005-01-31 05:52:55

Those rc.conf vars are cleared somewhere, even on my machine with genuine (read: non-modified) bootscripts. Try to echo any of it after boot. But it seems I'm too dumb to figure out where that happens :-)

dtw · 2005-01-31 05:59:02

um - i dunno if you know much about bash but the CONSOLEFONT variable should be read directly from the rc.conf by the splash script unless i forgot the

source /etc/rc.conf

at the top - they may be cleared from memory when the daemons start running but should still be available from rc.conf

lucke · 2005-01-31 06:07:47

Well, the least I can say: this variable didn't work for me :-)

-edit-

Damn. My wrong. Seems it works just well. When I first tried it, it didn't though. Well, sorry for the ruckus.

dtw · 2005-01-31 06:14:34

um - works for me. right, please post you the CONSOLEFONT section of your rc.conf so i can try the actual font you use and stuff - cos, as i said, i don't use the fonts so i don't know what they are supposed to do. i have tested with random fonts but i'd like to try yours

lucke · 2005-01-31 06:17:01

Look above at the edit line :-)

dtw · 2005-01-31 06:26:06

LOL - absolutely NO problem - very glad it does work!

Any more suggestions? I very much appreciate your guinea pig status!

How do you feel about the option for VERBOSEONFAIL being in rc.conf vs conf.d/splash?

lucke · 2005-01-31 10:15:24

I'm lost. I've just booted my machine with your improved splash script and the font in vc/1 is different again. Seems like a random thing, sometimes it works, sometimes not. To tell the truth, I've observed similar thing when I had that setfont thing in rc.local, sometimes it was O.K., sometimes not :shock: I don't have any idea what it is all about.

As for VERBOSEONFAIL, it suits me better in rc.conf.

Cheers,

lucke

lucke · 2005-01-31 10:49:01

No more reboots, argh.

Evil reboots allowed me to come to the conclusion, that it works well when you press f2 while booting and turn to verbose. It doesn't work with all-the-silent-boot.

Maybe that'll be some clue for you, I'm out of this rebooting business :-)

Cheers,

lucke

dtw · 2005-01-31 11:35:38

thanks dude - the problem ultimately appears to lie in whether the rc.d/splash runs correctly i think - sometimes it doesn't appear to run for me at all! this has been a bug from day one but i am defeated and the people who seem to know most about this stuff have been resolutely mute!

what if you just restart the rc.d/splash daemon?

Try swapping your font in rc.conf and to test the setting do:

/etc/rc.d/splash restart

this saves you a reboot and confirms that when the script runs correctly it does work - then we just have to figure out why it doesn't run correctly.

if, as you say, the script works correctly when you start in verbose, that may provide some very useful insight and i'll investigate that!

Arch Linux

#1 2005-01-09 10:07:06

[kernel] gensplash framebuffer boot splash screens for 2.6.x

#2 2005-01-10 16:32:17

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#3 2005-01-11 10:01:42

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#4 2005-01-11 10:42:35

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#5 2005-01-11 16:31:45

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#6 2005-01-12 02:36:25

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#7 2005-01-13 09:45:46

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#8 2005-01-14 07:51:46

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#9 2005-01-15 08:46:47

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#10 2005-01-20 15:20:59

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#11 2005-01-21 05:27:14

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#12 2005-01-21 08:29:04

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#13 2005-01-22 08:07:01

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#14 2005-01-30 12:52:09

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#15 2005-01-30 13:34:24

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#16 2005-01-31 05:09:09

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#17 2005-01-31 05:52:55

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#18 2005-01-31 05:59:02

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#19 2005-01-31 06:07:47

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#20 2005-01-31 06:14:34

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#21 2005-01-31 06:17:01

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#22 2005-01-31 06:26:06

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#23 2005-01-31 10:15:24

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#24 2005-01-31 10:49:01

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

#25 2005-01-31 11:35:38

Re: [kernel] gensplash framebuffer boot splash screens for 2.6.x

Board footer