GRUB2 in Slackware? Discussion and Instruction.

marav · 08-13-2023, 06:45 AM

Quote:

Originally Posted by bigbadaboum

I think there may be a problem with the patch:

# Since upstream apparently can't be bothered, let's fix using ext* filesystems
# created with what are now the default options:
zcat $CWD/7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763.patch.gz | patch -p1 --verbose || exit 1

with grub-2.06-x86_64-5.txz
https://mirrors.slackware.com/slackw...source/a/grub/

I use for 2 years the slackbuild grub-2.06-x86_64-4 with:
--enable-libzfs=no \
--enable-efiemu=no \
--enable-grub-themes=no \
--enable-grub-emu-pci=no \
(don't judge me i'm a caveman )

grub-2.06-x86_64-4.txz 5,2 Mo

now with grub-2.06-x86_64-5 with:
--enable-libzfs=no \
--enable-efiemu=no \
--enable-grub-themes=no \
--enable-grub-emu-pci=no \

grub-2.06-x86_64-5.txz 12,2 Mo

No problem here with your config (only ~4k)

Code:

$ ls -l /tmp/grub-2.06-x86_64-*
-rw-r--r-- 1 root root 10206068 Aug 13 13:42 /tmp/grub-2.06-x86_64-4.txz (without the patch, more or less the same size on cumulative: https://slackware.uk/cumulative/slackware64-current/slackware64/a/grub-2.06-x86_64-4.txz)
-rw-r--r-- 1 root root 10202388 Aug 13 13:37 /tmp/grub-2.06-x86_64-5.txz (with the patch)

LuckyCyborg · 08-13-2023, 09:08 AM

Quote:

Originally Posted by Petri Kaukasoina

If another OS wants to see versioned initrd, you can still use a single /boot/initrd.gz for multiple kernels, if you add versioned symlinks to it.

And who/what will make your initrd and these symlinks? You by hand or a script will do the job on fly?

I believe that the fundamental question is the one put by ZhaoLin1457 in this thread: will be there a single package for kernel and its modules which execute on its install/doinst.sh a script customizable by user?

The root feature which gives to user the freedom to customize as he like is this snippet on that package install/doinst.sh

Code:

if [ -x boot/setup-kernel ]; then
  /bin/chroot . /bin/sh -c "/boot/setup-kernel @@KERNEL_VERSION@@"
fi

I believe that does not matters if is better a mega-initrd (even with versioned symlinks) or the ones with versioned names like everybody else uses, or that you prefer to write by hand a /boot/grub/grub.cfg or not, as long this feature exists.

Heck, the Slackware even does not need to ship that /boot/setup-kernel script, as long that that 3 lines snippet exists on the install/doinst.sh from that package which ship both the kernel and its modules.

BUT, if this feature exists, the Slackers can choose from a fully manual configuration of initrd and GRUB2 up to a fully automatic configuration of them. As the Slackers themselves like.

Jeebizz · 08-13-2023, 09:39 AM

What I am about to request is dumb and extremely low priority but why the hell not? Are we going to get some kind of awesome branding / image used when GRUB2 is official? You know like what Debian does - Or any other distro....

garpu · 08-13-2023, 09:53 AM

So, officially, the tools and such will only support one kernel? I thought suggested practice for Slackware was to always have two: one working, one backup.

LuckyCyborg · 08-13-2023, 09:58 AM

Quote:

Originally Posted by garpu

So, officially, the tools and such will only support one kernel? I thought suggested practice for Slackware was to always have two: one working, one backup.

I for one, I believe that the best backup kernel is the working one.

BUT, there is still no way to do "upgradepkg /path/to/kernel-*.t?z" and the $(uname -r) kernel still to survive on reboot.

The guys and ladies who upgraded to 5.15.118 on a -stable release of Slackware, all of them using AMD graphics probably will agree with me.

marav · 08-13-2023, 10:02 AM

Quote:

Originally Posted by Jeebizz

What I am about to request is dumb and extremely low priority but why the hell not? Are we going to get some kind of awesome branding / image used when GRUB2 is official? You know like what Debian does - Or any other distro....

I don’t remember we do things like any other distro

AFAIK, Pat always provides most of the time, untouched pkg from source. I don’t see any reason for that to change

breeze-grub may be a good start ;-)

LuckyCyborg · 08-13-2023, 10:03 AM

Quote:

Originally Posted by Jeebizz

What I am about to request is dumb and extremely low priority but why the hell not? Are we going to get some kind of awesome branding / image used when GRUB2 is official? You know like what Debian does - Or any other distro....

Well, I can tell you that the GRUB2 has support for this kind of graphics, and on the Internet you can find plenty of tutorials for this.

You can start by looking in /etc/default/grub and the GRUB2 man pages.

marav · 08-13-2023, 10:06 AM

Quote:

Originally Posted by LuckyCyborg

I for one, I believe that the best backup kernel is the working one.

BUT, there is still no way to do "upgradepkg /path/to/kernel-*.t?z" and the $(uname -r) kernel still to survive on reboot.

The guys and ladies who upgraded to 5.15.118 on a -stable release of Slackware, all of them using AMD graphics probably will agree with me.

I sincerely congratulate all those who have a recent AMD and are still with kernel 5.15.x

LuckyCyborg · 08-13-2023, 10:07 AM

Quote:

Originally Posted by marav

I don’t remember we do things like any other distro

Believe it or not, Slackware does a lot of things like any other distro, otherwise it will not be a Linux distribution anymore.

For example, like any other Linux distribution it uses a Linux kernel. But the list is countless.

Quote:

Originally Posted by marav

AFAIK, Pat always provides most of the time, untouched pkg from source. I don’t see any reason for that to change

