You are not logged in.
It was called gummiboot before. I don't know why they added it to the systemd. Anyway, is it possible to install that?
Offline
not likely, systemd-boot-efi and systemd-boot both come from the systemd source. They're not explicitly in the banned packages, but they may have broken dependencies due to systemd source and package being banned.
Edit: you can always check out banned packages here http://deb.devuan.org/bannedpackages.txt
Last edited by UnixMan1230 (2023-10-22 15:17:55)
Offline
not likely, systemd-boot-efi and systemd-boot both come from the systemd source. They're not explicitly in the banned packages, but they may have broken dependencies due to systemd source and package being banned.
Edit: you can always check out banned packages here http://deb.devuan.org/bannedpackages.txt
grrr screw their developers really. Way to blow a good software like this.. Just tie it to systemd. It's not even related to systemd in any way. Why do this? I don't get it...
Offline
Hello:
Why do this?
Why?
I'll quote myself ...
Deprecating SystemV support was the last step in that direction.
lwn.net/Articles wrote:"Support for System V service scripts is now deprecated and will be removed in a future release. Please make sure to update your software
*now* [1] to include a native systemd unit file instead of a legacy System V script to retain compatibility with future systemd releases."[1] the asterisks are not mine, they are in the original.
The inevitable result will be that in a very short time there will be no SystemV compatible packages in the Debian repositories as devs/maintainers will not include init scripts for a deprecated init in their packages, something that will inevitably extend to all Debian based distributions using systemd.
I've said it many times before: there is a lot of moolah behind making systemd the de-facto init for the Linux ecosystem.
systemd is nothing but a MS registry for Linux and the main purpose is to turn Linux into a MS type OS, with all that such a thing implies.Like a poster at The Register once said with respect to systemd:
"... it is nothing but a developer sanctioned virus running inside the OS, constantly changing and going deeper and deeper into the host with every iteration and as a result, progressively putting an end to the possibility of knowing/controlling what is going on inside your box as it becomes more and more obscure."
But there's nothing new at hand: it is the old MS embrace, extend, and extinguish that has been going on for decades, only that now there's active and quite visible participation from IBM/RH and last but not least Microsoft, corporation that that went from labelling Linux a cancer to wanting to become best friends with it while everyone smiled and said "how nice of them to do so".
Devuan (and derivatives) is still holding on but who knows for how long this will be so.
Do you know where Poettering works these days?
Now ...
Do you understand why?
Best,
A.
Offline
The inevitable result will be that in a very short time there will be no SystemV compatible packages in the Debian repositories as devs/maintainers will not include init scripts for a deprecated init in their packages, something that will inevitably extend to all Debian based distributions using systemd.
There are still other experimental inits being supported in Debian, leaving the door open for someone to at least prop up SysVinit support in Debian. Question is, can the manpower be found to do it?....
Last edited by UnixMan1230 (2023-10-23 20:45:34)
Offline
Why the hell do you all insist on filling the forum with repetitions of previous posts.. in full or in parts. Are you all pre-schoolers? Do you think people can't read and remeber for a few seconds?
Offline
there's some use to having refference posts be quoted, tho permalinks would be the way to go...
as for systemd-boot, how about a fork that only changes the name, something like egummiboot, as long as the source keeps unrelated to systmed (no hard dependency) the main dev can comfortably be sed doing all the necessary iterations of:
sed 's/systemd-boot/egummiboot/g'
Offline
Would it be able to be maintained independently of systemd source though, or would the libraries still be needed? @EDX-0
Offline
UnixMan1230 . . . What exactly do you mean by "systemd source". Are you talking about files like these?
Online
@golinux I'm referring to what i see on this page:
https://packages.debian.org/sid/systemd-boot-efi
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.
Last edited by UnixMan1230 (2023-10-26 00:23:44)
Offline
Perhaps this thread will be helpful?
It is not on the banned packages list so we must do something creative to transform it.
Online
The first "point of call" for packages could be like:
https://pkginfo.devuan.org/systemd-boot
https://pkginfo.devuan.org/systemd-boot-efi
Those packages are in the repo without forking since chimaera.
Offline
Those packages will install in devuan. I tried it. I could not get the system to boot - something about the virtual machine not supporting efi variables. Maybe someone who knows their way around gummiboot would have a better chance.
Offline
I tried it on my UEFI laptop this morning, threw an error about the "Kernel-install" command not found. A cursory search led to this:
https://manpages.debian.org/testing/sys … .8.en.html
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?
Last edited by UnixMan1230 (2023-10-26 13:40:44)
Offline
It was called gummiboot before. I don't know why they added it to the systemd. Anyway, is it possible to install that?
...It's not even related to systemd in any way. Why do this? I don't get it...
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.
-
Last edited by boughtonp (2023-10-26 14:20:12)
3.1415P265E589T932E846R64338
Online
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.
Offline
As an alternative to systemd-boot, you may want to consider Limine.
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.
Freespoke is a new search engine that respects user privacy and does not engage in censorship.
Offline
Just as a follow-up, after reading up on it a bit and furthering my understanding of how banned packages work, it seems I was confused on how the sources worked. so my last comment was right -a shim would be needed for the "Kernel-install" function. But it seems a simple shim would be all that's needed, at least as a short-term solution. So perhaps this isn't as much of a challenge as i thought...
Last edited by UnixMan1230 (2023-11-18 13:22:23)
Offline