[SOLVED] Grub2 with generic kernel

M0M0 · 02-19-2021, 02:33 AM

Quote:

Originally Posted by Hangaber

Possibly just a typo, but if your initrd file is called "inird", change it to initrd.gz or something that the "11_linux_slackcustom" looks for (lines 194 to 204).

Yes this was a typo, thanks.

M0M0 · 02-19-2021, 02:35 AM

Quote:

Originally Posted by teoberi

Not!

Ok, it seems that you know what you're talking about so I will follow your suggestions. Out of curiosity: why is this dangerous?

teoberi · 02-19-2021, 03:02 AM

Quote:

Originally Posted by M0M0

Ok, it seems that you know what you're talking about so I will follow your suggestions. Out of curiosity: why is this dangerous?

Code:

ls -l /boot

My example is for a simple GRUB menu with 2 options, but it can also be adapted if you want more kernel versions.
I know what I'm talking about because before I do something I document myself, then test on the test server or in a virtual machine and finally I apply on the production server.
It does not mean that my solution is unique, others may recommend other options depending on everyone who thinks it is OK for him.

M0M0 · 02-19-2021, 03:29 AM

Quote:

Originally Posted by teoberi

Code:

ls -l /boot

That shows that vmlinuz is symlinked to the huge kernel. So my Question was why it's dangerous to symlink it to the generic kernel and leave everything else untouched.

Quote:

My example is for a simple GRUB menu with 2 options, but it can also be adapted if you want more kernel versions.

I think that is a good idea and followed your advice. Everything worked well, thanks!

Quote:

I know what I'm talking about because before I do something I document myself, then test on the test server or in a virtual machine and finally I apply on the production server.

I try to do the same, after not finding the documentation that I was looking for I asked this question in this forum. Thanks a lot for your patience and your Help!

pghvlaans · 02-19-2021, 03:56 AM

Quote:

Originally Posted by M0M0

So my Question was why it's dangerous to symlink it to the generic kernel and leave everything else untouched.

I'm not sure whether it's dangerous, exactly, but it's probably inconvenient.

The issue is that the vmlinuz and vmlinuz-generic symlinks are overwritten whenever a new kernel is installed. vmlinuz points to the huge kernel by default. So an entry booting off of vmlinuz -> vmlinuz-generic-5.10.17 with initrd.gz would be changed to vmlinuz -> vmlinuz-huge-5.10.18 with initrd.gz when 5.10.18 is installed. It would be necessary to set the symlink again. The next boot may or may not fail if this isn't done (never tested myself).

Using the vmlinuz-generic symlink for the "latest generic kernel" entry instead means that the only thing to do is make a new initrd.gz image.

To preserve the currently-installed generic kernel and initrd in a consistent place for GRUB to find, it's possible to copy vmlinuz-generic and initrd.gz before installing; I send mine to vmlinuz-old and initrd-old.gz, for example.

M0M0 · 02-19-2021, 04:02 AM

Quote:

Originally Posted by teoberi

In order not to load initrd to the huge kernel for the time being, the solution found is to comment the line in the /boot/grub/grub.cfg file.

When I do that I can't boot the huge kernel. The result is a kernel panic and "can't find root fs". I did the following

Code:

menuentry 'Slackware-14.2+ GNU/Linux, with Linux huge' --class slackware_14_2_ --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-huge-advanced-1c468282-94dd-4f04-8454-dd50d150d6bc' {
        load_video
        insmod gzio
        insmod part_gpt
        insmod ext2
        set root='hd0,gpt3'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  065461c1-0ded-4d10-851e-f44a2cc64b12
        else
          search --no-floppy --fs-uuid --set=root 065461c1-0ded-4d10-851e-f44a2cc64b12
        fi
        echo    'Loading Linux huge ...'
        linux   /vmlinuz-huge root=UUID=1c468282-94dd-4f04-8454-dd50d150d6bc ro  
        # echo    'Loading initial ramdisk ...'
        # initrd  /initrd.gz
}

Everything else works fine!

M0M0 · 02-19-2021, 04:08 AM

Quote:

Originally Posted by pghvlaans

