Just wanted to point out that the slackware images on Linode(akamai?) appear to be using GRUB. It seems to work perfectly fine. The only issue I encounter with it is when trying to remember how to update. Whenever I think try to remember the GRUB commands my brain goes into *buntu mode and I instinctively type "update-grub" which obviously doesn't do anything here...

If we do switch to GRUB, it would be nice to add an /sbin/update-grub script that calls the appropriate commands to write grub.cfg to whatever standard file location Pat decides is best.

4 members found this post helpful.

The update-grub on Ubuntu and derivatives is just one line which runs grub-mkconfig which you can see below. If you look at the file on your Ubuntu, you will see that. You could just create a link to run it if you are more familiar with that.

3 members found this post helpful.

Just my opinion, not a fan of this, not really needed. What Pat decides, I am good with. It's not like I really have any choice.

Well he pretty much implicitly confirmed when I made a request about having a choice of both LILO/ELILO and GRUB in the installer that it will be only GRUB - because well LILO/ELILO has pretty much stopped being maintained from what it seems anyhow. So it is now not if, but when Pat pulls the trigger and makes GRUB the new bootloader.

I was referring to /usr/bin/update-grub, a wrapper that runs 'grub-mkconfig -o /etc/boot/grub.cfg'; it is not necessary. If Pat decides to add an upgrade-grub to the package, so-be-it. I will still do it my way and use 'grub-mkconfig -o /etc/boot/grub.cfg' as I do now.

As for lilo/elilo? Yes I read Pat's comment on this the same as you did; lilo/elilo are gone in the next version of Slackware. I was a die hard lilo user. It's the reason I decided to learn grub. Better now than when the shoe drops. I'm good with lilo now, figure it out enough to make it work the way I like. I do wish the scripts in /etc/grub.d/ were better documented, maybe in this upcoming version. I only played with elilo in a VirtualBox EFI machine, it was not very dependable; grub on the other hand is. I am 100% on grub now. So even if lilo/elilo don't make it to pasture I fine with that.

Whichever boot loader becomes the default doesn’t matter to me either—especially as long as I get the choice to deploy it or not. Ever since I learned how to build a boot loader from source and deploy it (i.e., since the days of the Red Hat 9 desktop and GRUB 0.97), I’ve been installing my boot loader independently of any operating system; I can, thus, remove or change or add operating systems as I see fit without ever destroying the boot loader.

Whenever I set up a computer from scratch, I first set up the boot loader and make sure that it works; only then do I install the (only or first) operating system. One of the great little details about the Slackware installer is, that it won’t force me to deploy a boot loader. I have just installed the Devuan desktop, and that, on the other hand, insists on installing GRUB even if there’s already a boot loader present. Under UEFI, that’s OK by default—an entry gets added to the EFI boot menu, and some stuff gets copied to the ESP (“EFI System Partition”); I won’t even notice it unless I go looking for it, and I can remove it all if I wish. Under legacy BIOS, however, the existing boot loader will get overwritten unless I take care to change the location to which Devuan will install its own GRUB copy.

I currently use Limine as my boot loader, but even if I return to GRUB, I’ll continue to handle it myself, independently of any operating system.

Just out of curiosity, how do you install a bootloader (I assume you build it elsewhere) and test it without a running OS?

To build the boot loader, I obviously need a host computer that runs a suitable operating system; until recently, I built the boot loader under Ubuntu 20.04 on my desktop computer, but nowadays I use Slackware 15.0 as the host OS. I perform the build on a separate ext4 partition (labelled “CustomBootLoader”) and keep a copy of its contents on a USB stick.
These days, all my system disks will be partitioned with a GPT, and they will be hybrid BIOS/UEFI bootable.

When I get to install a computer from scratch, I will, obviously, have to boot it from some medium like a DVD or a USB stick (generally, “SystemRescue” is an interesting option); I usually either wipe the partition table clean with the ‘dd’ command—e.g.:
(or some such), or with the “o” option (“create a new empty GUID partition table (GPT)”) of the ‘gdisk’ command.

I then create three partitions on the system disk:

1. BIOS Boot partition—just 960 KiB, sectors 128 through 2047 (this is the first MiB of the disk, minus 64 KiB at the start to leave ample room for the GPT).
   The first stage of the Legacy BIOS boot loader will get dumped here when it is deployed; when the computer boots in UEFI mode, this partition will remain unused.
2. ESP (“EFI System Partition”), a few hundred MiBs, depending on the available disk space. While this is a requirement for UEFI mode only, it is a handy location for some files that the boot loader needs in Legacy BIOS mode as well—e.g., in the case of Limine, the ‘limine.cfg’ configuration file (shared by the Legacy BIOS and UEFI modes) and the ‘limine-bios.sys’ module (for Legacy BIOS only).
3. An ext4 partition labelled—you guessed it—“CustomBootLoader”, onto which I copy the contents of the USB stick.

Next, I deploy the boot loader according to its instructions; in the case of Limine, this means:

• Copy ‘BOOTX64.EFI’ to the ‘/EFI/BOOT’ directory (which must, obviously, first be created) of the ESP; this will provide UEFI boot support.
• Copy ‘limine-bios.sys’ to the root directory of the ESP, for Legacy BIOS boot support.
• Copy a dummy ‘limine.cfg’ configuration file to the root directory of the ESP, just so Limine will have at least something to do when it boots.
• Run ‘limine bios-install’ to deploy the Legacy BIOS boot loader to the first partition (i.e., the BIOS Boot Partition) of the system disk.

Finally, I attempt to boot the computer from its system disk. Unless I somehow messed up, the boot loader should successfully process its configuration file and display its (fairly useless, at this point) menu.

2 members found this post helpful.

Well, it's not really so nice.. Anyhow, there is something similar for Slackware currently, for Lilo, so to say, which is the bootloader setup.. If Slackware drops Lilo and goes with Grub, I'm pretty sure the Lilo bootloader setup will be removed, and maybe even be replaced with something similar for Grub. Several of these little bits of the installer have their separate invocation outside the installer, like netconfig.