would like to find a way to contribute

Thorsten Glaser t.glaser at tarent.de
Sun Jul 17 02:46:47 BST 2022


Hi,

> range of services, so NetBSD was fine, but in my next job I used it to
> replace a wide variety of legacy services, and chasing security updates was
> dismaying.)

just use those right for the job. I managed to sneak a MirBSD system
into $dayjob but mostly it’s Debian and derivates.

> I was involved with Devuan for a while, but[…]

Thanks for the detailled reasons why me being wary of them
is a good thing.

> get out of Debian directly. Shipping elogind, libelogind0, and eudev to a
> large extent mean you're still depending on systemd and just calling it

Yeah, that too. I dropped elogind after several misadventures with
it just changing system behaviour in unexpected ways.

Though given who’s udev’s maintainer in Debian I think we could gain
from having an independent implementation…

> I'm aware of an issue that bites me using sysvinit today, wherein root on
> LUKS cycles through timeouts as it's never able to unlock. As of Bullseye,

This is weird. The unlocking is done in the initrd so it’s independent
of the init system. I vaguely recall having had trouble with luks when
using the autodetect partition types, but with 0xDA everything works
for me; normally there’s LVM on LUKS but on one installation, I directly
put ext4 on it and use it as root filesystem.

It used to be that you have to put rootdelay=5 into GRUB_CMDLINE_LINUX
but this system doesn’t use that either. nor GRUB_DISABLE_LINUX_UUID
(which is for when you use root on LVM). The /boot/grub/grub.cfg root=
uses the UUID.

bye,
//mirabilos
-- 
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)



More information about the Debian-init-diversity mailing list