| |
π
2010-10-24 01:01
in Linux, Public
So, linux upgrades can always be a bit painful: software gets upgraded, things change (not always for the better), and there is not always a lot of (or any) QA on upgrade paths, so things do break.
There is nothing new there, I've been doing this for 15 years, so I'm used to it.
Just to say that I'm not picking on plymouth, other random things broke during my recent upgrades, and I fixed it (including Xorg switching to kernel modesetting, and requiring i915.modeset=1). Usually it's just a matter of googling for error messages and applying the answers.
(plymouth is a new 'feature' that hides all the boot messages by default, replaces them with a splash screen and tries to capture text output from the boot and log it, which it still does improperly as of today, including by dropping them if there are too many).
A few release backs, the switch to upstart was a bit painful. I can't say I was super thrilled with it, especially when at the time documentation and debugging info was sparse. This has however been fixed (the documentation that is), and while there are still bugglets here and there (statd won't start properly on my laptop), at least my boot doesn't randomly hang on networking dependencies anymore ( https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/499361 ). But the main part is that I'm willing to be more patient and understanding with upstart because it is a clear win for linux: it is good progress on functionality.
And this brings up to the trainwreck otherwise known as plymouth.
So, you might ask, what is so wrong with plymouth? Well, how about this:
Plymouth changes some very core parts of the system, and was rolled out by over eager people way before it was finished. If Red Hat does that on Fedora which is used for experimentation on mostly willing users, great. That canonical puts this in Long Term Support Lucid in the half baked state that it was: very lame (6 months ago, I upgraded my mythtv to lucid to pick up new mythtv packages and their dependencies. Needless to say that it didn't go so well, and that plymouth really sucked and made my life miserable then: http://marc.merlins.org/perso/linux/post_2010-04-25_Ubuntu-Lucid-and-Mythtv-0_23-Upgrade_-Please-Don_t-Become-Red-Hat.html ).
As a result, I entirely skipped lucid on my main laptop and waited for maverick with some dim hopes that it would get a bit better. Long story short: not significantly so.
Plymouth is still mostly undocumented as of today. man plymouth and man plymouthd still return nothing. Searching for 'plymouth ubuntu' or 'plymouth' on ubuntu.com does not return anything useful. What do you think I'd be wanting?
-
If you are going to be significantly changing all our systems, you'd better post a good rationale as to why the change is good and desirable. This was done for upstart and even mostly for network-manager (nevermind the many problems that network-manager had for 18 months after being pushed to all before it was mostly useable and stable). The cynic will point out that lack of rationale for the switch to plymouth is that said rationale is very dubious.
-
If you are going to be pushing a big change to all our system (hell, it's only how they boot, how they fsck drives, and how you can get to single user mode, or not), you'd better bad a page that explains how it works, how you debug it, and how you work around it if you have to. Why is it that even getting 'noplymouth' as a boot option is such a highly guarded secret apparently?
-
If you really need to put a multiplexer in the boot system, which is a big change, make baby steps: add it while keeping text mode booting by default for at least existing installs. Debug the hell out of it (it looks to me that as text mode booting as you can get with plymouth is a very little tested code path, unless the entire code is as buggy still as what I experienced in text mode).
-
Who thought that they were going to make friends with us by forcing that utterly useless "you don't need to see your boot, it might have useful debug info that might be useful to you, we can't have that". Why is it that is is so fscking hard to turn off plymouth boot message stealing? Even after turning off the graphical crap, you still get a useless one in text mode spinning around colored text dots. Really ?!?!
noplymouth INIT_VERBOSE=yes at the lilo prompt seems to do it for me right now, but where on earth is that documented?
So, that's really my beef with canonical on this one: I care much much more about having a system I can upgrade mostly safely like I can in debian, than this graphical crap that is downward hurtful to my system. I really don't care about how windows-like you can make linux look like (up to an un-debuggable and opaque boot), I'm really not interested.
Ubuntu/Canonical, stop the madness, please. Do impose some standards on your eager developers who think they came up with the last 'this is so cool' thing to add to linux, especially when it affects essential parts of the system.
I think I'm also specifically bitter about plymouth in ubuntu because its presence could have been made optional in init scripts (Red Hat even had such support in their init scripts), but in ubuntu "it's obviously good enough for everybody, so eat it and shut up".
For more details on what went wrong this time with plymouth, if you are curious:
on top of being hard to turn off, plymouth still broke my custom 'ask password from the command line' code in my initrd for cryptpart (by disconnecting stdin from my shell script it seems, thank you very much for that). I just re-opened my filed bug: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/665789 which was closed as invalid (sure, it's ok to break cryptsetup and it's invalid to complain about it since plymouth is obviously necessary (it's not, I'm booting without it right now); perfect, so the problem must be with me, not plymouth; and properly documented (all those people all over google searches asking how to turn it off or generally kill plymouth are probably just a statistical error).
I had a problem with /usr, apparently because the system has been rebooting without unmounting partitions cleanly (some other bug probabably). When I asked to be dropped to a prompt to debug, I got a shell where /usr was mounted and where I could't umount it (fuser -kvm did not help at that point).
some other plymouth bug stopped me from getting to real single user mode: I got both a single user console and a second process still asking me for my root password, both stealing keystrokes at the same time. End result was that I couldn't type anything.
at the next boot, while I was still trying to get a single user prompt, plymouth just answered fsck for me that it was ok to fsck -f -y /usr and scroll many pages of vital errors that I could not capture and that were lost (a few lines ended up in /var/log/boot.log, but not enough to be useful). In my book, plymouth actually caused data loss here, thank you (thankfully I have backups).
I could go on (it does go on), but that's long enough, you get the idea....
As sad as it is, and with people like Steve Langasek ( https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/665789 ) who are now probably understandably defensive about plymouth, likely due to many complaints like mine, instead of doing the right thing and making it really optional, writing a rationale on ubuntu.com as to why it's there and why we should love it, and especially documenting the crap out of it, I'm now dubious as to whether ubuntu/canonical will get a clue about this and whether I should just switch back to Debian where I haven't seen much insanity like this... |
|
