GRUB2 in Slackware? Discussion and Instruction.

marav · 08-12-2023, 02:04 PM

Quote:

Originally Posted by volkerdi

This makes a good point. I do not see any reason why GRUB2, once installed, ever needs to be futzed with again. Is this not one of the selling points of GRUB? Unlike LILO, the files referenced in the GRUB config file can be completely changed out without any requirement to reinstall or reconfigure GRUB. But in order for this to work, *the filenames must remain the same*.

Now, I know that LuckyCyborg loves versioned filenames as used elsewhere almost as much as he believes I love LILO, elilo, etc, but I don't think that's how we want to do this. I think that initrd.gz will be fine as an unversioned file as it's always been. The kernel file will be versioned (as always), but with an unversioned symlink pointing to it (and used in the GRUB config). Then when a new kernel (and symlink) is installed, and the initrd updated, everything should just work concerning GRUB. Versioning a Slackware initrd doesn't make a lot of sense anyway - it can support multiple different kernel versions with a single initrd. What's the filename version supposed to be then?

The scripts that come with GRUB2 as well as things like os-prober are probably not relevant for our purposes as we just want a simple starting configuration. Since we don't plan to mess with it later, you'll be able to change it (or not) without a future update plowing over the top of it.

Also, this method allows managing GRUB2 from a foreign operating system without having to reconfigure anything there after a Slackware kernel/initrd update.

And I do exactly the same with my custom kernels
That's why I don't have to modify my grub.cfg, which looks like this:

Code:

menuentry "Slackware-15.0+ , kernel [custom]" {
        echo    Linux Custom…
        linux   /boot/vmlinuz-custom root=UUID=f18cf16b-a61d-4186-966d-0a208cda185c ro resume=/dev/nvme0n1p2 mem_sleep_default=deep amd_pstate=active
        echo    Linux initrd
        initrd  /boot/initrd-custom.gz
}
menuentry "Slackware-15.0+ , kernel [generic]" {
        echo    Linux Generic…
        linux   /boot/vmlinuz-generic root=UUID=f18cf16b-a61d-4186-966d-0a208cda185c ro resume=/dev/nvme0n1p2 mem_sleep_default=deep
        echo    Linux initrd
        initrd  /boot/initrd.gz
}
menuentry "Slackware-15.0+ , kernel [huge]" {
        echo    Linux Huge…
        linux   /boot/vmlinuz-huge root=/dev/nvme0n1p3 ro resume=/dev/nvme0n1p2 mem_sleep_default=deep
}

elcore · 08-12-2023, 02:21 PM

Modern windows must have ESP which is fat32 so it requires a file and not a symlink.
I'm unaffected since I only use CSM legacy and specifically asked for board with legacy MBR support.

But folks who must have ESP, must copy vmlinuz-xyx into ESP/vmlinuz or write vmlinuz-xyz into grub.cfg
Maybe there is another workaround, but I'm not aware of anything else ATM.

I'd certainly prefer not to touch grub.cfg after initial setup, too.

garpu · 08-12-2023, 02:36 PM

Quote:

Originally Posted by volkerdi

Now, I know that LuckyCyborg loves versioned filenames as used elsewhere almost as much as he believes I love LILO, elilo, etc, but I don't think that's how we want to do this. I think that initrd.gz will be fine as an unversioned file as it's always been. The kernel file will be versioned (as always), but with an unversioned symlink pointing to it (and used in the GRUB config). Then when a new kernel (and symlink) is installed, and the initrd updated, everything should just work concerning GRUB. Versioning a Slackware initrd doesn't make a lot of sense anyway - it can support multiple different kernel versions with a single initrd. What's the filename version supposed to be then?

Wait, wait. I've always been generating a new initrd for every kernel (and naming it with the version name).

From mkinitrd_command_generator.sh:

Code:

-k <kernelversion>        Use specific kernel version. Or, support
	                            more than one kernel version by passing a
	                            list of versions separated by colons (:).

The more you know dot gif.

I've only been doing separate ones for, oh, the past 15 years...

volkerdi · 08-12-2023, 02:49 PM

Quote:

Originally Posted by elcore

Modern windows must have ESP which is fat32 so it requires a file and not a symlink.

There's no requirement for the kernel/initrd to reside on the ESP.

pghvlaans · 08-12-2023, 02:58 PM

Quote:

Originally Posted by elcore

