Re:Why systemd is a problem for embedded Linux
by blueflow on Sunday November 03, 2024 @06:38PM
(#42037044)
That "occasional weird problem" is because systemd is not designed to be used with other software. While you technically still have the choice to roll your own non-systemd initramfs, it will be an uphill battle.
[ Parent
| on HN ]
Re:Why systemd is a problem for embedded Linux
by jcalvinowens on Sunday November 03, 2024 @07:28PM
(#42037328)
> That "occasional weird problem" is because systemd is not designed to be used with other software.
That's not true, systemd has an explicitly documented and supported initrd interface: https://systemd.io/INITRD_INTERFACE/
It's actually really easy, there's rarely a reason for the initrd to be more complex than a single 50-line busybox script on an embedded device with built-in drivers.
Re:Why systemd is a problem for embedded Linux
by blueflow on Monday November 04, 2024 @04:13AM
(#42039839)
"really easy" except for the hotplug events that don't get to systemd and cause your problem.
Re:Why systemd is a problem for embedded Linux
by jcalvinowens on Monday November 04, 2024 @11:25AM
(#42043054)
I got an immediate answer with a solution from the upstream developer when I asked about it: I can't imagine how that could have been easier to solve. And it was also trivial to hack around by leaving the entry out of fstab and mounting it in a script.
Re:Why systemd is a problem for embedded Linux
by blucaz on Sunday November 03, 2024 @08:12PM
(#42037529)
Debian, Ubuntu and all derivatives thereof use initramfs-tools, which does not use systemd in the initrd, and things work just fine
Re:Why systemd is a problem for embedded Linux
by bmicraft on Monday November 04, 2024 @10:47AM
(#42042617)
Ubuntu is literally trying to replace it with dracut as we speak.
Re:Why systemd is a problem for embedded Linux
by helloka on Monday November 04, 2024 @05:09PM
(#42046506)
https://dracut-ng.github.io/dracut-ng/developer/compatabilit...
Dracut is used both in Void Linux and on Alpine without systemd and with busybox.
It even runs continuous integration with musl based containers.
Re:Why systemd is a problem for embedded Linux
by blueflow on Tuesday November 05, 2024 @03:39AM
(#42049741)
Alpine uses mkinitfs per default, tho.
Re:Why systemd is a problem for embedded Linux
by noncoml on Sunday November 03, 2024 @07:14PM
(#42037233)
Not uphill at all; try buildroot
Re:Why systemd is a problem for embedded Linux
by binkHN on Sunday November 03, 2024 @10:27PM
(#42038153)
Not an uphill battle at all; Void Linux does this by default and has for many years.
Re:Why systemd is a problem for embedded Linux
by blueflow on Monday November 04, 2024 @03:23AM
(#42039617)
Void Linux dropped systemd because it wouldn't work with a different libc than glibc. Which i would add as next point in my systemd lock-in list.
Re:Why systemd is a problem for embedded Linux
by chasil on Monday November 04, 2024 @12:50PM
(#42044146)
The embedded people will naturally look at busybox. I saw it running on a credit card scanner at Old Navy a few years ago.
It has an init:
$ /home/busybox-1.35 init --help
BusyBox v1.35.0 (2022-01-17 19:57:02 CET) multi-call binary.
Usage: init
Init is the first process started during boot. It never exits.
It (re)spawns children according to /etc/inittab.
Signals:
HUP: reload /etc/inittab
TSTP: stop respawning until CONT
QUIT: re-exec another init
USR1/TERM/USR2/INT: run halt/reboot/poweroff/Ctrl-Alt-Del script
On an embedded system, that will be a strong contender for pid 1.