Grub 2.12 feedbacks

bigbadaboum · 01-16-2024, 01:15 AM

marav
LQ Guru
testing/packages/grub-2.12-x86_64-1.txz: Added.
Here, it doesn't boot correctly
It just cycles to my BIOS

now grub-2.12-x86_64-2.txz work fine for me.
Intel Haswel cpu / American Megatrends International bios

# Configure:
CFLAGS="$SLKCFLAGS" \
./configure \
--prefix=/usr \
--libdir=/usr/lib${LIBDIRSUFFIX} \
--sysconfdir=/etc \
--localstatedir=/var \
--infodir=/usr/info \
--mandir=/usr/man \
--enable-liblzma=yes \
--enable-libzfs=no \
--enable-efiemu=no \
--enable-grub-themes=no \
--enable-grub-emu-pci=no \
--enable-stack-protector=no \
--disable-werror

*stack-protector is not valid in legacy bios mode.

**Pat's comment about grub-core/extra_deps.list made me laugh, but it's worrying for such an important project.

lostintime · 01-16-2024, 02:07 PM

Quote:

I suggest to adapt Slackware to GRUB (instead of adapting GRUB to Slackware), doing what most other distributions do since a long time:

* drop the huge kernels for good and provide only generic ones
* build an initramfs for each new kernel
* keep the running kernel just in case
* adopt a naming scheme handled by grub-mkconfig
* build a new grub.cfg, possibly keeping the previous one as a backup.

I am presuming Pat is juggling all of this because since the original announcement we have not yet seen any commits in the change log regarding GRUB. I agree that adapting Slackware to GRUB rather than vice-versa likely is the path of least resistance and avoids trying to swim upstream.

Dropping huge seems reasonable, but users need an option to retain at least two kernels. I would like to see an admin-defined option for how many kernels to retain. Possibly in /etc/default/grub or a new /etc/default/kernel.

Some people might loathe the idea of an update-grub wrapper script, but I think providing the wrapper script provides consistency with other distros. My thinking is that doing so again avoids trying to swim upstream.

Just my two pennies.

chrisretusn · 01-16-2024, 10:49 PM

With a few modifications to /etc/grub.d/10_linux and /etc/default/grub, Grub handles Slackware just fine. Even if we drop huge, which I think will happen with the recent change to generic. Grub can easily be adapted to work with Slackware with minimal user impact. With the standard install of Slackware, referring to -current here, nothing needs to be done when the kernel is upgraded to a new version (special situations excepted). I'm running this setup, no huge installed, grub-mkconfig only needs to be run once to create the grub.cfg file. This could be during the installation routine or when switching to grub from lilo or elilo. Even with Slackware before the recent changes to generic, nothing has to be done with regard to the kernel aside from recreating an initrd. If the user is using huge nothing need to be done. The vmluniz symlink is the key.

teoberi · 01-17-2024, 12:11 AM

Quote:

Originally Posted by chrisretusn

With a few modifications to /etc/grub.d/10_linux and /etc/default/grub, Grub handles Slackware just fine. Even if we drop huge, which I think will happen with the recent change to generic. Grub can easily be adapted to work with Slackware with minimal user impact. With the standard install of Slackware, referring to -current here, nothing needs to be done when the kernel is upgraded to a new version (special situations excepted). I'm running this setup, no huge installed, grub-mkconfig only needs to be run once to create the grub.cfg file. This could be during the installation routine or when switching to grub from lilo or elilo. Even with Slackware before the recent changes to generic, nothing has to be done with regard to the kernel aside from recreating an initrd. If the user is using huge nothing need to be done. The vmluniz symlink is the key.

I am in the same situation, only that I also use huge. Huge is clean, instead I add the microcode for the processor to generic.
Huge is only used as a backup solution.

Petri Kaukasoina · 01-17-2024, 12:59 AM

In grub.SlackBuild:

Code:

# Install default options file:
mkdir -p $PKG/etc/default/grub.d
cat $CWD/etc.default.grub > $PKG/etc/default/grub.new

I don't see /etc/default/grub.d used: wouldn't 'mkdir -p $PKG/etc/default' be enough?

teoberi · 01-17-2024, 02:02 AM

Quote:

Originally Posted by Petri Kaukasoina

In grub.SlackBuild:

Code:

# Install default options file:
mkdir -p $PKG/etc/default/grub.d
cat $CWD/etc.default.grub > $PKG/etc/default/grub.new

I don't see /etc/default/grub.d used: wouldn't 'mkdir -p $PKG/etc/default' be enough?

