upstream: containing only the code relevant to systemd-boot.
patches: containing the patches to turn upstream into "egummyboot".
gummy: the code to be put into release tarballs.

But I think, it looks like a trolling from Was2023.

IMHO he tries to promote Russian Alt Linux, which is IMHO not good for DevOps because not popular like Debian.

If I understood correctly, I was told on another forums, that Debian kernel in the future may lack support for non UEFI mode of booting?

@Bimon can you elaborate on this? Maybe share a source?

Please explain me in more details why there is so much worry about systemd-boot?

May be some of following issues (not sure):

If I understood correctly, I was told on another forums, that Debian kernel in the future may lack support for non UEFI mode of booting?
So we could not boot a new kernel ? Actually I do not understand why.
Is not it easy to replace (rebuild with other options) a kernel which is compatible with old legacy boot without need for UEFI boot loader?

For old legacy PCs there is a boot loader with UEFI emulator:

https://wiki.archlinux.org/title/Clover

Or may be (I am not sure) an UEFI mode can be emulated on legacy PC  by software like OVMF:

https://wiki.osdev.org/UEFI#Emulation_w … U_and_OVMF

?

Or may be it is because new kernel can be tied to exactly systemd-boot?

It looks like corporations would like to put kernel and squeeze it in a vice from two sides: [boot] -> KERNEL   <- [userland system manager]

to get more control over users may be even like locking their boot process under some conditions.

If there is no direct tie between kernel and systemd-boot, then why we cannot replace systemd-boot with alternative boot loader?

There are a lot of other boot loaders available which have nothing to do with systemd:

https://wiki.archlinux.org/title/Arch_b … comparison

https://en.wikipedia.org/wiki/Comparison_of_bootloaders

Some info about Limine:

https://limine-bootloader.org/
https://wiki.archlinux.org/title/Limine

I learned about it a few months ago when I playing around with EasyOS.

whilst blanking the gummiboot repository and 404ing its webpage, instead of the standard practice of redirecting or posting suitable migration notices

Why is this *not* surprising? Leave it to these two muppets to do something like that. But you are correct, we would have to surgically extract these packages from the systemd source tarball Debian provides in order to properly use them standalone in Devuan, not to mention a shim for the kernel-install function. The latter should be reasonably straightforward with a shell script, but I worry that gummiboot may be too deeply entangled in systemd to be fully separable from it now. It would take work on the level of elogind or eudev, and that's not a one or two person job.

It was called gummiboot before. I don't know why they added it to the systemd. Anyway, is it possible to install that?

Systemd might primarily be the work of Lennart Poettering, but he did it in close collaboration with Kay Sievers.

Kay Sievers is the developer who created Gummiboot, and the same person who back in 2015 merged it into systemd, (whilst blanking the gummiboot repository and 404ing its webpage, instead of the standard practice of redirecting or posting suitable migration notices).

(Kay Sievers is also the one who Linus Torvalds banned from the kernel for repeatedly submitting buggy code and refusing to fix it.)

It is entirely unsurprising that Kay would make his project part of systemd.

-

If there is actually a benefit to gummitboot/systemd-boot over the various other options then the correct thing to do would be fork it and create an independent package unrelated to systemd - that is what Gentoo developers did with eudev when udev got merged into systemd.

-

When rebooted, the laptop *did* present the gummiboot menu, but there were no kernels to boot from, so I had to rescue it and reinstall grub. Seemingly, this command comes from systemd itself. Perhaps a shim could be made similar to the systemctl shim?

Ustable and Testing Systemd.

It is not on the banned packages list so we must do something creative to transform it.

It shows at the top of the page that this package comes from the main Debian systemd package source. This package happens to be one of the dependencies of systemd-boot, hence why I raised my concern. It also appears that the main systemd-boot package is dependent on the systemd shared private library.