To preserve the currently-installed generic kernel and initrd in a consistent place for GRUB to find, it's possible to copy vmlinuz-generic and initrd.gz before installing; I send mine to vmlinuz-old and initrd-old.gz, for example.

That's a smart idea. Is Grub smart enough to figure out that initrd.gz belongs to vmlinuz-generic and that initrd-old.gz belongs to vmlinuz-old? Or do I need to specify which initrd belongs to which kernel?

pghvlaans · 02-19-2021, 04:10 AM

It's not quite smart enough for that. You'd want two separate entries, one with initrd.gz and one with initrd-old.gz.

EDIT: Also, regarding the huge kernel failing to boot, maybe try changing the vmlinuz line to something like this:

Code:

linux   /boot/vmlinuz-huge root=UUID=065461c1-0ded-4d10-851e-f44a2cc64b12 ro

This assumes that /boot and / are on the same partition.

M0M0 · 02-19-2021, 04:15 AM

Ok, do I need to specify this in /boot/grub/grub.cfg by hand after I run grub-mkconfig or is there an easier way?

pghvlaans · 02-19-2021, 04:19 AM

Personally, I'd edit it by hand. grub-mkconfig has given me trouble with pointing at incorrect partitions before, but YMMV. Of course, if GRUB points to nothing but symlinks, there's no need to touch the file or run grub-mkconfig at all once all the entries are correct.

gmgf · 02-19-2021, 05:08 AM

So that grub boots on symbolic links 'vmlinuz' in first and 'vmlinuz-huge' in second, I modify the /etc/default/10_linux

like this:

case "x$machine" in
xi?86 | xx86_64)
list=
for i in /boot/vmlinuz /boot/vmlinuz-huge /vmlinuz-* /boot/kernel-* ; do

like this reinstall grub isn't needed after kernel update on slackware

teoberi · 02-19-2021, 05:37 AM

Quote:

Originally Posted by M0M0

When I do that I can't boot the huge kernel. The result is a kernel panic and "can't find root fs". I did the following

Code:

menuentry 'Slackware-14.2+ GNU/Linux, with Linux huge' --class slackware_14_2_ --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-huge-advanced-1c468282-94dd-4f04-8454-dd50d150d6bc' {
        load_video
        insmod gzio
        insmod part_gpt
        insmod ext2
        set root='hd0,gpt3'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  065461c1-0ded-4d10-851e-f44a2cc64b12
        else
          search --no-floppy --fs-uuid --set=root 065461c1-0ded-4d10-851e-f44a2cc64b12
        fi
        echo    'Loading Linux huge ...'
        linux   /vmlinuz-huge root=UUID=1c468282-94dd-4f04-8454-dd50d150d6bc ro  
        # echo    'Loading initial ramdisk ...'
        # initrd  /initrd.gz
}

Everything else works fine!

Solution for kernel panic:
/etc/default/grub
Add or edit lines:

Code:

GRUB_DISABLE_LINUX_UUID=true
GRUB_DISABLE_LINUX_PARTUUID=false

After the changes, run the command again:

Code:

grub-mkconfig -o /boot/grub/grub.cfg

and comments for last time the two lines (the ones for initrd).
#8 (post no.8) from:
https://www.linuxquestions.org/quest...ic-4175686704/

M0M0 · 02-19-2021, 07:45 AM

Thank you, teoberi! Now everything works perfectly! With your setup there is no need to run grub-mkconfig after a Kernel upgrade, am I correct?

teoberi · 02-19-2021, 08:42 AM

Yes, but be careful when updating the GRUB version, then it may still need to be run.
And now if you say that everything is OK, you should take the time to better understand what you did, a kind of fixation of knowledge, maybe a little howto.
PS
If you are satisfied you can mark the thread as solved and even answer the question:

Quote:

Did you find this post helpful?

what appears after each post.
Another PS
GRUB can be password protected so that existing boot configurations cannot be edited (press the "e" key in the GRUB menu).
If you think it's worth it, can you try to find the solution yourself?
Cheers!

M0M0 · 02-19-2021, 08:56 AM

Thanks, I'm aware of the "solved" function but before your last answer it was not solved for me. But I will do that now.

Yes I'm trying to understand how GRUB and other bootloaders work at the moment, I will definitely get a better understanding with the time!