Watching dracut, udev, systemd, and plymouth all battle each other for nfs/ramboot

I can’t even begin to describe the complete and utter broken-ness of this mess. This doesn’t look like systemd issue, its just the poor stack trying to get everything else working.
But plymouth. Seriously. It should be given the old-yeller treatment.
And watching udev not … settle … is … amusing.
While its doing that, the dracut options of debug, drop to a shell, break, etc. aren’t working.
This isn’t engineering at this point. Its fire suppression.
I am blown away at how completely broken this stack is. I can’t even imagine “what were they thinking”. This isn’t anti-systemd. This is anti-crap.
Sadly, I think I need to find a solution, which, based upon past experience with this, involves spending as absolutely little time in the distro tools as possible. That is, I have to retro-fit and remove large swaths of their breakage in order to do what I need it do, correctly, repeatedly, and reliably.
Back in the RHEL/CentOS 5/6 days, I built a PXE-kickstart system that laid down a basic OS on software RAID with our kernel and some enhanced stack bits in /opt/scalable. As I discovered early on, the kernel/initrd/initramfs bits were borked somehow, precisely to prevent the type of software RAID on OS that I wanted to build. So I wrote a bunch of extensions that pushed it out of the way, and merely handed it an operational md0 for install.
This was needed, as it didn’t do a good job of it. And then later, during initramfs build, I injected some additional intelligence in to handle the fact that it was booting from a software RAID. This took a while to correctly fix, and again, involved me shunting much of their “intelligent” tools to the side, doing what was needed, and presenting a fait acompli .
This was old … and isn’t getting any better any time soon from what I can see.
Seriously, the entire boot process in this distro family is horribly borked.

1 thought on “Watching dracut, udev, systemd, and plymouth all battle each other for nfs/ramboot”

  1. Current stacks’ making the typical case complex has made the complex case infeasible. Driving me nuts in other cases. Even my laptop doesn’t always boot up correctly because one of the zillion little software bits isn’t started at quite the right time.

Comments are closed.