:: Re: [DNG] Giving Devuan sans-initra…
Page principale
Supprimer ce message
Répondre à ce message
Auteur: Simon Hobson
Date:  
À: dng@lists.dyne.org
Sujet: Re: [DNG] Giving Devuan sans-initramfs capabilities
Steve Litt <slitt@???> wrote:

> This idea came to me while I wrote an anti-merge rant a few minutes
> ago...


I was going to reply to that, I'll reply here instead ...

First off, thanks for answering a question I hadn't asked but had always wondered about the answer to. I "sort of" knew what initramfs was, but had always assumed it was "fairly simple" - I vaguely recall having poked about once in the distant past. TBH I've never really given it much thought, except when I've been fixing something and forgotten to update the initramfs before rebooting :-/

But over the last few days I've been tinkering in a "foreign land" to me. I use MythTV, I had one frontend running nicely, and due to changed personal circumstances wanted a second. I had an identical box lying around, so I thought "no problem - partition, make filesystems, copy all files, fixup fstab to suit the changed partitioning, install grub" just like I've done quite a few times with Debian (pre-systemd) systems.

Could I make this *******ing system boot ? Could I **** ! After that experience, my view of Ubuntu has gone from "fairly neutral" to "WTF!" How could anyone make a system so flippin hard to get to boot ! Usually I find I can at least manually edit the grub stanza to get the root fs mounted, and rebuild grub.cfg and initramfs from there - but I couldn't even get that working. Best I could manage was to set root= to an invalid partition so it dropped to buybox.
In the end I gave up and used dd to clone the disk - so much for UUIDs being unique ! And that's without systemd.

Just to add, further proof that one of the claimed "benefits" of systemd is in fact a huge problem just waiting to chew people's backsides off. Had a problem with no sound - because the second machine has a couple of tuners that the original didn't, and so the sound devices were different. Blacklisted a module, rebooted, got sound. Next time I booted, got no sound. Because the hardware probing and module loading isn't deterministic - on the next boot a different module had loaded earlier and subtly changed sh*t (needed to blacklist another module). So anyone that tells me that non-determinitic bootup is a "benefit" better have thick skin.

So yes, you are quite right that complexity is the enemy of reliability. The question shouldn't be "what else can we put in", but "what can we leave out".