Poor man's graphical boot in Slackware revisited...
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
This line:
"$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 /'.
I am searching for a boot splash strategy for friends and acquaintances for whom I install Slackware. I hope to try this idea soon. Has anybody tried this idea with Current (13.2)?
Is the wiki updated with all the fixes and conversation of this thread?
Lastly, there seems to be concerns this idea will burp if separate partitions are used for /usr or /boot. True or false?
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.
Hi,
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.
Hi,
Yeah I am thinking it proberly tweak needed to the bootup script.
Since it sometimes stop at EOFEOF
Maybe it because the EOFEOF dont get sent to it?
Then I right click make vmware sent Ctrl Alt Del and then it reboot again and works.
So it must be something that blocks the EOFEOF ?
So it could be rewritten and tweak around it?
Now I installed on a Dell server and still get the EOFEOF even without using vmware at all.
Can there be some work around for the EOFEOF?
It just stops there.
I can ping the unit etc. but nothing helps.
I tried CTRL C etc.
but it just keeps at EOFEOF
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.