News for hackers. Stuff that matters.
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.
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.
Re:Why systemd is a problem for embedded Linux by blueflow on Tuesday November 05, 2024 @03:44AM (#42049773)
This is what Alpine Linux use, Alpine also uses OpenRC for service startup.