Using recent versions of bootsplash (I'm currently at 0.6-r11), I see the following on the console after my logger starts: seq: invalid floating point argument: try `seq --help' for more information. The problem is the following line in /etc/init.d/bootsplash: test -z "${BOOTSPLASH_TTYS}" && BOOTSPLASH_TTYS=`seq 0 "${RC_TTY_NUMBER}"` Since RC_TTY_NUMBER is not defined, this doesn't work. I'm not sure where RC_TTY_NUMBER is supposed to be established, so I put the following line ahead of the problem line in bootsplash: test -z "${RC_TTY_NUMBER}" && RC_TTY_NUMBER="5" This is obviously a hack, but it works around the problem. Searching the forums for RC_TTY_NUMBER or the error message text reveals that I'm not the only one to encounter this problem. Reproducible: Always Steps to Reproduce: Boot the system (gentoo-dev-sources-2.6.3-r1, bootsplash 0.6-r11, other current stable packages). Actual Results: The seq error message displayed (until I hacked the bootsplash script). Expected Results: Set the bootsplash image on the appropriate virtual terminals.
RC_TTY_NUMBER is a variable introduced in /etc/conf.d/rc by baselayout-1.8.6.13-r1. This baselayout version is still unstable. I'm sorry I didn't notice it when moving bootsplash-0.6-r11 to stable x86. I have now marked -r11 as unstable, added a proper dependency on the aforementioned baselayout version to both -r11 and -r12 and backported a little fix to -r10. I hope this will fix all issues with RC_TTY_NUMBER. As for the problem itself - there's an even easier way to avoid it - define BOOTSPLASH_TTYS in /etc/conf.d/bootsplash.conf. This may come in handy in case you want to keep bootsplash-0.6-r11 and <=baselayout-1.8.6.13.