The official way to configure the GRUB2, as recommended by its developers, is the usage of grub-mkconfig .

And yes, I do not see a reason to change this. After all, I use grub-mkconfig without issues since 2012.

Petri Kaukasoina · 08-13-2023, 10:09 AM

Quote:

Originally Posted by garpu

So, officially, the tools and such will only support one kernel? I thought suggested practice for Slackware was to always have two: one working, one backup.

installpkg and removepkg support multiple kernels. A single initrd.gz can support multiple kernel versions. Remember to blacklist kernel for slackpkg.

Jeebizz · 08-13-2023, 10:10 AM

Quote:

Originally Posted by marav

I don’t remember we do things like any other distro

AFAIK, Pat always provides most of the time, untouched pkg from source. I don’t see any reason for that to change

breeze-grub may be a good start ��

Except if you use the menu in LILO you get a Slackware brand image...

LuckyCyborg · 08-13-2023, 11:21 AM

Quote:

Originally Posted by Petri Kaukasoina

installpkg and removepkg support multiple kernels. A single initrd.gz can support multiple kernel versions. Remember to blacklist kernel for slackpkg.

When the users are forced to download manually the kernel packages and to install manually the kernel packages, the fact that "a single initrd.gz can support multiple kernel versions" becomes rather a matter of Slacker's taste.

I do not see how a mega-initrd will be interesting even on the case when the user do this manually installation of the kernel packages.

Even when it's used an "untouchable" /boot/grub/grub.cfg , the user can just make symlinks to /boot/initrd-latest.gz and /boot/initrd-previous.gz while making initrds with versioned names. Manually.

garpu · 08-13-2023, 11:38 AM

We're talking Slackware, though. The average Slackware user is used to doing at least some things manually. Those who want to live on the edge can still use slackpkg, et al to handle their kernel. Those who wish to automate more can do that, too.

It's like the argument my partner and I have about automation, scripting, etc. I don't trust scripts because I don't trust that the script will get it right. He doesn't trust doing things manually, because he doesn't trust that he'll get it right. (It's a mixed marriage. I like Slackware. he likes Alma/Windows.

)

Petri Kaukasoina · 08-13-2023, 11:49 AM

Yes. There are two orthogonal problems and their solutions.

Use grub instead of (e)lilo as a boot loader.
Automatically install a new kernel, modules, and initrd, possibly leaving working versions of $(uname -r) as a backup.

I think Patrick is now solving problem number one. Of course, it would be nice to also solve problem number two, but it could have been solved a long time ago, or it can be solved in the far future. It's not directly connected to lilo/grub choice.

LuckyCyborg · 08-13-2023, 11:50 AM

Quote:

Originally Posted by chrisretusn

A point regarding mkinird.

If you are going to make an /etc/mkinitrd.conf and use it you must use the -F switch to read it.

This does not use /etc/mkinitrd.conf:

Code:

mkinitrd -c -k 6.1.45 -o /boot/initrd-6.1.45.img

This does (note I left out the "-c" option, it's in the mkinitrd.conf (CLEAR_TREE="1"). I could have left out the -k option also.

Code:

mkinitrd -F -k 6.1.45 -o /boot/initrd-6.1.45.img

This is what I used with my last kernel upgrade. I keep at least two kernels bootable):

Code:

mkinitrd -F -k 6.1.44:6.1.45

It uses this /etc/mkinitrd.conf:

Code:

SOURCE_TREE="/boot/initrd-tree"
CLEAR_TREE="1"
OUTPUT_IMAGE="/boot/initrd.gz"
KEYMAP="us"
MODULE_LIST="jbd2:mbcache:crc32c_intel:crc32c_generic:ext4:drivetemp"
LUKSDEV=""
ROOTDEV="/dev/sda1"
ROOTFS="ext4"
RESUMEDEV=""
RAID=""
LVM=""
UDEV="1"
WAIT="1"

Yes, you are right. For the stock mkinitrd the -F parameter is mandatory.

Seems like ZhaoLin1457 still uses (just like me) a /sbin/mkinitrd to which have applied long time ago this patch bellow (made by me) for Slackware 15.0:

Code:

--- mkinitrd.orig	2022-01-26 22:33:29.000000000 +0200
+++ mkinitrd	2023-08-13 19:38:19.084631792 +0300
@@ -85,10 +85,6 @@
 root filesystem is available.  Other binaries may be added to the
 initrd, and the script is easy to modify.  Be creative.  :-)
 
-  -F      Use the contents of /etc/mkinitrd.conf (optional)
-          If this is used in conjunction with any other options passed
-          on the command line, the command-line options will override
-          the config file options.  See mkinitrd.conf(5) for details.
   -c      Clear the existing initrd tree first
   -f      Filesystem to use for root partition (must be used with -r)
   --help  Display this message
@@ -342,17 +338,10 @@
   fi
 fi # default no-option actions
 
-# Parse for the use config file option first or else the other command
-# line options can not override /etc/mkinitrd.conf. 
-for opt in "$@"; do
-  if [ "$opt" = "-F" ]; then
-      if [ -e /etc/mkinitrd.conf ]; then
-        . /etc/mkinitrd.conf || badconf_file
-      else
-        badconf_file
-      fi
-  fi
-done
+# Include the configuration file.
+if [ -e /etc/mkinitrd.conf ]; then
+  . /etc/mkinitrd.conf || badconf_file
+fi
 
 # Parse options:
 while [ ! -z "$1" ]; do

My rationale for this patch is that a program (or script) should use in a mandatory way its configuration file, not in an optionally way how does the stock /sbin/mkinitrd . Yeah, probably the patch can be improved.

And yes, I played a bit with this script in the past, and me and ZhaoLin1457 shared along our experiences regarding the scripting of the boot(loader) setup.