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