Requests for current-next (15.0-->15.1)

Petri Kaukasoina · 07-09-2026, 04:53 AM

Quote:

Originally Posted by Lockywolf

the initrd is capable of booting with a static busybox.

Likewise with a dynamically linked busybox.

These dynamically linked executables are in an initrd of current in addition to busybox:

Code:

./lib/udev/hid2hci
./lib/udev/dmi_memory_id
./lib/udev/mtp-probe
./lib/udev/mtd_probe
./lib/udev/libinput-fuzz-to-zero
./lib/udev/libinput-fuzz-extract
./lib/udev/cdrom_id
./lib/udev/ata_id
./lib/udev/scsi_id
./lib/udev/fido_id
./lib/udev/pcmcia-socket-startup
./lib/udev/libinput-device-group
./lib/udev/pcmcia-check-broken-cis
./lib/udev/v4l_id
./lib/udev/collect
./sbin/dmsetup
./sbin/udevd
./sbin/mdadm
./sbin/mdmon
./sbin/lvm
./sbin/kmod
./sbin/udevadm

They are simply copied from the root file system. No need to rebuild them statically because all the needed libraries are also copied.

Lockywolf · 07-09-2026, 04:57 AM

Quote:

Originally Posted by Petri Kaukasoina

These dynamically linked executables are in an initrd of current in addition to busybox:

Code:

./lib/udev/hid2hci
./lib/udev/dmi_memory_id
./lib/udev/mtp-probe
./lib/udev/mtd_probe
./lib/udev/libinput-fuzz-to-zero
./lib/udev/libinput-fuzz-extract
./lib/udev/cdrom_id
./lib/udev/ata_id
./lib/udev/scsi_id
./lib/udev/fido_id
./lib/udev/pcmcia-socket-startup
./lib/udev/libinput-device-group
./lib/udev/pcmcia-check-broken-cis
./lib/udev/v4l_id
./lib/udev/collect
./sbin/dmsetup
./sbin/udevd
./sbin/mdadm
./sbin/mdmon
./sbin/lvm
./sbin/kmod
./sbin/udevadm

They are simply copied from the root file system. No need to rebuild them statically because all the needed libraries are also copied.

Okay, but busybox is _not_ copied from the root filesystem. I don't see why it should be dynamic in this case.

Quote:

Likewise with a dynamically linked busybox.

No, not in all cases, as already shown.

Look, it is ridiculous that a kernel might be able to boot _without an initrd entirely_, but would fail to boot _with_ an initrd, just because some libraries, which are not used for anything in the boot process are confused.
Critical boot components should be more resilient than that.

UrbanDesimator · 07-09-2026, 06:33 PM

Quote:

Originally Posted by Jeebizz

For 15.1 would it be feasible, and not too complicated to have the installer give you the choice to install LILO or GRUB , or ELILO or GRUB (in UEFI mode) ?

As long as your not made to choose one, as currently you can say no to both. So you can drop down to shell and setup stub boot either with a loader or direct boot of kernel. I run a script that gets the UUID of root partition to add to efibootmgr's config line to enable biios/direct kernel boot. The line is help is bios by your backup/battery, unless you don't realise it's nearly flat and has forgotten your bot line when powered back on.

folks with eufi firmw2are will often choose stub-boost "No boot loader". booting the kernel straight from the eufi bios as it so much more reliable as you don't have the bootloader causing issues with the firmware.

Roderick W. Smith has a page some were on his site were he goes into it how they try to take ownership to early.

Jeebizz · 07-09-2026, 10:23 PM

Quote:

Originally Posted by UrbanDesimator

As long as your not made to choose one, as currently you can say no to both. So you can drop down to shell and setup stub boot either with a loader or direct boot of kernel. I run a script that gets the UUID of root partition to add to efibootmgr's config line to enable biios/direct kernel boot. The line is help is bios by your backup/battery, unless you don't realise it's nearly flat and has forgotten your bot line when powered back on.

folks with eufi firmw2are will often choose stub-boost "No boot loader". booting the kernel straight from the eufi bios as it so much more reliable as you don't have the bootloader causing issues with the firmware.

Roderick W. Smith has a page some were on his site were he goes into it how they try to take ownership to early.

This was addressed by Pat - he implied that it will just be GRUB , ELILO is no longer maintained and LILO I think is in the same boat.

Lockywolf · 07-09-2026, 10:31 PM

I would grab this opportunity to suggest giving up on grub entirely and switching to refind.