Didier's SlackBuild contains:

Code:

# Install default options file:
mkdir -p $PKG/etc/default
cat $CWD/grub.conf > $PKG/etc/default/grub.new || exit 1

Petri Kaukasoina · 01-19-2024, 06:58 AM

OK, now I found it.

When I first noticed /etc/default/grub.d, I thought it's a good idea to put my changes there. But it didn't work when I just put files there. After reading Pat's 0003-support-dropins-for-default-configuration.patch it's clear: the file must have suffix .cfg. For example:

Code:

$ cat /etc/default/grub.d/petri.cfg
GRUB_EARLY_INITRD_LINUX_CUSTOM=intel-ucode-local.cpio
GRUB_CMDLINE_LINUX_DEFAULT="4"
GRUB_CMDLINE_LINUX="raid=noautodetect preempt=voluntary noautogroup vt.default_utf8=0 ipv6.disable=1"

It's similar to /etc/profile.d: the files are sourced. But the files are switched off differently: the x bit does not have any meaning but the file suffix can be changed.

I guess the future setup program on the installation iso will drop config files to that directory to set these kinds of values.

chrisretusn · 01-20-2024, 12:27 AM

Quote:

Originally Posted by Petri Kaukasoina

OK, now I found it.

When I first noticed /etc/default/grub.d, I thought it's a good idea to put my changes there. But it didn't work when I just put files there. After reading Pat's 0003-support-dropins-for-default-configuration.patch it's clear: the file must have suffix .cfg. For example:

Code:

$ cat /etc/default/grub.d/petri.cfg
GRUB_EARLY_INITRD_LINUX_CUSTOM=intel-ucode-local.cpio
GRUB_CMDLINE_LINUX_DEFAULT="4"
GRUB_CMDLINE_LINUX="raid=noautodetect preempt=voluntary noautogroup vt.default_utf8=0 ipv6.disable=1"

It's similar to /etc/profile.d: the files are sourced. But the files are switched off differently: the x bit does not have any meaning but the file suffix can be changed.

I guess the future setup program on the installation iso will drop config files to that directory to set these kinds of values.

Did some playing around with this. Settings in chris.cfg override settings in "grub". Just for the fun of it, I moved the /etc/defaul/grub to /etc/default/grub.d/chris.cfg, restored the original /etc/default/grub from the package, ran 'grub-mkconfig -o /boot/grub/grub.cfg'. Worked as expected, including the "export" values I created.

Petri Kaukasoina · 01-21-2024, 11:14 AM

Quote:

Originally Posted by chrisretusn

With a few modifications to /etc/grub.d/10_linux and /etc/default/grub, Grub handles Slackware just fine. Even if we drop huge, which I think will happen with the recent change to generic. Grub can easily be adapted to work with Slackware with minimal user impact. With the standard install of Slackware, referring to -current here, nothing needs to be done when the kernel is upgraded to a new version (special situations excepted). I'm running this setup, no huge installed, grub-mkconfig only needs to be run once to create the grub.cfg file. This could be during the installation routine or when switching to grub from lilo or elilo. Even with Slackware before the recent changes to generic, nothing has to be done with regard to the kernel aside from recreating an initrd. If the user is using huge nothing need to be done. The vmluniz symlink is the key.

I have been running a similar setup. I use symlinks /boot/vmlinuz and /boot/vmlinuz.old. This is the only edit in /etc/grub.d:

Code:

--- 10_linux.orig       2024-01-02 21:48:56.000000000 +0200
+++ 10_linux    2024-01-17 08:40:09.925844992 +0200
@@ -166,7 +166,7 @@
 case "x$machine" in
     xi?86 | xx86_64)
        list=
-       for i in /boot/vmlinuz-* /vmlinuz-* /boot/kernel-* ; do
+       for i in /boot/vmlinuz /boot/vmlinuz.* ; do
            if grub_file_is_not_garbage "$i" ; then list="$list $i" ; fi
        done ;;
     *)

So, it only generates menuentries for vmlinuz and vmlinuz.old.
And this is a .cfg file under /etc/default/grub.d:

Code:

GRUB_EARLY_INITRD_LINUX_CUSTOM=intel-ucode-local.cpio
GRUB_CMDLINE_LINUX_DEFAULT="4"
GRUB_CMDLINE_LINUX="raid=noautodetect preempt=voluntary noautogroup vt.default_utf8=0 ipv6.disable=1"

I don't install huge. Only generic and modules. No need to generate an initrd. No need to use grub-mkconfig to generate a new grub.cfg. I can reboot directly after the kernel upgrade.

