BusyBox Drops Systemd Support

[oleid]

Well, busybox has been running on embedded systems and initramfs'es for a long time now. Obviously systemd is something that is not needed in that arena at all. You shouldn't be using systemd in that space anyway. Anybody trying to shove systemd into an initrd is stupid.

Why is that stupid? I use systemd in the initramfs for booting up our workstations at university. They use NFS as rootfs and thus, networking is configured in the initramfs. By using systemd in initramfs, the init system was clever enough not trying to reconfigure network later during the boot and thus the NFS connection doesn't get interrupted. By using systemd, booting our gentoo workstations on NFS-root was a breeze - it basically worked out of the box. I tried openrc before, but I stopped after editing the 5th init script and trying to figure out what blocks bootup or shutdown.

Furthermore, as GreatEmerald mentioned, systemd is used by Sailfish OS. It works great there.

[interested]

Well, busybox has been running on embedded systems and initramfs'es for a long time now. Obviously systemd is something that is not needed in that arena at all. You shouldn't be using systemd in that space anyway. Anybody trying to shove systemd into an initrd is stupid.

You don't know what you are talking about: systemd is working already in initramfs on Fedora, Debian etc., so you have full service management and logging from even before rootfs is mounted. And systemd and journald can not only pivot from initramfs to rootfs when it is mounted, they can also pivot back to initramfs when shutting down the system so you can unmount rootfs and safely disassemble large raid arrays before turning of the power, and even potentially get logging info from after rootfs has been unmounted. Really cool and useful stuff.

systemd is also increasingly being used in embedded systems (together with dbus). The GenIVI group are building their embedded stuff on systemd and are working on kdbus too. From security frameworks, service management, watchdogs, to internationalisation of error-messages, systemd have long passed any similar functionality in busybox in functionality.

It is simply a matter of time before systemd becomes as dominant in the embedded field as it is among among desktop and servers.

[duby229]

You don't know what you are talking about: systemd is working already in initramfs on Fedora, Debian etc., so you have full service management and logging from even before rootfs is mounted. And systemd and journald can not only pivot from initramfs to rootfs when it is mounted, they can also pivot back to initramfs when shutting down the system so you can unmount rootfs and safely disassemble large raid arrays before turning of the power, and even potentially get logging info from after rootfs has been unmounted. Really cool and useful stuff.

systemd is also increasingly being used in embedded systems (together with dbus). The GenIVI group are building their embedded stuff on systemd and are working on kdbus too. From security frameworks, service management, watchdogs, to internationalisation of error-messages, systemd have long passed any similar functionality in busybox in functionality.

It is simply a matter of time before systemd becomes as dominant in the embedded field as it is among among desktop and servers.

No your right, I have made several embedded systems based on gentoo where I had to make an initramfs myself. I can say I learned a lot, but I can't say I ever really mastered it. As for how you explained it, I can certainly see the appeal. I don't want to discourage the adoption of open source projects in commercial products. Commercial interest is usually where money for development comes from. Which means those guys can do whatever they want to do.

[duby229]

Why is that stupid? I use systemd in the initramfs for booting up our workstations at university. They use NFS as rootfs and thus, networking is configured in the initramfs. By using systemd in initramfs, the init system was clever enough not trying to reconfigure network later during the boot and thus the NFS connection doesn't get interrupted. By using systemd, booting our gentoo workstations on NFS-root was a breeze - it basically worked out of the box. I tried openrc before, but I stopped after editing the 5th init script and trying to figure out what blocks bootup or shutdown.

Furthermore, as GreatEmerald mentioned, systemd is used by Sailfish OS. It works great there.

Yeah, I'm reading on the topics you and interested pointed out and there is a lot of commercial interest in just what I called stupid. Well, I can't take back what I said. Gentoo has genkernal for creating initramfs files. I don't need to use it very often and my needs aren't very extensive. I'm maintaining a gentoo based live flash drive I use with tools I need mostly for repairing windows machines. So I admit my needs are pretty narrow and don't cover a broad spectrum of usage.

[ryao]

Why is that stupid? I use systemd in the initramfs for booting up our workstations at university. They use NFS as rootfs and thus, networking is configured in the initramfs. By using systemd in initramfs, the init system was clever enough not trying to reconfigure network later during the boot and thus the NFS connection doesn't get interrupted. By using systemd, booting our gentoo workstations on NFS-root was a breeze - it basically worked out of the box. I tried openrc before, but I stopped after editing the 5th init script and trying to figure out what blocks bootup or shutdown.

Furthermore, as GreatEmerald mentioned, systemd is used by Sailfish OS. It works great there.

Unfortunately, no one has worked much on / on NFS support. I suggest opening an issue.

That said, how did you put systemd into your initramfs? As far as I know, there is no established way of doing that. Dracut does not, although some people might think it does in Fedora et al.

[ryao]

You don't know what you are talking about: systemd is working already in initramfs on Fedora, Debian etc., so you have full service management and logging from even before rootfs is mounted. And systemd and journald can not only pivot from initramfs to rootfs when it is mounted, they can also pivot back to initramfs when shutting down the system so you can unmount rootfs and safely disassemble large raid arrays before turning of the power, and even potentially get logging info from after rootfs has been unmounted. Really cool and useful stuff.

systemd is also increasingly being used in embedded systems (together with dbus). The GenIVI group are building their embedded stuff on systemd and are working on kdbus too. From security frameworks, service management, watchdogs, to internationalisation of error-messages, systemd have long passed any similar functionality in busybox in functionality.

It is simply a matter of time before systemd becomes as dominant in the embedded field as it is among among desktop and servers.

Would you explain how systemd is inside the initramfs on Fedora? As far as I know, Fedora uses Dracut and it only has udev.

The ability to pivot to an initramfs environment as the last stage of shutdown is not unique to systemd and it is not typically used on systemd distributions. that is something that we had tried in Gentoo in 2012 for ZFS, but it turned out to be based on an incorrect understanding of the shutdown process, so we killed it. It is possible that there are rootfs configurations that actually need it, but I have yet to see them.

That said, here are links to the files in the old CVS repository showing that we had the capability:

https://sources.gentoo.org/cgi-bin/v...tic=0&view=log
https://sources.gentoo.org/cgi-bin/v...tic=0&view=log

It would not surprise me if this predates Redhat's conception of the idea, although I have not verified that.

[Nille]

I don't care. With a decision like this, you can only loose.

[DeepDayze]

Yes why not just make systemd support be optional and off by default? Turning it on could just be a config option in the config file or be compiled in.

[andre30correia]

I don't care. With a decision like this, you can only loose.

their choice

[yoshi314]

Seems a very childish reason for dropping it but the choice is his to make.

yeah, it seemed to be something short and that required almost no maintenance, so this is just some kind of attention grab move.