First of all thanks for taking the time and replying.

The situation with Grub 2.14 and Your setup is quite unfortunate. I filled those shoes more times than i would like to admit (a watershed point with perfectly functional setup suddenly rendered obsolete by a seemingly whim or quirk of the developer).

My experience tought me following (would i be shown wrong i will update my stance to best of my knowledge then):

1. I, personally, can afford to keep my setup at the "least effort but functional level" for indefinite amount of time - it is my call and i bear the weight of that decision alone (more or less).
2. Would that setup be some customer's or otherwise non personal project - i'd have to call the shot when i will transition to a future proof solution - note not "if" but "when": on next update, upgrade or full overhaul. It is what it is.
3. Now that we are done with "the right way" solutions, "the right thing" would be to make a USB stick that would contain the needed grub elements (core.img and /boot/ partition) so the raid array is not disturbed for the foreseeable time - buying ample time to address it in the future at a more advantageous time and circumstances.

This in no way implies You haven't considered the listed solutions, should consider them or they apply for your particular setup - I would have to know more of the intricacies to be able to determine that . I merely try to point out it can be a complex array of mutually exclusive parameters one has to confront and navigate to find the most opportune solution.

Other than that, I'm curious is it a hardware RAID or a software RAID?

Also, back to the topic and question:
Would You find your particular setup "a role model" or a "painted in the corner" case, going forward?

Again, I hereby apologize if sounding brush or rude as English is not my native language.

1 members found this post helpful.

A couple quotes from the grub manual:

And a little later:

Which would mean something like 2000 x 512 byte sectors or more is recommended before the first partition. It's unfortunate that this 2.14 version's core image now rubs up against that 63 sector gap in that raid array. Not sure what else you can do to trim the image.

RE elilo: It works perfectly on some machines, and then not on others, and isn't getting fixed for that AFAIK. Probably not worth keeping that headache around for the long term.

Also when you switch to using grub with EFI, copying kernels to the efi partition is no longer needed like with elilo, so its less likely to have users upgrade a kernel to a non-booting system because they forgot that part with elilo. With the direction that kernel upgrades and the new automated initrd generation is going in -current, it makes upgrading kernels a little less tricky when combined with grub.

2 members found this post helpful.

Do you think our Glorious Leader is the first to encounter this problem with GRUB in a layout starting from sector 63?

There are millions of posts and pages on the internet explaining what to do in this case and the best practices. If our Glorious Leader were to post this problem in the Fedora forums, he would probably get this recommendation:

Convert each hard disk to GPT disklabel using "gdisk" and add a "BIOS boot" partition to each one at the end, with a size of at least 1MB. Then install GRUB2 as usual. And, yes! He has over 100MB free at the end of the drive, so it's not the end of the world.

With all due respect and not intending to lecture our Glorious Leader: we are in 2026, there is no reason to use a layout starting from sector 63 today, in fact it is really a very bad idea. And there is no reason to use an MSDOS disklabel today, because the oldest supported by Slackware-current are Intel socket 478 and AMD socket 754. We have shown the middle finger even to the Intel Pentium III and the glorious AMD AthlonXP, along with its cousin Barton. So, all supported computers works with GPT disklabels today.

Should I add that the partitioning tools in Slackware use sector 2048 as the starting point even in Slackware 14.2?

With all due respect, I ask our Glorious Leader not to complicate himself and complicate our lives anymore. Let MSDOS disklabels and layouts that start with sector 63 die. Along with LILO and ELILO.

Anyway, I think it is not a good idea to recommend practices that lead to doom when a binary is changing size from 29KB to 32KB. It's about 3KB size difference, folks! This is insane! It is like petting wild tigers. What can go wrong?

2 members found this post helpful.

If Patrick decides to do that... those of us who choose to continue using them have but to blacklist lilo/elilo
so that 'slackpkg clean-system' will not remove them from our systems.

1 members found this post helpful.

Since the problem with lilo/elilo really only lies with newer systems, I see no problem keeping it as a legacy support option. Going forward though I suspect the default should be grub to avoid having to deal with new users complaining about a failed installation.

For those people who want to push for faster development, I think it's worth reminding people that some industries have good reason for sitting on older hardware/software. Mission critical systems where failure results in loss of human life typically involve well tested tech and one does not simply upgrade those to newer versions of the same software. Any change, no matter how minor, is required to go through a qualification process that can often take years to fully complete. Failure to qualify these systems inevitably leads to problems like the Therac-25.

The average lifespan of a commercial helicopter in the USA is greater than 40 years. So yes, there are computer systems actively making a difference in everyone's daily lives that run computers older than myself. This might be a bit over dramatic but I don't think it's a stretch to say that if everyone abandoned old software then aircraft would literally start falling out of the sky.

Food for thought before you abandon old bootloaders... qualify the new grub first, then deprecate.

9 members found this post helpful.

Not going to argue it's 2026 nor that LILO hasn't run it's course.

But...

Would You be too surprised that one of the Slackware niches was exactly that - old computers that couldn't be used with any other up-to-date distro because of cutting short the supported architectures?

It was it's strength (backward compatibility) once praised to high heavens.

It (Slackware) was the distro showcasing how one can build a modern Linux and still yet maintain that old chunky PC from decades ago - running lean and mean.

It was the proof that mandated obsolescence of printers and burro machines pushed by some heavy state-subsidized companies was nothing but a petty practice.

It still is the good old Slackware we came to love and respect, it's just the uphill battle somehow never seems to yield or ease?

11 members found this post helpful.

I partitioned those drives in 2011. Also, take your "Glorious Leader" and shove it where the sun doesn't shine.

24 members found this post helpful.

Attempting a rebuild against this revealed 28 FTBFS, mostly GNU things (as warned in the NEWS). It'll all get handled, but it may be a little while.

2 members found this post helpful.

Gimp-3.0.8 is just released.

From the site:

GIMP 3.0.8 Released
2026-01-24 by GIMP Team

Thought you'd want to know.

1 members found this post helpful.

That's a very solid take. I think the old bootloaders are still valid on older systems, hence there's no need to remove them just yet. And in the case of something like ELILO where keeping it isn't necessarily imperative for compatibility, it's a small enough package that keeping it around purely as an option for a user so inclined to choose it isn't the end of the world as far as maintenance is concerned.

Once again, solid take, and once again, showing that these older bootloaders can still be valid for certain use-cases, or if nothing else solely as an option for the adventurous user.

Neat that the drives have lasted so long - do they see any large amount of activity? Also, I audibly chuckled at the second half of your post.

The problem is more about keeping backward compatibility for it in all kernel-related scripts (initrd and kernel file names, etc.)

2 members found this post helpful.

GRUB loads its configuration not only from /etc/default/grub but also /etc/default/grub.d/*.cfg (see /usr/sbin/grub-mkconfig):

so it's possible to apply local changes without touching /etc/default/grub and simply overwrite it with grub.new on updates. Unfortunately the new doinst.sh from grub-2.14-x86_64-2 only checks /etc/default/grub:

It would be nice to have a consistent behavior so that GRUB_INSTALL_SCRIPT can also be changed in a /etc/default/grub.d/*.cfg file.

3 members found this post helpful.

https://linuxiac.com/kde-plasma-logi...r-bsd-systems/

Watershed moment:
Will we go forward requesting inclusion of systemd or drop that future "KDE Plasma login manager" as it will be apparently unusable for "systemd-free" sytems including BSDs and our beloved Slackware?

Is there still a third way?

Use a different login manager. The only reason I would have requested KDE to just be removed is the very slow adoption of KDE 6.x in --current.

Yes, don't use a login manager.

4 members found this post helpful.