This is the script I use to upgrade the kernel. It removes all other versions of generic kernel+modules and only keeps the currently running ones. Then makes the link vmlinuz.old to the currently running kernel. And installs the new one.

Code:

#!/bin/sh
# change to the directory where the 64-bit kernel packages are:
#cd ~ftp/slackware64-current/slackware64/a
#
if [ $(ls -1 kernel-generic-*.txz 2>/dev/null|wc -l) -ne 1 \
  -o $(ls -1 kernel-modules-*.txz 2>/dev/null|wc -l) -ne 1 ]; then
    echo Wrong number of kernel packages. Mirroring not ready?
    exit 1
fi
if [ -f /var/adm/packages/$(ls -1t kernel-modules-*.txz|head -1|sed 's/\.txz$//') ]; then
  echo The kernel in the directory is already installed.
  exit 1
fi
if [ $(/bin/id -u) -ne 0 ]; then
  echo Run as root.
  exit 1
fi
export TERSE=0
# remove other versions of generic kernel+modules: keep only the currently running ones
RMPKG=$(ls -1 /var/adm/packages/kernel-{generic,modules}* 2>/dev/null|grep -v -- "-$(uname -r)-")
[ "$RMPKG" ] && removepkg $RMPKG
# make vmlinuz.old a link to the currently running kernel for backup
ln -sf vmlinuz-generic-$(uname -r) /boot/vmlinuz.old
# install the new generic kernel+modules
installpkg kernel-{generic,modules}-*.txz

Running the script looks like this:

Code:

# update_kernel
Removing package: kernel-generic-6.6.11-x86_64-1
Removing package: kernel-modules-6.6.11-x86_64-1
kernel-generic-6.6.13-x86_64-1: a general purpose Linux kernel ......... [  21M]
kernel-modules-6.6.13-x86_64-1: Linux kernel modules ................... [ 365M]
#

After that it looks like this:

Code:

$ ls -l /boot/vmlinuz*
lrwxrwxrwx 1 root root       22 2024-01-21 00:11 /boot/vmlinuz -> vmlinuz-generic-6.6.13
lrwxrwxrwx 1 root root       22 2024-01-21 00:11 /boot/vmlinuz-generic -> vmlinuz-generic-6.6.13
-rw-r--r-- 1 root root 12317152 2024-01-15 21:48 /boot/vmlinuz-generic-6.6.12
-rw-r--r-- 1 root root 12300544 2024-01-20 21:27 /boot/vmlinuz-generic-6.6.13
lrwxrwxrwx 1 root root       22 2024-01-21 00:11 /boot/vmlinuz.old -> vmlinuz-generic-6.6.12

chrisretusn · 01-21-2024, 11:49 PM

Quote:

Originally Posted by chrisretusn

With a few modifications to /etc/grub.d/10_linux and /etc/default/grub, Grub handles Slackware just fine. Even if we drop huge, which I think will happen with the recent change to generic. Grub can easily be adapted to work with Slackware with minimal user impact. With the standard install of Slackware, referring to -current here, nothing needs to be done when the kernel is upgraded to a new version (special situations excepted). I'm running this setup, no huge installed, grub-mkconfig only needs to be run once to create the grub.cfg file. This could be during the installation routine or when switching to grub from lilo or elilo. Even with Slackware before the recent changes to generic, nothing has to be done with regard to the kernel aside from recreating an initrd. If the user is using huge nothing need to be done. The vmluniz symlink is the key.

Quote:

Originally Posted by Petri Kaukasoina

I have been running a similar setup. I use symlinks /boot/vmlinuz and /boot/vmlinuz.old.

I took a slightly different approach based on how I was doing it with lilo. This is my /boot:

Code:

# ls -l /boot/vmlinuz*
lrwxrwxrwx 1 root root       22 Jan 21 14:22 /boot/vmlinuz -> vmlinuz-generic-6.6.13
lrwxrwxrwx 1 root root       22 Jan 21 14:22 /boot/vmlinuz-generic -> vmlinuz-generic-6.6.13
-rw-r--r-- 1 root root 12317152 Jan 16 03:48 /boot/vmlinuz-generic-6.6.12
-rw-r--r-- 1 root root 12300544 Jan 21 03:27 /boot/vmlinuz-generic-6.6.13
lrwxrwxrwx 1 root root       22 Jan 21 14:24 /boot/vmlinuz-generic-stock -> vmlinuz-generic-6.6.13
lrwxrwxrwx 1 root root       22 Jan 21 14:24 /boot/vmlinuz-generic-working -> vmlinuz-generic-6.6.12

