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.
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.
How about those who reboot several times a day -like me? Is the goal of saving time during bootup simply invalid under Slackware because the original setup takes no thought of it? My system, which is pretty similar to Slackware, boots to CLI login in about 6 seconds -10 seconds to GUI login. Slackware itself is pretty much bound to take 2-3 times as long (on this machine) because of the extra things it does. Most of it is done for sanity's sake, but most other systems do not find all of these things necessary. I'm particularly irked by the icon-cache routines since I mostly don't use gtk2 at all.
I achieve those times partly by eliminating the things which really are not necessary during bootup. Anything somebody wants to add back can be done in rc.local. Most of the time improvements actually came from other optimizations instead of simply by-passing possibly-useful actions. Anyone who really wants/needs faster boot times on Slackware could do the same. But it means altering several standard things so persistence of changes becomes a problem when updating packages. For myself, all the hacks are built right into the original packages. For instance, I use a faster shell to run the init scripts -but not simply a link from /bin/sh to ash/dash -since that would compromise the use of the many shell scripts which are actually using/needing the special behaviour of /bin/bash as /bin/sh. I've re-written all the init scripts to use the alternate shell directly (calling it /bin/initsh). Other optimizations include using hard-coded paths to all executables -resolving PATHs and links both take up time. Of course, some things are backgrounded to promote faster times. Also, careful use of sourcing as opposed to direct execution saves a few extra instances of the shell and avoids the latency of starting each instance. One thing I have not implemented (yet, anyway), would be the use of a single conf file which would control the desired startup status of optional routines by using variables: instead of checking if each rc.d script is executable in order to decide if it is wanted, the answer would be in a conf file. I believe that Archlinux does something like this...
That said, my system avoids all the 'serious' hacks such as readahead, preload, patches to X, etc, while still achieving a pretty decent speedup of ~60%, while maintaining a sane startup which does not rely on using cron to make up the difference.
Of course your concerns about bootspeed are valid for you. The real question would be: Is it worth to do all that work for having a system starting in 10 seconds to GUI instead of 20-30, instead of just using the already available standby function and have an instant on system? If the bootspeed matters so much that you do all this, standby would be by a far more logical conclusion.
But honestly, is bootspeed really that important to you?
First split that boot time into two parts - Kernel and the rest from Init. There is nothing much you can do to reduce the boot time of the kernel (except lilo compact line) and the rest since initrd is mainly slowed down by massive index rebuilding which can be disabled if you wish so. I however would not care about boot time at least on the desktop as it is once-a-day event. I have that 40 seconds to wait till I get the prompt.
Don't blame things you have no understandings for. Blaming a kernel for taking 40 seconds to start is really using a hammer. The kernel can bootup in seconds. What's slow is utter crap userspace that taking long.
It might be udev that went for a ride with a bicycle, a useless initrd. or a something in the kernel which tries to load, which is none existance in OP's hardware. 40 Seconds for a bootup in Slackware is a very very long bootup and it only does take so long for me from the installation cd when actual installing the dist.
There's really no right or wrong way to do things, neither do i say so. But if OP want's a initrd, a generic kernel and everything as a module. Then it's his own choice - He might find it useful with everything compiled as modules, even though he don't have 99% of what's turned on in the kernel at all - nor do he use it either. I can't know, i just speculate.
Atleast, Slackware actual starts rather than doing things in the background, which makes it feel faster.
For the question to OP. Please try to figure out which 'tools' are slow, and please report more. Atleast try to compile your own kernel, and turn of stuff you have no use for. And please come back when saying so.
It's all about configuration - not dists themself. If it takes 40 seconds to boot a kernel, something went very wrong. I understand the installation CD takes so long to boot and why it does.
That is a valid argument, but do you really care if the system takes 30 seconds or a minute to boot if you only do it once a day?
I'm not the OP who raised the question. Regardless, for myself, once a day? No, but gnashley raised a point I did not mention: multiple reboots during the day. I experiment a lot using multiple partitions and virtual images. Reboot times become important with such usage.
Everybody is a little different. Such discussions are important for people for whom boot speeds are important. For everybody else the discussion is irrelevant and questioning the usage habits of people is not going to help the discussion.
My system, which is pretty similar to Slackware, boots to CLI login in about 6 seconds -10 seconds to GUI login.
Gnashley, do you have copies of your scripts or explanations posted somewhere?
Woodsman, here's an older package of my init scripts: http://distro.ibiblio.org/amigolinux....7-i586-1.tpkg
Note that the package is actually a tarred, xz'ed archive just like slackware packages. *DO NOT* try to install or use the package on your Slackware box as it will leave it unbootable! As I mentioned, the scripts are used in conjunction with the 'dash' shell -renamed to 'initsh'. IOW, I use a shell dedictaed to the init process. The scripts would mostly work with ash as well. They will also work with bash. At first, I made the whole thing so that you could choose to use either bash or dash by making /bin/initsh a link to whichever you liked. Since I roll my own here, I am able to control the content of all init subscripts. Wherever possible, they have been converted to use /bin/initsh as well, although a few still use /bin/sh because of bashisms. Lots of little tricks in there -some of which I adapted from earlier work by GrapefruitGirl and tuxdev -they were working on strict POSIX scripts for init. Accessory scripts come with their individual packages. A bit of wrangling/checking might make the whole thing work on a Slackware box.
Oh boy did this start a conversation. Thanks, it's good to know that it's normal. I was afraid that I might have messed something up. It is installed on a netbook, but the battery doesn't work so it pretty much stays in the same place. I'd leave it on but I'm pretty much always messing with it and playing with different OS's and stuff.