Suggested update to README.initrd in Slackware 14
 

Using the mkinitrd command in the README.initrd file linked to in the /boot directory will not work with a luks-encrypted file system. The result will be a system that won't boot.

I suggest that a line be added either giving the correct command or a reference to the README_CRYPT.TXT which includes the correct command.

DNA
AKA mrascii

People still use an initrd.gz file? I though the huge kernel solved that issue entirely.

I'm pretty sure the generic kernel+initrd was solving the problem of on-demand module loading with configurable options. The huge kernel solved installation with a single monolithic kernel rather than having to ship several but its purpose in a running system has always been as a backup.

As to the question at hand, if you're using LUKS encryption then you're expected to read README_CRYPT.TXT anyway, which gives you more than enough information including how to create a satisfactory initrd. I think that file is more appropriate since it is more specific (and thus trumps the more generic README.initrd). Just my opinion though.

huge kernel does solve that problem, but for daily usage, people tends to use generic kernel

Sure people use initrd.gz files. Not everyone needs everything included in the huge kernel. Yes, you could compile your own kernel with everything you need and no more but it is simpler and faster just to use the generic kernels with an initrd.gz.

First thing I do after hitting "EXIT Slackware Setup", even before the first reboot, is chroot into my freshly installed Slackware and build an initrd.

If you stay with the huge kernel, just look out for "unsupported features" in your boot messages.

Besides, with some Intel graphics cards, you need to include i915 and intel_agp into your initrd for KMS to work.

Snap, I do exactly the same! ;)

Stop pulling my leg.

I do it after the first reboot, using /usr/share/mkinitrd/mkinitrd_command_generator.sh as a guideline. Is there any advantage to doing it before the first reboot?

One less reboot? Also it means you don't even have to install the huge kernel at all, even for first boot (granted you could have also avoided this by booting from the huge kernel on the Live CD at the isolinux boot prompt but configuring everything up front seems neater).

In my case I don't use Lilo (and hence don't install it) any more. Instead I use extlinux. I manually setup and configure extlinux at the same time as making my initrd. By doing it all immediately after install, the whole boot process is configured and complete, without having to boot from the CD or USB disk again.

+1
Along with moving /tmp into a tmpfs.

I don't do this but have been considering it of late. Perhaps I will when I do my first clean install of Slackware 14.

afaik you need to build an initrd.gz also for LVM; at least if your entire setup is on LVM. iirc I would get kernel panics if I didn't build the initrd before the first reboot... A simple mkinitrd -k <kernel version> -f <filesystem> -r <root device> -h <resume from hibernate device> -L -o <outputfile> is all that's needed, but still, it's needed.

Why not to add mkinitrd&generic kernel to the slackware installer?

I believe the team have looked at this. I recall the following discussion from another thread.

Not sure why it was never included in the installer, though presumably they hit an problem.

In any case they are certainly aware this would be a nice to have addition. So I suspect it could indeed turn up one day. As for the exact time scale of when that it is, I suspect it it like everything else in Slackware. It'll appear when it is ready. ;)

One less reboot, since you'd have to configure LILO accordingly. When you have more than twenty machines to install (as I do right now in a school), this sort of detail is a timesaver. (Thus I can spend the time saved playing minesweeper or posting on LQ :D)

Ah, yes, never thought of that. I've only got three. :)

Exactly right. I should have made it clear that I encrypted /, /home and swap. Even booting huge.s an initrd is needed. In addition, following the recovery instructions to boot using "root=/dev/sdax" will not work if root is encrypted. The / volume must first be decrypted and made active then /proc and /sys mounted before lilo can be used to write a new lilo.comf file.

DNA
AKA mrascii

Yes, The README_CRYPT.TXT is excellent and your point his well taken, T3slider. However, a sentence in README.initrd would remind anyone to use the instructions in the README.CRYPT.TXT instead if they are using luks and LVM. I purposely used the mkinitrd command in README.initrid upgrading from RC2 to RC3 to see if it would break my test box which it did and to make sure I could recover from a non-bootable encrypted LVM if needed.

DNA
AKA mrascii

Choosing a kernel was, at one time, included originally in the Slackware installation, but the scripts were removed possibly because it was confusing to do so and using the generic kernel with initrd.gz was considered a customization feature that often proved unnecessary for common systems.

Plus with the addition of rerunning LILO each time you reconfigured the kernel, you would also have to regenerate the initrd.gz with the specific modules you needed if you upgraded the kernel. Huge eliminated the need to hunt down and trial and error solve which modules were needed at load time so it became the default.

The last time I saw this was between releases 10.0 and 13.0 before EXT4 was finalized as the recommended default Slackware filesystem. Haven't seen it since.

From -current's CHANGES_AND_HINTS.TXT (and as far as I know CHANGES_AND_HINTS.TXT from at least 12.0, which introduced the huge/generic split):
The generic kernel replaced the myriad of specific kernels shipped with pre-12.0 Slackware, and was always meant to be used as the standard kernel. Even in 12.0's CHANGES_AND_HINTS.TXT it mentions the huge kernel's use as primarily an install kernel. Huge has always been the default kernel because it requires no setup, but it has always been advised to switch to the generic kernel. An initrd should be nothing new to those using post-11.0 Slackware.

The good thing is we do have a choice.

I am using the huge kernel but nothing here: