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.
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
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.