SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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.
People still use an initrd.gz file? I though the huge kernel solved that issue entirely.
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.
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.
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.
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?
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.
Last edited by ruario; 08-27-2012 at 05:17 AM.
Reason: added a comma and deleted a word
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.
Quote:
Originally Posted by Richard Cranium
Actually, the installer already should know what filesystems you intend to use for your partitions. It asks you fairly early in the process.
How many disk drive controllers are you going to build into the generic image? The installer doesn't know about that.
I think you'll end up with what we already have: a kernel with everything in it so that you can do an initial install and a generic kernel with the bare minimum to boot with which you use an initrd.
Unless someone can write a script that would troll through /sys to figure out what minimum set of modules should be loaded by initrd to allow you to boot into runlevel 3.
Quote:
Originally Posted by Alien Bob
The script /usr/share/mkinitrd/mkinitrd_command_generator.sh does just that.
Quote:
Originally Posted by Richard Cranium
Cool. Does the installer ask if you want to run this? (I haven't done a full install in quite a while.)
Quote:
Originally Posted by Alien Bob
No, but internally, the team had this working end of 2008 already. It's just never gone public.
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.
Last edited by ruario; 08-27-2012 at 05:14 AM.
Reason: Initially I missed out one of the quotes from the previous thread
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.