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.
The problem is the -c option which clears the modules of the previous kernel from the initrd. If you leave that out, mkinitrd adds modules for the new kernel without removing the old ones.
Ah, okay. That makes sense, I'll try that. Thanks.
It looks like I can either boot into the old kernel or the new one. I re-ran the mkinitrd.sh command below for the 5.15.19 kernel and was able to boot into it, but then I was unable to boot into the 5.16.8 kernel so I re-ran the mkinitrd.sh command for the new kernel and was able to boot into the new kernel but unable to boot into the old kernel.
As I said I don't use initrd, but the boot manager should be able to boot another kernel with another initrd. In most distroes I have tried, initrd also takes on a version number corresponding with the relevant Kernel, and that initrd is used in the boot manager to boot the Kernel with that particular initrd.
You could replicated that process, probably by doing like was said in a previous thread and back up your old initrd.
This brings up another question, though. What does geninitrd do? I read that this is new to 15, but I am not sure what it does exactly and if it's something that I need to use.
As I said I don't use initrd, but the boot manager should be able to boot another kernel with another initrd. In most distroes I have tried, initrd also takes on a version number corresponding with the relevant Kernel, and that initrd is used in the boot manager to boot the Kernel with that particular initrd.
You could replicated that process, probably by doing like was said in a previous thread and back up your old initrd.
I wonder if making a new initrd file (/boot/initrd.gz) would be a better way to go?
The problem is the -c option which clears the modules of the previous kernel from the initrd. If you leave that out, mkinitrd adds modules for the new kernel without removing the old ones.
Removing the -c option did fix my problem. Thanks. This made me think if creating a new initrd file (/boot/initrd01.gz) for each kernel would be a better way to go, or would using the -c option complicate things for that as well?
This brings up another question, though. What does geninitrd do? I read that this is new to 15, but I am not sure what it does exactly and if it's something that I need to use.
It seems to me that it automatically looks which generic kernels you have installed and builds an initrd which contains the needed modules for all of them in one initrd, just like what you did, but automatically. No manual mkinitrd_command_generator.sh or mkinitrd commands needed.
It seems to me that it automatically looks which generic kernels you have installed and builds an initrd which contains the needed modules for all of them in one initrd, just like what you did, but automatically. No manual mkinitrd_command_generator.sh or mkinitrd commands needed.
That's what I thought as well. Must be more useful for grub, I would think. Otherwise how would you update lilo if you use the geninitrd command?
You can edit /etc/lilo.conf using a text editor. It's simple to change the 'image' lines to point to the file names of the correct kernels, and to change 'label' lines to contain suitable labels for them.
The problem is the -c option which clears the modules of the previous kernel from the initrd. If you leave that out, mkinitrd adds modules for the new kernel without removing the old ones.
Thanks for this, Petri. Even after all these years, I had never even considered this! I guess I had always just assumed that building a distinct initrd was required for each kernel installed.
On the few boxes where I actually keep multiple kernels, I've always done something like this:
Both methods you describe--specifying multiple kernels with the "-k" or running mkinitrd without "-c" so as to add modules to the existing initrd-tree--sound great! A single initrd.gz image that handles all the installed kernels? Awesome.
Last edited by JayByrd; 02-12-2022 at 11:23 AM.
Reason: correction.
You can edit /etc/lilo.conf using a text editor. It's simple to change the 'image' lines to point to the file names of the correct kernels, and to change 'label' lines to contain suitable labels for them.
Okay, I tested this out on my laptop, also running 15.0 stable.
I used the geninitrd command instead of mkinitrd.sh command and then just had to add the entry in lilo.conf for the 5.15.19 kernel (copied from my tower) and everything works nicely. I haven't tried installing a new kernel yet, I'll try that next and will see if the geninitrd command is enough for the new kernel as well.
Okay, I tested this out on my laptop, also running 15.0 stable.
I used the geninitrd command instead of mkinitrd.sh command and then just had to add the entry in lilo.conf for the 5.15.19 kernel (copied from my tower) and everything works nicely. I haven't tried installing a new kernel yet, I'll try that next and will see if the geninitrd command is enough for the new kernel as well.
When installing a new kernel geninitrd will just generate the initrd for the new kernel only. The mkinitrd command is still needed, but without the -c option. Once I used the mkinitrd command for both kernels I could log into both of them. Though I cannot boot into the huge kernel as I am getting kernel panic (on my laptop), but as long as the generic kernels work I will be uninstalling the huge kernel on my laptop, I already uninstalled it on my tower.
When installing a new kernel geninitrd will just generate the initrd for the new kernel only. The mkinitrd command is still needed, but without the -c option. Once I used the mkinitrd command for both kernels I could log into both of them. Though I cannot boot into the huge kernel as I am getting kernel panic (on my laptop), but as long as the generic kernels work I will be uninstalling the huge kernel on my laptop, I already uninstalled it on my tower.
The other option is to just modify grub.cfg. I do the following and this only makes changes to the first menuentry section.
Code:
#modify as needed for specific kernel
/usr/sbin/grub-mkconfig | sed '/^menuentry/,/^}/{s/5.15.19/5.16.8/; s/vmlinuz\-huge\-/vmlinuz\-generic\-/}' > /boot/grub/grub.cfg
It's also possible to 'cp /etc/mkinitrd.conf.sample /etc/mkinitrd.conf' and then just once edit /etc/mkinitrd.conf to contain the list of module names and other unchanging options and then simply run 'mkinitrd -F -k 5.16.8' to make initrd after kernel upgrades. (-F for using values from mkinitrd.conf).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
