sooo... don't remove /bin/plymouth (say, by uninstalling the "plymouth" package) and still expect your system to boot. Oh yeah, there's no warning when you removed the plymouth package a week or two ago. And there's nothing on screen to indicate what the problem might be, you *must* have a root password set (sorry, Debian and Ubuntu users who didn't do that) in order to log into safe mode, run "journalctl -xb" and see the error where being unable to execute /bin/plymouth is a FATAL error.
Yup, this systemd thing sure makes booting my systems a lot faster... *&^%$#@!
(And if anyone noticed that the new MUUG mirror server was down for a while tonight, systemd is the culprit. It also doesn't like filesystems that take more than a few seconds to mount and/or fsck. Which would not include a 40TB XFS LVM volume. *&^%$#@! again.)
On 2015-05-15 Adam Thompson wrote:
sooo... don't remove /bin/plymouth (say, by uninstalling the "plymouth" package) and still expect your system to boot. Oh yeah, there's no warning when you removed the plymouth package a week or two ago.
Oh joy. Lucky me, it's one of the few things I haven't culled yet. However, the rpm -qi indicates it's a ripe target for rpm -e:
Plymouth provides an attractive graphical boot animation in place of the text messages that normally get shown. Text messages are instead redirected to a log file for viewing after boot. ===
I don't want an attractive boot. I want it as ugly as it can be. So that's one I would have removed, had I known.
yum remove plymouth shows it only has deps on plymouth-* rpms, meaning that it does look safe to remove.
Did you find a workaround that *didn't* involve reinstalling plymouth? If I had to guess, I'd say dracut -f solves the problem, as with much of systemd. It's at the point now I want to run dracut -f after any yum command. Or maybe a change to /etc/default/grub.
And there's nothing on screen to indicate what the problem might be, you *must* have a root password set (sorry, Debian and Ubuntu users who didn't do that) in order to log into safe mode, run "journalctl -xb" and see the error where being unable to execute /bin/plymouth is a FATAL error.
That brings up another thing I should have mentioned for Gilbert et al when first starting with systemd. Turn back on syslogging!!
in rsyslog.conf: #TEC must have off or we don't get any v/l/m $OmitLocalLogging off
So now we (mostly) dupe the binary logs into sane text logs. Still no way to disable the binary logs... If I had to pick one gripe about systemd to complain about the loudest, this would be it. It's *sooo* not UNIX. What's next, a registry?
(And if anyone noticed that the new MUUG mirror server was down for a while tonight, systemd is the culprit. It also doesn't like filesystems that take more than a few seconds to mount and/or fsck. Which would not include a 40TB XFS LVM volume. *&^%$#@! again.)
Fun. There'll be a workaround I'm sure, and I'm sure Lennart would tell you the functionality is newer and better now so just live with it, and if you don't you hate handicapped people (you did watch my prior video link, right?). What he fails to see is this is 1 hour spent learning new workarounds to new bugs times X thousand people who also hit the problem, times X thousand new bugs.
Admins don't want new stuff for the sake of new stuff; admins want tried and tested and learned and known and debugged old stuff that they already know, even if it runs a bit slower. They want up boxes, not down boxes.
Bah