I copied 10_linux to 09_slackware and use that, I made a number of changes to 09_slackware. the section that collects the boot images I modified as follows:

Code:

-       for i in /boot/vmlinuz-* /vmlinuz-* /boot/kernel-* ; do
+       for i in /boot/vmlinuz-*-[a-z]* /boot/vmlinuz ; do

This picks up any of created symlinks and also vmlinuz. I modified the code to check if we have more than one image in the list, if so, the vmlinuz is dropped and the created symlinks are used. I also modified the script to create menu entries with the name of the created link and the option to a kernel version. Excerpt from /boot/grub/grub.cfg:

Code:

'Slackware-15.0+ with Generic Kernel [Working] (6.6.11)'
'Slackware-15.0+ with Generic Kernel [Stock] (6.6.12)'

I use GRUB_DEFAULT=save and GRUBSAVEDEFAULT=true in the /etc/default/grub.d/*.cfg file to set the default menu option.

When I was using lilo I had an install script, need to work on that again as there are changes.

Petri Kaukasoina · 01-22-2024, 03:44 AM

Quote:

Originally Posted by chrisretusn

Excerpt from /boot/grub/grub.cfg:

Code:

'Slackware-15.0+ with Generic Kernel [Working] (6.6.11)'
'Slackware-15.0+ with Generic Kernel [Stock] (6.6.12)'

I get these:

Code:

'Slackware-15.0+ GNU/Linux'
'Advanced options for Slackware-15.0+ GNU/Linux'

and the advanced ones:

Code:

'Slackware-15.0+ GNU/Linux, with Linux vmlinuz'
'Slackware-15.0+ GNU/Linux, with Linux vmlinuz (recovery mode)'
'Slackware-15.0+ GNU/Linux, with Linux vmlinuz.old'
'Slackware-15.0+ GNU/Linux, with Linux vmlinuz.old (recovery mode)'

chrisretusn · 01-22-2024, 10:16 AM

Quote:

Originally Posted by Petri Kaukasoina

I get these:

Code:

'Slackware-15.0+ GNU/Linux'
'Advanced options for Slackware-15.0+ GNU/Linux'

and the advanced ones:

Code:

'Slackware-15.0+ GNU/Linux, with Linux vmlinuz'
'Slackware-15.0+ GNU/Linux, with Linux vmlinuz (recovery mode)'
'Slackware-15.0+ GNU/Linux, with Linux vmlinuz.old'
'Slackware-15.0+ GNU/Linux, with Linux vmlinuz.old (recovery mode)'

Nice!

I set the following in my etc/default/grub.d/*.cfg file (I like the flat menu). With my setup I see no need for (recovery).

Code:

GRUB_DISABLE_RECOVERY=true
GRUB_DISABLE_SUBMENU=true

This gives me an idea I am going to try out with a 09_slackware I am working on.

teoberi · 01-27-2024, 02:30 PM

What we do with GRUB 2.12 from "testing"?

Debian and OpenSUSE already have packages ready.

There are already several commits in the Git GRUB repository.

Damn GRUB is hard to maintain, would there be another viable alternative?

Didier Spaier · 01-27-2024, 03:12 PM

Quote:

Originally Posted by teoberi

What we do with GRUB 2.12 from "testing"?

Debian and OpenSUSE already have packages ready.

There are already several commits in the Git GRUB repository.

Damn GRUB is hard to maintain, would there be another viable alternative?

Maybe Patrick waits for the Argon2id key derival function to be supported by GRUB 2.12+, as this is recommended by mjg59 Or maybe he would prefer to ship an Unified Kernel Image , as is trying to do Fedora (following You Know Who), and get rid of a separate initramfs for good? Who knows? But any of these could delay the release of Slackware 15.1 by several years

chrisretusn · 01-28-2024, 01:05 AM

Quote:

Originally Posted by teoberi

What we do with GRUB 2.12 from "testing"?

Debian and OpenSUSE already have packages ready.

There are already several commits in the Git GRUB repository.

Damn GRUB is hard to maintain, would there be another viable alternative?

Installed it? I did. No issues.

Both Debian and OpenSUSE are using the same version in testing.

Those are commits toward the next version release, are you expecting Pat to make a package out of git?

How is grub so hard to maintain? Just install it and start using it. Perhaps you have a special use case that's in one of the commits?

There could be issues that Pat is aware of in Slackware that we are not aware of or it's like Didier Spaier stated.