It's maintained, it has a single configuration file, it can do auto detection, but only if asked, it boots windows and macos natively and other oses via chainloading. It loads its fs drivers right from the efi partition, so no need to fiddle with building them into the bootloader image and play with grub notation (hd0,1)

I set my default entry to boot /boot/vmlinuz + /boot/initrd.gz, so it always boots the latest installed kernel. I prefer writing out menu entries for each kernel manually, but refind can also autodetect installed kernels.

I do not clean up /boot/initrd-tree, so the initrd.gz has modules for all of the kernels, works with any of them. If that bothers anyone, a single line in kernel's douninst.sh would clean up /boot/initrd-tree/lib/modules/$version.

ZhaoLin1457 · 07-10-2026, 12:36 AM

Quote:

Originally Posted by Lockywolf

I would grab this opportunity to suggest giving up on grub entirely and switching to refind.

Yes, but GRUB2 is also capable of being used in legacy BIOS mode, and is capable of running 32bit kernels even from UEFI mode, has easy integration with automatic configuration updates from kernel packages without accessing a FAT32 partition, automatically recognizes and configures multiple kernels in the menu and above all, has a very powerful scripting part.

But of course, all of this is very well known since the entire Slackware Nation argued and insulted LuckyCyborg for 2 years for daring to ask for an automation of initrd generation and update of the bootloader configuration.

I thought this problem was solved years ago and all other bootloaders will end up in /pasture . However, it seems that we still need to run around our tails for some years. And we wonder why a release cycle lasts 7 years.

Lockywolf · 07-10-2026, 02:20 AM

Quote:

Originally Posted by ZhaoLin1457

Yes, but GRUB2 is also capable of being used in legacy BIOS mode, and is capable of running 32bit kernels even from UEFI mode, has easy integration with automatic configuration updates from kernel packages without accessing a FAT32 partition, automatically recognizes and configures multiple kernels in the menu and above all,

refind can do all of that too, and even better, you don't _need_ "automatic configuration updates from kernel packages_, because refind works WITHOUT configuration updates AT ALL.

Quote:

has a very powerful scripting part.

Right, refind cannot do that, just like elilo and lilo cannot. And somehow we managed to deal without this ability for years. For those who actually need complex scripting, grub can always be in /extra . In any case, what do you intend to actually _use_ this powerful scripting for? The "cutting-edge" distros, which advocate for wayland, rust, systemd, and such use it for?.. nothing? Or even consider switching to systemd-boot, which is more of a stub than a bootloader? Or even boot the kernel with a compiled-in efistub?

Quote:

But of course, all of this is very well known since the entire Slackware Nation argued and insulted LuckyCyborg for 2 years for daring to ask for an automation of initrd generation and update of the bootloader configuration.

The "nation" disagreed with this idea, because this idea is a mistake. Initrd is a superflous tool which is not needed in most cases, is fragile, is an extra moving part which is unneeded for most users, and those who need it, usually do not rely on pre-installed scripts to generate it, because they have their own quirks. Adding automatic initrd generation to the kernel install packages is a mistake, which, hopefully, does not hurt too much. Rewriting bootloader configuration each time a kernel is installed/reinstalled/updated is just purely insane.

Nobody insulted him intentionally, people here are mostly civilized and criticize ideas, not people. This is how development works.

Quote:

And we wonder why a release cycle lasts 7 years.

Nobody wonders. It is 7 years, because one year is spent taming GRUB, and another year rebuilding all the 700 KDE packages, which are once again all rewritten from scratch, and incompatible with the previous version of themselves, and a third one is dedicated to trying to make pipewire do the same thing that aRts did since about 2006. Drop these guys, and development is going to go twice faster. But I digress, this was not the point of the question.

ZhaoLin1457 · 07-10-2026, 02:47 AM

Quote:

Originally Posted by Lockywolf

Nobody wonders. It is 7 years, because one year is spent taming GRUB, and another year rebuilding all the 700 KDE packages, which are once again all rewritten from scratch, and incompatible with the previous version of themselves, and a third one is dedicated to trying to make pipewire do the same thing that aRts did since about 2006. Drop these guys, and development is going to go twice faster.

Both GRUB2 integration and Plasma6 were served on a platter by LuckyCyborg. This is not a realistic argument.

And PipeWire could have been as well adopted 4 years ago as the default audio/video server, soon after Slackware 15.0 release. It is used exactly in the same way by Plasma5 so it was possible to tune its management just as well while using Plasma5, by Slackware users like Mr. Petri and Mr. Rizitis.

BTW, Mr. Petri uses Slackware 15.0 so the script invented by him is made in -stable and tested with the PipeWire package from /testing .

Quote:

Originally Posted by Lockywolf

But I digress, this was not the point of the question.

And I don't want to argue with you in this thread. I just said my opinion, that I thought the issue was settled years ago.

But a new warrior has risen and wants to start over. Have fun.

It's perfectly OK for me if we'll have a release in 2047 and if it will be an Rube Goldberg machine.

teoberi · 07-10-2026, 04:43 AM

Quote:

Originally Posted by teoberi

And a new step forward for fixing the problem at the Postfix level and without reverting for lmdb.

https://www.mail-archive.com/postfix...msg108095.html

This seemed like the OK way to go, reverting to the old version of lmdb is just a temporary solution I think.
I always choose the new packages even if problems still occur, that's their role to move forward!

Let's see what Wietse Venema/Viktor Dukhovni think.

PS:
We'll have to wait a little longer!
https://www.mail-archive.com/postfix...msg108100.html

Until then:
1. revert to Berkeley DB (hash and btree)

2. whoever wants to try the second proposed patch (also accepted by BDFL)

https://www.mail-archive.com/postfix...msg108095.html
3. use cdb/tinycdb (tinycdb has slackbuilds but is read-only database format)

4. sit and wait with cracked mail servers (who can afford it)

A new approach that goes straight to the source of the problem, i.e. lmdb!
https://www.mail-archive.com/postfix.../msg01336.html
Solution verified by Wietse

https://www.mail-archive.com/postfix.../msg01339.html

We could have lmdb built with the maintainer's patch if we now have certainty that it works.

jtsn · 07-10-2026, 05:17 AM

Quote:

Originally Posted by Lockywolf

I would grab this opportunity to suggest giving up on grub entirely and switching to refind.

It's maintained, it has a single configuration file, it can do auto detection, but only if asked, it boots windows and macos natively and other oses via chainloading. It loads its fs drivers right from the efi partition, so no need to fiddle with building them into the bootloader image and play with grub notation (hd0,1)

I second that recommandation. Even without file system drivers, after removing elilo.efi, it just detects Slackware sitting in its EFI subdirectory and boots right into it with the proper EFI kernel boot protocol (unlike ELILO, which tries to emulate 16 bit LILO and breaks). And it allows editing the kernel command line. So it's a complete drop-in replacement for ELILO.

When it's able to read the boot partition (with file system drivers loaded), it also detects all kernels and initrds and allows selecting them. No config sync needed.

ZhaoLin1457 · 07-10-2026, 05:23 AM

Quote:

Originally Posted by jtsn

I second that recommandation.

Considering what you recommend for Slackware, it's probably best to avoid it like fire.

I don't fondly remember your SIMPLEDRM stunt, and to be honest, I suspect it's because of you that the initrd is rebuilt twice when I update the kernel packages and just because I have a USB WiFi driver registered in DKMS, as I have for years.

marav · 07-10-2026, 06:55 AM

If Mr. Volkerding had intended to switch to rEFInd, he would have done so a long time ago...

garpu · 07-10-2026, 08:49 AM

Quote:

Originally Posted by marav

If Mr. Volkerding had intended to switch to rEFInd, he would have done so a long time ago...

+1. Grub's in a really nice place now.

jtsn · 07-10-2026, 10:24 AM

Quote:

Originally Posted by marav

If Mr. Volkerding had intended to switch to rEFInd, he would have done so a long time ago...

It's not about dropping GRUB (which is probably facing the same upstream development fate as its predecessors). rEFInd is just a drop-in replacement for ELILO (which GRUB isn't) as it figures out booting the kernel from the EFI partition very well without manual intervention, even with a neat Slackware logo built-in.

Having rEFInd already installed on my new machine spared me hours of troubleshooting, as it turned out as the only software that got Slackware actually booting on my new machine. Neither the unpatched ELILO installed by Slackware nor Slackware's GRUB defaults (mostly related to its video mode setup) lead to an actual bootable Slackware install. Slackware's UEFI boot path is rough terrain.

Meanwhile I have patched (and then retired) ELILO and forced GRUB into submission with a large trout, but rEFInd (unmodified binaries distributed by upstream) got it running out of the box, without it I couldn't even get started on the work.

It's also a way better boot selector than GRUB which still cannot get into remembering the last selection.

Petri Kaukasoina · 07-10-2026, 10:32 AM

Quote:

Originally Posted by jtsn

Having rEFInd already installed on my new machine spared me hours of troubleshooting, as it turned out as the only software that got Slackware actually booting on my new machine.

As this is "Requests for current-next", please elaborate. Was it really -current that you tried to boot?