Poor man's graphical boot in Slackware revisited...
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
There is less than 24 hours left to vote in the 2015 LinuxQuestions.org Members Choice Awards. Click here to go to the polls. Vote now and make sure your voice is heard!
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Sorry, that is correct that rc.S doesn't call rc.M. I was a bit distracted when I wrote that.
I've gone back to page 1 of this thread to read through the wrapper scripts again. I see several potential failure point in there. First, there is no PATH set at the top of the scripts, so a couple of programs are being called without the path to them, so far I see 'bc' and 'tput' which are both in /usr/bin. If you happen to have /usr on a separate partition these are not going be available at the start of rc.S or at the start of the rc.S wrapper. I also think the use of the busybox binary under /boot/initrd-tree/bin is weak -for the same reason as above (possibly separate un-mounted /boot partition) and also because it implies that mkinitrd is installed. I'd just create a busybox package and install it so that busybox is in /bin for easier usage. The only other stand-alone bins I see being called are 'setterm' and 'mv' which are both in /bin, so no problem there.
"$STARTUP" &> /boot/GSplash/fifo &
assumes that the directory /boot/GSplash/ exists -there is no 'mkdir -p /boot/GSplash' anywhere, that I see. Again, there will be a problem if /boot is a separate partition. 7tmp would be a more likely place to create the fifo, but /tmp might also be unavailable still, before 'mount -a ...' is run. The only sure place to create the fifo so soon would be right in /, which is kinda messy. But, rc.S is gonna create a file in / when it checks to see if / is writable, so you could do the same. But think about it, / is supposed to be readonly where this is all happening, so you can't even create the file in / until rc.S has run...
The other thing I see is that no framebuffer device is being specified with the fbsplash command. And that brings up the fact that you must be booting using a framebuffer, which means you cannot be using accelerated graphics drivers( you should have some vga=xxx setting on the kernel boot line)
As far as I can see there is no way that the wrapper scripts will work at all in their present form. Most of what is being done there depends on / being mounted read-write and that doesnt happen until after : '/sbin/mount -w -v -n -o remount /' is run. Looks to me like the best way to handle this is to edit the original scripts to insert the code where needed. You won't be able to start the create the fifo until after '/sbin/mount -w -v -n -o remount /'.
wow old thread... certainly this is still a viable option. It's not really that complicated. If you are used to reading scripts it's easy enough to follow. I believe some of the minor fixes and concerns were fixed on the wiki as well.
Personally, I would do it differently and, once a solution finalized, make the scripts run more directly without the wrappers. Additionally, since this solution requires busybox to be accessible somewhere on your system (e.g. /boot/initrd-tree/bin/busybox) it's logical to assume that this is not considered 'installed' and finding another 'fbsplash' program would probably be a better solution.
As to issues with separate /boot /usr portions, it all depends on when /boot is mounted. You can always move a copy of busybox to the /usr partition and update the path variables. That's an easy fix. But the question is where to put busybox. It's technically a swissarmy knife designed for embedded systems. It doesn't really belong anywhere because it's not supposed to be used by the main OS :P.
I am searching for a boot splash strategy for friends and acquaintances for whom I install Slackware. I hope to try this idea soon.
Right now the LQ database is down, if you really want a splashy then search threads started by me and you will find a thread with title something 'bootsplash or splashy' the thread has thumbs up by me. I had to compile splash screen in a kernel(by applying a patch), that method works for lot of people(including me) compared to the one mentioned in this thread. You will need to find the bootsplash patch for your kernel though.
Compiling kernel is not hard,(you may get adrenaline rush for a first few times though!) Good luck.
When I run it as a VM Image I many times after reboot get a EOFEOF and then it just hangs.
This happens many times.
What I must do then is sent CTRL ALT DELETE signal from vmware menu.
Then it reboots and starts up good.
So something corrupt it once it gets shutdown via the vmware.
Anyone had this issue?
I think that's a known issue -if you are talking about the old 'real' bootsplash kernel support. It doesn't play well with vmware. Search posts hear about bootsplash by the author 'jong357' to see his experience.
You have to use some other form of 'splash' -the other ones all work in user-space instead of as a kernel module. You can set up any of several splash tools in an initrd. Or you figure out how to fix the bootsplash sources so they work with vmware. Still, if you were running it on real hardware you'd probably not have this problem.