Systemd-boot(it's actually not tied to systemd) possible in devuan?

recklessswing · 2023-10-22 13:24:13

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

UnixMan1230 · 2023-10-22 15:16:20

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)

recklessswing · 2023-10-23 16:22:49

UnixMan1230 wrote:

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...

Altoid · 2023-10-23 16:36:19

Hello:

recklessswing wrote:

Why do this?

Why?
I'll quote myself ...

Altoid @ 2023-09-05 08:10:34 wrote:

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.

UnixMan1230 · 2023-10-23 20:45:11

Altoid wrote:

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)

ralph.ronnquist · 2023-10-23 22:38:39

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?

EDX-0 · 2023-10-25 21:47:18

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'

UnixMan1230 · 2023-10-25 23:17:05

Would it be able to be maintained independently of systemd source though, or would the libraries still be needed? @EDX-0

golinux · 2023-10-25 23:39:05

UnixMan1230 . . . What exactly do you mean by "systemd source". Are you talking about files like these?

UnixMan1230 · 2023-10-26 00:14:54

@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)

golinux · 2023-10-26 00:35:55

Perhaps this thread will be helpful?

Ustable and Testing Systemd.

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

ralph.ronnquist · 2023-10-26 01:42:56

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.

fsmithred · 2023-10-26 13:25:40

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.

UnixMan1230 · 2023-10-26 13:40:19

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)

boughtonp · 2023-10-26 14:18:23

recklessswing wrote:

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

recklessswing wrote:

...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)

UnixMan1230 · 2023-10-26 18:42:57

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.

pcalvert · 2023-10-27 01:43:31

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.

UnixMan1230 · 2023-11-18 13:07:56

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)

bimon · 2024-03-06 21:41:01

Hello Dear Devuan users!

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

Last edited by bimon (2024-03-07 01:40:29)

UnixMan1230 · 2024-03-10 01:06:40

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?

bimon · 2024-03-13 01:20:39

https://www.linux.org.ru/news/novell/17 … d=17542939

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.

EDX-0 · 2024-07-15 00:04:54

well, necroposting side, it doesn't seem like there would be complication to the plan of using the systemd sources to build an 'egummyboot' after rolling a shim that provides the functionality of kernel install, at least so long as the upstream systemd-boot does NOT integrate the libraries and utilities of systemd more into it's own code beyond the level of simply calling their named binaries for the function, tho still i will say for as simple as that seems it almost feels like there's a foot gun waiting to happen there...

UnixMan1230 · 2024-08-24 01:38:47

I just realized that Devuan could *probably* use the .install files to create shim packages. Basically its own fork of the systemd package that *only* builds portions that work without systemd and aren't directly tied to it. Kind of like elogind. *kind of...* still at the mercy of upstream, though.

EDX-0 · 2024-08-25 11:27:14

perhaps a more "sane" approach would be a repo with 3 branches:

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.

The officially official Devuan Forum!

#1 2023-10-22 13:24:13

Systemd-boot(it's actually not tied to systemd) possible in devuan?

#2 2023-10-22 15:16:20

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#3 2023-10-23 16:22:49

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#4 2023-10-23 16:36:19

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#5 2023-10-23 20:45:11

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#6 2023-10-23 22:38:39

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#7 2023-10-25 21:47:18

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#8 2023-10-25 23:17:05

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#9 2023-10-25 23:39:05

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#10 2023-10-26 00:14:54

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#11 2023-10-26 00:35:55

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#12 2023-10-26 01:42:56

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#13 2023-10-26 13:25:40

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#14 2023-10-26 13:40:19

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#15 2023-10-26 14:18:23

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#16 2023-10-26 18:42:57

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#17 2023-10-27 01:43:31

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#18 2023-11-18 13:07:56

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#19 2024-03-06 21:41:01

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#20 2024-03-10 01:06:40

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#21 2024-03-13 01:20:39

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#22 2024-07-15 00:04:54

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#23 2024-08-24 01:38:47

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

#24 2024-08-25 11:27:14

Re: Systemd-boot(it's actually not tied to systemd) possible in devuan?

Board footer