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?

Thanks
Robert

If you had no problem then there is no advantage for a change. Fix it only when it's broken.

1 members found this post helpful.

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.

1 members found this post helpful.

running my 14.1 (32bit) with 2gb ram with hughsmp here too.. all nice all fine. i dont see a reason to change it as long as it works.

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.

I've ran both. To me the Huge Kernel is just less to setup and worry about.

1 members found this post helpful.

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

1 members found this post helpful.

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.
Regards,
Bill

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.

1 members found this post helpful.

I use the generic kernel, but always keep an entry for the huge one in my lilo.conf, like this:

it uses the default vmlinuz link, just in case. I learned this the hard way...

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.