This update-grub2 script is not for your but for regular Slackware users which would like to go with defaults, and probably it will stay in /sbin . You will not be affected by its presence, excluding maybe several (hundred) bytes of storage consumed, unless you activate the GRUB2 bootloader.

This update-grub2 script is supposed to be called by the Slackware packages for kernels, in their doinst.sh and IF by configuration is disabled, will do NOTHING. And it makes sense only when GRUB2 bootloader installed, then an additional check could be done.

I did not asked you to wrap your mkconfig and your custom scripts!

Among those abandoned boot loaders I still prefere LILO for MBR boot and if UEFI is needed I prefer syslinux/extlinux.
For installation media on CD/DVD I use syslinux for legacy boot and grub for UEFI boot, unfortunately syslinux does not support UEFI boot with CD/DVD. The major reason for me prefering LILO and syslinux is that they have rather simple configuration files, syslinux is also usable for other purposes like network boot.

With a more or less custom huge kernel there is no need to mess with any initrd.

Maybe it would work with grub, but I have made my own kernel update packages which are installed to many machines. The installation script of those packages does:

1) Moves the old kernel files to /boot/old_kernels/${kernel}.`date +%y%m%d`
2) Copies the new kernel files to a subdirectory of /boot like /boot/huge.s
3) gunzip boot/${kernel}/System.map.gz
4) If /boot/efi/EFI/Boot directory exist, copy bzImage to boot/efi/EFI/Boot/vmlinuz
5) Runs lilo if /boot/extlinux.conf is missing

This installation script allows automatic kernel updates on many different machines using different kernel configurations and different boot methods (lilo or extlinux).

regards Henrik

The ELILO is already broken, the LILO can stay well in SBo and from what I know, the SYSLINUX shipped by Slackware has no UEFI support. So, you use a custom SYSLINUX package, right?

Then, what stops you to continue to use your custom bootloaders?

Permit me to differ. Everybody uses initrds (generated on-fly) and generic kernels. And nobody other than Slackware asks the users to manualy update their bootloaders. True, everybody uses GRUB2 and nothing else. No LILO, no ELILO, no SYSLINUX, nothing else.

In other hand, I for one I use UUIDs for defining the partitions, which is the safest way to ensure that no matter where you mount that particular hard drive, the partitions would find with accuracy.

So, I believe that initrds is a must have and huge kernels should go Dodo bird way. Anyway, I never used them other than in the Slackware installer and I truly do not understand for what they are good for. Even the Slackware installer can work well with a generic kernel, considering that it have a huge initrd.

BUT, please note that I talk only about the Slackware kernels - be my guest to build yourself Kernelzillas as huge as you like.

Exactly for GRUB2 is supposed to work. For everything else and your custom kernels installations, this feature can be easily disabled in a consistent way.

No, I do not ask you to change your workflow, but to be kind to permit to majority of Slackware users to have a consistent boot setup without to be required to be rocket scientists.

They can have a seamless kernels upgrade without your custom workflows to be affected. I explained already how.

Then what stops you to continue to go the "manual" way?

The /boot/grub/grub.cfg is a text file and you can write it well also by hand, provided that you already disabled its auto-update when a new kernel is installed, IF my idea of update-grub2 script is implemented.

Please note that right now nothing auto-updates this GRUB2 config file.

who the hell you think you are to decide where the packages should go?
are you retarded? you still dont learn that this this distro is not Ubuntu or Fedora or OpenSUSE? if you like that why dont you use that and leave this forum with all your shit alone? i dont use grub2, i use rEFInd, why dont you stop your bullshit and leave the guys that manage the distro do their work in peace?
this is clearly not a distro for you is not that hard to understand.

1 members found this post helpful.

I want to be able to generate initrd manually, this is the only operation I do when updating the kernel.
Let's see if GRUB2 will become the standard in Slackware and after that we'll see how we manage with it.

On that I agree with you. I'd also argue that there's no point having a separate kernel-modules package and that a single kernel+modules package would be more reliable (removing the possibility of a kernel/modules mismatch). That's been my opinion for years. Anyway, this has been suggested multiple times over the years and never goes anywhere, so don't hold your breath.


