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.