GRUB2 in Slackware? Discussion and Instruction.

ZhaoLin1457 · 08-12-2023, 11:38 PM

Quote:

Originally Posted by saxa

Hi, would there be a way to have with the transition to grub also keep the old kernel installed and bootable
from the grub in case some dirvers/modules in the new kernel does not work anymore ?

EDIT: I mean keep the previously installed kernel after an upgrade. So basically 2 funcional kernels.

n this forum, a method for this was described by LuckyCyborg.

It is a package for the kernel and its modules, where these files are kept in /boot/incoming and moved to the final position of install/doinst,sh. After that, a CRON script can clean up the old kernels. From what I understand, it's a method inspired from openSUSE.

But yes, I think many would have appreciated this well to exist when in Slackware 15.0 an update was put for the 5.15.118 kernel

LuckyCyborg · 08-13-2023, 12:34 AM

Quote:

Originally Posted by ZhaoLin1457

I can confirm that it literally produces duplicates. One is in the main menu (and it is always with files using a version in their name) and one in the submenu.

Not only that these entries are duplicated, but some are incorrect.

And the cherry on top the cake is that the main entry is incorrect with the /boot/vmlinuz-generic-5.13.4 being matched with nothing when the initrd name is /boot/initrd.gz. The single entry matched correctly is /boot/vmlinuz with /boot/initrd.gz and it's on submenu.

Anyway, I believe that they does not tested beyond of this. Or maybe they think that grub-mkconfig is defect because does not work as they expect with their mega-initrd? Who knows.

Quote:

Originally Posted by ZhaoLin1457

I wonder why RHEL does not use a mega-initrd if it is so advantageous? Or Debian? Or SUSE?

Because probably they have seen that this method is complicated and errors prone?

Anyway, I started to believe that the ultra-secret grubconfig which our BDFL develops almost certainly write directly a /boot/grub/grub.cfg avoiding entirely the GRUB2 scripts.

That's WHY probably our BDFL insists that the file names should not change - because they are hardcoded in that mystery gruubconfig.

LuckyCyborg · 08-13-2023, 12:37 AM

Quote:

Originally Posted by ZhaoLin1457

n this forum, a method for this was described by LuckyCyborg.

It is a package for the kernel and its modules, where these files are kept in /boot/incoming and moved to the final position of install/doinst,sh. After that, a CRON script can clean up the old kernels. From what I understand, it's a method inspired from openSUSE.

But yes, I think many would have appreciated this well to exist when in Slackware 15.0 an update was put for the 5.15.118 kernel

There's another way, and it's even better: to add support on Pkgtools for a noupgrade flag, which in practice would be an empty file install/slack-noupgrade for the packages needed to be marked this way.

Obviously, these packages marked this way will be possible to be only installed or removed, BUT not also upgraded.

BUT, I have no hopes to see something like this in Slackware considering their reticence at any new idea. To be honest, I'm tired.

elcore · 08-13-2023, 02:06 AM

Quote:

Originally Posted by saxa

Hi, would there be a way to have with the transition to grub also keep the old kernel installed and bootable
from the grub in case some dirvers/modules in the new kernel does not work anymore ?

EDIT: I mean keep the previously installed kernel after an upgrade. So basically 2 funcional kernels.

You can make this locally with a directory structure /boot/kernel1/vmlinuz, /boot/kernel2/vmlinuz etc.
So when you install new over the old, /boot/vmlinuz symlink changes but /boot/kernel1/vmlinuz keeps poining to old /boot/vmlinuz-old-version file.

marav · 08-13-2023, 03:08 AM

it's not the symlinks that generate duplicates, but the conf files in /etc/grub.d

chrisretusn · 08-13-2023, 03:09 AM

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"

chrisretusn · 08-13-2023, 03:17 AM

Quote:

Originally Posted by saxa

Hi, would there be a way to have with the transition to grub also keep the old kernel installed and bootable
from the grub in case some dirvers/modules in the new kernel does not work anymore ?

EDIT: I mean keep the previously installed kernel after an upgrade. So basically 2 funcional kernels.

I do this. My method uses symlinks.

Code:

lrwxrwxrwx  1 root root      22 Aug 12 14:49 vmlinuz-generic-stock -> vmlinuz-generic-6.1.45
lrwxrwxrwx  1 root root      22 Aug 12 14:49 vmlinuz-generic-working -> vmlinuz-generic-6.1.44

My lilo.conf contains:

Code:

image=/boot/vmlinuz-generic-stock
  initrd=/boot/initrd.gz
  label=Slackware64
image=/boot/vmlinuz-generic-working
  optional
  initrd=/boot/initrd.gz
  label=LastWorking
image=/boot/vmlinuz-generic-testing
  optional
  initrd=/boot/initrd.gz
  label=Testing

I just point symlinks to the respective kernels. I rarely edit the config file.

I am hoping to be able to do the same with grub.cfg, like @marav shows in this post.

