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.
Are there any significant advantages from booting with an initrd versus just booting from a huge kernel configuration? I have always used the huge kernel and have not had any problems, but am wondering if it would be advantageous to use an initrd?
I am running 14.0 with a hugesmp kernel on a quad core i3 with 4GB of Ram. I just got the 14.1 dvd and wondered if during the upgrade it made any sense to change the way I boot?
Are there any significant advantages from booting with an initrd versus just booting from a huge kernel configuration?
Advantages? Yes. Significant? Well, that is up to you. You will save a few KB, maybe MB, of RAM (not really significant on a system with 4GB of RAM) and will have slightly shorter boottime.
Not significant enough for me to think about using the generic kernel and use an initrd. This would be different of course if I would run my OS from a LVM, RAID or encrypted partition, in which case an initrd is mandatory.
Can't disagree with the above replies.
For me it's personal preference. First thing I do after a fresh install is build a custom kernel from the generic-config in /boot, that way I don't have to use a initrd. Follow Eric's kernel build and your set.
Distribution: Slackware 14.1 64 bit MLED with XFCE 4.12, KDE 4.14.3 and currently using Fluxbox
I use the huge kernel... easier to update and I haven't had any issues. I tried setting up the generic kernel and did see a faster boot time, but I also had issues getting my wireless card working so I switched back to the huge kernel. If it ain't broke don't try to fix it. :-)
I started using Slackware by compiling my own kernel. I thought it worked better, & back in the day, maybe it did. Then I got to the point that I wanted to use "root=LABEL=foo" or "root=UUID=foo" while booting, instead of using a device name. Back then, this required editing the init file in an initrd, so I did that for a while, still compiling a kernel. When slackware went to the 2.6 series kernel & the generic & huge kernels, some maintainer modified the Slackware init file to allow using LABEL & UUID. I started using a generic kernel then & put my fs modules in the initrd. I'm still doing that & am quite happy.
Also note that Pat requires bugs to be reported only if using the generic kernel. See the first paragraph under "*** OTHER NOTABLE CHANGES AND HINTS ***" in CHANGES_AND_HINTS.txt.
If you've never had a problem, you've never had a problem; if it ain't broke, don't fix it.
Personally I have had problems, particularly on some of my older hardware where some device drivers have become buggy as the kernels get updated and regressions sneak in (I don't know why but I've had that happen a few times), so the ability to unload and reload kernel modules when the driver craps out is an attractive feature.
Other than for testing and getting something quickly up and running, I see no reason not to use a generic kernel with modules and an initrd. This isn't like the old days where we had to load modules manually... udev will detect hardware and load modules accordingly. Plus, the mkinitrd_command_generator.sh tool that comes with Slackware makes generating an initrd very simple.
I keep both but use the intrid.gz. I have found that for some hardware issues it made sense and it is is well documented by alien bob. we will see more hardware in the future needing an intrid.img. as the the hardware demands more set up in a working tree as the kernel is passed off to the system.
If it works for you that's all that matters.