My problem with grub2 is that it will require a /boot partition and I don't currently have any space to make one, so it's going to mean a full repartition and reinstall when/if I have to switch. In contrast ELILO is completely self-contained within its subdirectory of the EFI partition, is simple to configure, and has thus far caused me absolutely no issues at all. Switching to grub2 is simply not worth the inconvenience here. These issues with Pat's 5.19 packages are certainly concerning, but do we really know that ELILO is at fault at this point?

Like elcore the contents of my ELILO.CONF is completely read-only and never changes. I have a post-install script that will be automatically invoked by my 'slackup' tool whenever it sees the kernel-modules package is updated/installed and which will update vmlinuz and initrd files in the EFI partition for me. This gives me the automatic self-managing behaviour you crave. It's trivial system administration stuff and I'm sure many others have come up with their own automated solutions for this.

No. None of my systems have a separate /boot partition and I have no issue booting them with grub2. This includes for some of them an encrypted root partition that grub2 kindly unlocks to find the kernel and initrd in /boot (a directory in the root partition, not a separate partition).

4 members found this post helpful.

This forum has written rules that says that personal insults are not accepted. I think this post of yours will not be appreciated by moderators.

And please stop with this Vendetta against LuckyCyborg, it makes no sense! All your posts in the last time are insults at LuckyCyborg's address. You have nothing else to say, in a civil manner?

Anyway, this is a requests thread, and anybody has the freedom to propose anything they want. Who are you to censure what is proposed here?

9 members found this post helpful.

My understanding was that grub2 needs to load its modules from /boot/grub to support lvm and luks, but perhaps I'm mistaken on that one. I currently have lvm on LUKS2. I know grub2 has/had issues with LUKS2 support initially, don't know whether that is still true.

Nope. The GRUB2's grub-install uses this /boot/grub directory as a temporary place to build a core.img and/or core.efi, which are both composite binaries and the real installed stage2.

True, for the hard drives with GPT partition labels, GRUB2 needs for MBR/BIOS mode, a small BIOS boot type partition. BUT, this one could be at small as 1MB.

Yesterday, I had 2 failures with the kernel 5.19.0 and ELILO. Because I have the habit to keep the drives bootable also as BIOS/CSM legacy, even I use UEFI, I added this partition by simply removing the UEFI ESP of 500MB and creating two partitions: 5MB for BIOS boot and 495MB for ESP. That's all.

BTW, in the ESP, the grub-install installed only a single EFI binary, where is hardcoded the UUID of partition where it have to look for its grub.cfg.

2 members found this post helpful.

no issue with LVM as far as I know, LUKS2 is supported since 2.06 with the exception of Argon2i as stated in this commit. I still use LUKS1, but no LVM as instead I use a btrfs file system with / and /home as subvolumes so no need to worry about the space allocated to / and /home respectively as they use the same pool as illustrated below. And GRUB handles this setup out of the box:PS And a btrfs file system can handle several devices so I don't think I will need LVM for anything, but I digress.

2 members found this post helpful.

In recent versions for complex layouts, more (I use 3M to be safe). Before that you could just use the gap between the the end of the partition table and the beginning of the first partition.

1 members found this post helpful.

I just had a peruse of the Arch wiki on the subject and yes, it looks like you are right, you have to tell grub to preload the modules in its conf file before you do a grub-install, I'd assumed it read them from /boot/grub at runtime, apparently not.

Anyway, I also noticed from that page that you have to start messing with custom core images to get non-US keyboard maps included, that puts me off a little as the whole thing is getting overly involved.

Until I hit a problem, I'm just going to stick with ELILO, but thankyou for your input.

1 members found this post helpful.

I know people are trying to help with grub2, and that might well be the answer, but pushing it *now* isn't really doing anything to fix the problem of the default configuration (elilo) being broken for some. That some have it working with elilo and 5.19 means that it could be a config issue, a bug in the kernel, or a bug in elilo. Just switching to grub isn't going to help nail down what that is.

7 members found this post helpful.