Petri Kaukasoina · 08-13-2023, 03:29 AM

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.

henca · 08-13-2023, 04:31 AM

Quote:

Originally Posted by volkerdi

I like GRUB2 just about as much as you do, but the fact is that at this point it is the only bootloader for Linux that actually works in all circumstances.

Quote:

Originally Posted by mickski56

Whats wrong with limine too new ?

Quote:

Originally Posted by volkerdi

Having every functional bootloader included is not essential for our purpose here.

I have no experience from limine myself, but I do find it interesting as it seems capable to work for all cases that I can come to think of for intel compatible PCs (however at least Pentium Pro is required for 32-bit x86).

https://github.com/limine-bootloader/limine

Yes, limine does not support as many file systems as grub2 does, but that only means that a boot partition will be needed with a supported file system like ext4 or FAT32.

For Slackware, limine would support IA-32 (x86), x86_64 and arm64. It would support both GPT and MBR partitions, it would also support both BIOS and UEFI boots. Of course it would also support iso boot, both on BIOS and UEFI systems.

Like some other boot loaders it also supports PXE boot. How cool would it be with a Slackware installation media asking if you wanted to start a network boot server with NFS, tftp and dhcp servers, allowing other networked machines to PXE boot to installation? Yes, it would be cool, but for most people it is probably not a high priority request.

regards Henrik

elcore · 08-13-2023, 04:46 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.

I've thought about this, and versioned files or versioned symlinks still require editing the boot loader conf file.
Directories do not, as you put both the static path and static filename into static conf file, and then simply exchange the symlinks on update.

Didier Spaier · 08-13-2023, 05:31 AM

Quote:

Originally Posted by marav

it's not the symlinks that generate duplicates, but the conf files in /etc/grub.d

Not an issue if you or some Slackware script write grub.cfg once and for all. This is how I understand what Patrick wrote in post #13, quoted below:

Quote:

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*.

However, this addresses well only one use case: no multi-boot (as I have pointed out in post #21) and only genuine Slackware packages installed, no custom one.

So I would suggest that the choice be given to the user during installation between this method and at least another one: as most if not all other distributions using grub do: run grub-mkconfig (actually update-grub, also backing up the previous grub.cfg) upon every upgrade of a kernel provided by Slackware (in one package also including the modules), do not put symlinks in /boot and associate an initrd to each kernel. The choice made by the user during installation could be recorded in some config file, input of a script doing the kernel upgrade and associated tasks. And users changing their mind would just edit this config file.

Petri Kaukasoina · 08-13-2023, 05:34 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.

Quote:

Originally Posted by elcore

I've thought about this, and versioned files or versioned symlinks still require editing the boot loader conf file.
Directories do not, as you put both the static path and static filename into static conf file, and then simply exchange the symlinks on update.

I don't see the difference. Why isn't it enough to make the symlinks in /boot ?

Code:

/boot/initrd.gz
/boot/vmlinuz -> vmlinuz-generic-5.15.117
/boot/vmlinuz.backup -> vmlinuz-generic-5.15.94
/boot/vmlinuz-generic-5.15.117
/boot/vmlinuz-generic-5.15.94

Lilo, elilo, or grub refer to static names vmlinuz & initrd.gz, or, for the backup kernel, to vmlinuz.backup & initrd.gz. Lilo needed to be run, elilo wanted vmlinuz, vmlinuz.backup, and initrd.gz be copied to /boot/efi/EFI/Slackware. For grub no need to do anything.

Quote:

Originally Posted by Didier Spaier

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:
...

This is why I mentioned that you can add versioned symlinks, if you want to use grub of another OS. Like this:

Code:

/boot/initrd.gz
/boot/initramfs-5.15.117.img -> initrd.gz
/boot/initramfs-5.15.94.img -> initrd.gz
/boot/vmlinuz -> vmlinuz-5.15.117
/boot/vmlinuz.backup -> vmlinuz-5.15.94
/boot/vmlinuz-5.15.117
/boot/vmlinuz-5.15.94

marav · 08-13-2023, 05:36 AM

Richard Cranium made a Slackware specific config file for grub2
https://github.com/Richard-Cranium/S...lackware_linux

Based on that, it's easy to tune it to individual needs

elcore · 08-13-2023, 05:52 AM

Quote:

Originally Posted by Petri Kaukasoina

I don't see the difference. Why isn't it enough to make the symlinks in /boot ?

Some context: I have 4 systems using same /boot and have seen folks using 10 or more.

It's not enough only if you want every one of those 4 kernels called vmlinuz which is what Slackware kernel package is doing.
There can be only one /boot/vmlinuz, and if you define /boot/vmlinuz in grub.cfg and replace the symlink on update then the other system menuentry fails.
But if you define the path, then both the old kernel and the other system kernel symlink still works, without any need to "update grub.cfg" on kernel upgrade.

Note that I'm not requesting anything, just sharing what I've already solved long time ago.

bigbadaboum · 08-13-2023, 06:22 AM

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