But folks who must have ESP, must copy vmlinuz-xyx into ESP/vmlinuz or write vmlinuz-xyz into grub.cfg
Maybe there is another workaround, but I'm not aware of anything else ATM.

grub-install puts an EFI stub in ESP, which is used at boot time to load GRUB. This is immaterial to what needs to go in grub.cfg, so far as I know. My systems all have ESP and use the kernel symlinks in grub.cfg, and it's never given me trouble.

Didier Spaier · 08-12-2023, 03:04 PM

Quote:

Originally Posted by volkerdi

Also, this method allows managing GRUB2 from a foreign operating system without having to reconfigure anything there after a Slackware kernel/initrd update.

But then this foreign operating system won't probably detect Slackware's initrd because in the file util/10_linux.in in the sources of grub-2.12-rc1 there is this code snippet:

Code:

  initrd_real=
  for i in "initrd.img-${version}" "initrd-${version}.img" \
       "initrd-${alt_version}.img.old" "initrd-${version}.gz" \
       "initrd-${alt_version}.gz.old" "initrd-${version}" \
       "initramfs-${version}.img" "initramfs-${alt_version}.img.old" \
       "initrd.img-${alt_version}" "initrd-${alt_version}.img" \
       "initrd-${alt_version}" "initramfs-${alt_version}.img" \
       "initramfs-genkernel-${version}" \
       "initramfs-genkernel-${alt_version}" \
       "initramfs-genkernel-${GENKERNEL_ARCH}-${version}" \
       "initramfs-genkernel-${GENKERNEL_ARCH}-${alt_version}"; do
    if test -e "${dirname}/${i}" ; then
      initrd_real="${i}"
      break
    fi
  done

So the naming scheme 'initrd.gz" is not under the radar of "grub-mkconfig".

Similarly if this foreign operating system uses os-prober, Slackware's initrd won't be found as in the file linux-boot-probes/mounted/common/90fallback in os-prober-1.81 there is this code snippet:

Code:

    for kernfile in $(eval ls -vr "$mpoint$kernpat" 2>/dev/null); do
        kernbasefile=$(echo "$kernfile" | sed "s!^$mpoint!!")
        if [ -f "$kernfile" ] && [ ! -L "$kernfile" ]; then
            initrdname=$(echo "$kernfile" | sed "s/vmlinu[zx]/initrd\*/")
            # Yellow Dog Linux appends .img to it.
            initrdname1="${initrdname}.img"
            # Arch Linux names its initrds weirdly.  We take
            # some care here to avoid false positives on other
            # systems, since kernel.img could conceivably be a
            # kernel itself.
            initrdname2=$(echo "$kernfile" | sed -n 's/vmlinu[zx]\([0-9][0-9]*\)/kernel\1/p' | sed 's/$/.img/')
            # Dracut initramfses are named differently again.
            initrdname3=$(echo "$kernfile" | sed "s/vmlinu[zx]/initramfs\*/" | sed 's/$/.img/')
            # And Gentoo's also
            initrdname4=$(echo "$kernfile" | sed "s/kernel/initramfs\*/")
            # Also Alpine
            initrdname5=$(echo "$kernfile" | sed "s/vmlinu[zx]/initramfs\*/")
            foundinitrd=0
            for initrd in $(eval ls "$initrdname" "$initrdname1" "$initrdname2" "$initrdname3" "$initrdname4" "$initrdname5" 2>/dev/null); do
                if [ "$initrd" != "$kernfile" ] && [ -f "$initrd" ] && [ ! -L "$initrd" ]; then
                    initrd=$(echo "$initrd" | sed "s!^$mpoint!!")
                    result "$partition:$kernbootpart::$kernbasefile:$initrd:root=$mappedpartition"
                    exitcode=0
                    foundinitrd=1
                fi
            done
            if [ "$foundinitrd" = 0 ]; then
                result "$partition:$kernbootpart::$kernbasefile::root=$mappedpartition"
                exitcode=0
            fi
        fi
     done

So in this case too initrd.gz will not be found thus if the boot menu includes an entry for Slackware booting will fail. Unless grub and/or os-release are patched to handle this naming scheme. I do that in Slint but do not expect that all foreign operating systems will follow suit. Patches can be proposed also upstream, but it would take years for them be applied and the patched versions be used by foreign operating systems.

