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.
Viewed 19609 times by 1983 viewers