Additionally having the kernel symlinked leads to duplicate boot entries in the grub menu if grub-mkconfig is used.

Quote:

Versioning a Slackware initrd doesn't make a lot of sense anyway - it can support multiple different kernel versions with a single initrd. What's the filename version supposed to be then?

Yes mkinitrd can build an initrd for multiple different kernel versions, but that it can does not imply that it should. I see no clear benefit doing that.

Hints:

Adopting something like the Debian naming scheme would be safe.

Here and now in /boot I have:

Code:

System.map-6.1.29
System.map-6.1.40
config-6.1.29
config-6.1.40
efi
grub
initramfs-6.1.29.img[1]
initramfs-6.1.40.img[1]
vmlinuz-6.1.29
vmlinuz-6.1.40

[1]Using dracut but it also allows to customize the name of the initrd.

GazL · 08-12-2023, 03:13 PM

Quote:

Originally Posted by volkerdi

There's no requirement for the kernel/initrd to reside on the ESP.

Unless, like me, you made the mistake of having your /boot on a LUKS2/Argon2d protected LVM setup, which apparently GRUB2 still doesn't like.

If I swap to grub then I'll likely have to use the --esp-directory=/boot/efi --boot-directory=/boot/efi approach and copy my kernels over there like I do now, or wipe my disk and repartition from scratch.

Alternatively, I'll just stick with the EFI_STUB approach, which has been working reliably here, since I dropped ELILO.

Not complaining, you do what you have to and I'll workaround it, just raising a consideration that might bite some folk.

Didier Spaier · 08-12-2023, 03:17 PM

Quote:

Originally Posted by GazL

Unless, like me, you made the mistake of having your /boot on a LUKS2/Argon2d protected LVM setup, which apparently GRUB2 still doesn't like.

I assume that you meant Argon2id. And think it will be supported in grub-2.12, that I hope will be included in Slackware 15.1.

GazL · 08-12-2023, 03:27 PM

Quote:

Originally Posted by Didier Spaier

I assume that you meant Argon2id. And think it will be supported in grub-2.12, that I hope will be included in Slackware 15.1.

Ooops, yes I missed the "i". That's what I meant.

ZhaoLin1457 · 08-12-2023, 05:21 PM

Quote:

Originally Posted by volkerdi

Now, I know that LuckyCyborg loves versioned filenames as used elsewhere almost as much as he believes I love LILO, elilo, etc, but I don't think that's how we want to do this. I think that initrd.gz will be fine as an unversioned file as it's always been. The kernel file will be versioned (as always), but with an unversioned symlink pointing to it (and used in the GRUB config). Then when a new kernel (and symlink) is installed, and the initrd updated, everything should just work concerning GRUB. Versioning a Slackware initrd doesn't make a lot of sense anyway - it can support multiple different kernel versions with a single initrd. What's the filename version supposed to be then?

I have a question: how big do you estimate an initrd will be with modules from 100 kernels?

Because this can happen if the user uses -current.

And one more question: do you intend or not to introduce the ability to automatically generate initrd when a kernel is installed?

What LuckyCyborg wants is what he has seen other Linux distributions do. And as someone who has used Fedora for a long time, I can confirm that Fedora does the same.

I think it should be left up to the users if they want to use initrd with versioned names or if they want to update their GRUB2 configuration or not.

For this I have a very simple proposal:

to install a script, called /boot/setup-kernel that accepts a single optional parameter, the version of the kernel to be processed. Something like that

Code:

#!/bin/sh

VERSION=${1:-$(uname -r)}

mkinitrd -k ${VERSION}

It is important that this script has a .new treatment and is called from install/doinst.sh from the kernel package. Of course, if it is executable.

And that the packages kernel-generic and kernel-modules be merged.

I think that this solution solves all the options that users want. I, for example, will modify /boot/setup-kernel in this way

Code:

#!/bin/sh

VERSION=${1:-$(uname -r)}

mkinitrd -c -k ${VERSION} -o /boot/initrd-${VERSION}.img -s /boot/initrd-${VERSION}

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

I think the most important feature is that the kernel-generic and kernel-modules packages are merged, and this package install/doinst.sh calls a script that users can modify as they wish.

That they want to use initrd with version in name or not, that they want to update or not /boot/grub/grub.cfg, this they can adapt as they want.

LuckyCyborg · 08-12-2023, 07:40 PM

Quote: