All | Aquariums | Arduino | Btrfs | Cars | Cats | Clubbing | Computers | Dining | Diving | Electronics | Exercising | Festivals | Flying | Halloween | Hiking | Linux | Linuxha | Monuments | Museums | Outings | Public | Rc | Sciencemuseums | Solar | Tfsf | Trips



>>> Back to post index <<<

2010/04/25 Ubuntu Lucid and Mythtv 0.23 Upgrade, Please Don't Become Red Hat
π 2010-04-25 01:01 in Linux, Public
Summary from the post below, about why plymouth is the worst thing to have happend to ubuntu so far:

  1. it can't be removed and it can't be turned off.

  2. when booting with --verbose INIT_VERBOSE=true, plymouth still starts in text mode and writes useless progress dots on my screen that prevent me from seeing the debugging I need. Not only I can't remove it, but I can't even seem to stop it from spamming my screen :(

  3. plymouth is not finished, it SEGVs and requires a very recent kernel with devtmpfs or the system won't boot at all (!). Many people can't just upgrade to the latest kernel, especially on servers (in this case the forced kernel upgrade forced me to upgrade lirc which is in turn broken in lucid. Some servers come with drivers that don't yet work on recent kernels; sad but still a fact of life).

  4. like network-manager or upstart when they were added to ubuntu, there is virtually no useful debugging info on how to deal with this new system and how to remove/bypass it if it fails badly (which it does). By comparison, when RH introduced /etc/rc.d back in 1995 (yes, a while ago), they had a document explaining why it was better than rc.local, how it worked and how to debug problems.

In a nutshell, plymouth adds absolutely no functionality I need whatsoever and makes me want to stab ubuntu with something long and sharp because of how much of a pain in the ass it is and how much in the way it gets. It cost me many hours of painful and otherwise unnecessary debugging where I could hardly debug because of plymouth itself.
(upstart can be a pain for debugging too, but at least faster parallel booting is a good improvement, so I'll suck it up).

Of all things, if canonical only had 2 release requirements:

  • brand new shiny things should be optional and easy to remove/work without
  • they absolutely MUST have detailed information on how to be
  • debugged/worked around if they fail

    bonus:

  • if they touch the boot system like plugging into fsck of the root
  • filesystem, they had better be very well tested and be stable across many configurations.

    Unfortunately, canonical failed 3 times on those points with at least network-manager, upstart and now plymouth.
    I'm just much more angry here because plymouth is a useless piece of crap that only prevents me from booting/debugging my systems right now :(


    Original post below with more details:

    So, like all failed upgrades, this started with a reasonably working system. A bit like getting a newer dd-wrt version: because it felt like a good idea at the time, I thought I'd jump from mythtv 0.21 to 0.23RC2 all at once.
    I never went to 0.22, because quite frankly my mythtv box was working and I didn't see the point of mucking with it for features I didn't seem to need. But I was having some playback studdering problems with mythfrontend, they were getting annoying and they were apparently fixed in recent mythtv versions.

    The problem was that 0.23 was only available for lucid and maybe karmic while I was still running jaunty on my mythtv (in hindsight, I should have compiled it myself for jaunty, but I figured upgrading the base OS from time to time couldn't be that bad). That said, I still remember the upgrade to jaunty where ubuntu pulled off some custom kernel patch where the base system didn't boot with a standard kernel.org kernel when you had the evms package (some obscure problem with mounting lvm devices more than once).

    My plan was to upgrade as little of the system as necessary to get the mythtv packages working. Of course, I knew it might not be that simple due to the switch to upstart but I figured it'd be better than upgrading everything and risking to break a lot of things (including X, lirc, and sound, which can be interesting to tweak on a mythtv machine). In the end, that likely made no difference since the problem was mostly with plymouth.

    Well, of course, it went about as badly as it could: machine didn't reboot for multiple reasons, one being that plymouth would SEGV in mountall (something that the average user would already be hard pressed to find).
    Quite frankly, I think it sucks that ubuntu felt it was ok to require an experimental and somewhat controversial devtmpfs in a very recent kernel with no warning at upgrade time that the said kernel is required, and no dpkg dependency. If plymouth must absolutely depend on 2.6.32, it really should put out a warning at upgrade time that 2.6.32 and devtmpfs are required. And come on, it was non trivial for me to even find the problem and that it required devtmpfs to start with.

    About upstart: I know ubuntu means well with upstart, but man does this thing not work well, at least on upgrades. My fully dist-upgraded karmic laptop still does not reliably boot due to a (race condition in upstart, bug 499361), and lucid turned out to be worse on my mythtv: it somehow managed to start init scripts and things that mounted all my filesystems before fscking them in mountall, which then caused mountall to silently fail without being able to give me the usual sulogin shell, likely because of plymouth.

    As others have already echoed, plymouth looks like half baked still, and when it fails, it gives you a broken system that it super hard to debug :-/

  • Plymouth bug #1, stops boot from working, allegedly fixed.
  • Plymouth bug #2, requires DEVTMPFS kernel and SEGVs otherwise, stopping the boot (!).
  • Lucid beta2 release notes don't mention anything about kernel dependency or plymouth
  • Nothing about how to disable graphical boot. I don't want this crap if it stops me from debugging my system.
  • For debugging, I knew about --debug and nosplash, but they didn't help. Andrew told me about additional --verbose INIT_VERBOSE=true which I can't find documented anywhere and they didn't seem to do anything useful with the ubuntu kernel. Strangely enough when I switched to my kernel, I started getting stuff written on the screen although several processes were overlaying one another, it wasn't pretty...

    I'm afraid to state my experience with Ubuntu lucid, upstart, and now especially plymouth:
    Debugging a boot has become almost as hard as windows. Ubuntu, you're done: you've made the linux desktop as invasive as you could and almost matched windows on the "suckiness of debugging" scale.
    As for dependencies ending up so broken that mountall in rcS.d runs _after_ my partitions have been mounted and therefore fails and hangs the boot with no prompt I can see due to plymouth brokenness, that's just plain bad.

    The best part is that you can't even fix/debug a non booting system with init=/bin/bash so much because anything in /etc/init won't start if upstart wasn't launched as pid 1 (which is bash in this case). This "progress" really does not make debugging systems easier :(
    I also hate the fact where fsck is hidden and where the boot is just looking like it's not doing anything spinning the ubuntu dots while fsck is actually doing something or has silently failed or hung somewhere else that is not necessarily visible.

    Is this really an improvement from the old known good text boot?
    (maybe it's supposed to work better than that, but considering how badly it's capable of failing then, I don't really care).

    About the switch to fbconsole: killing X gives me an unusable flashing text console. It might be fixable, but is that really an improvement as a default: something I can't debug when it goes wrong?

    For now, after rebuilding a customer kernel in the hopes that I could boot and that lirc would work (I can only boot unfortunately, no lirc yet despite new versions and module rebuilds), the system almost boots but gdm won't auto start. Upstart of course makes debugging and fixing this non fun :-
    Of course, the problem here is that it's easy to just criticize other people's work without contributing. That's always been true: when you complain a piece of open source software doing something questionable or plain wrong, that's always an issue. At least, I pay my "dues" by making plenty of contributions myself (albeit not to ubuntu per se outside of the occasional detailed bug report) and I'm not making a big fuss about how my alsa sound got muted to 0 (master volume) after the upgrade: it's not hard for me to fix, even if the less technical end user all this extra polish is supposed to be for, might not fix this quickly.

    Ubuntu/Canonical, I switched from Debian to you because you were just plain better. You made me reconsider this with the network-manager fiasco that just broke my networking for a whole 2 years before it got finally fixed, and after this now pretty nightmarish upgrade that burned almost a weekend on getting my mythtv server working again, I'm really starting to reconsider my decision. Please remember that less can be more, and that more wiz bang polish is just a bad idea when it's a the expense of not having a simple system to understand and debug anymore when things go wrong (and will go wrong when you give it to end users).

    I was also looking at upgrading bunch of servers at work to lucid (from something much older), but now that I've seen plymouth and upstart dependencies that still don't work and are a pain in the ass to debug (hell, you never fixed/figured out why they still don't work on my laptop 6 months later, aka bug 499361), I am really reconsidering trusting servers with ubuntu karmic or newer now (aka pre/post-upstart).
    (quick update, upstart has gotten some debugging docs put up now. They weren't there when I really needed them, just like NetworkManager,

    Ubuntu/Canonical, I switched from Red Hat to Debian because Red Hat was focussing so much on the desktop that it started sucking on servers (at the time). You are now doing the same from where I stand: I don't really care about all that time wasted on which corner of the window the X will be, I don't even use gnome anyway, but don't lose focus on the server: this is what Linux is good at and if I can't trust Ubuntu for servers anymore (after my experience on my mythtv and broken/hard to debug upstart network dependencies that just hang boot on my laptop, I can't see myself putting lucid on servers), I am reconsidering Debian now: last I checked they still considered that for the server simpler is better.
    Also, if you introduce bold new systems which quite frankly aren't going to work quite right for a while, make sure easy to find documentation on how to debug them/work around them is posted in the release notes and easy to find places on the ubuntu site (being in search indexes for "foo debugging" is of course pretty much a must too). And on the mountall/plymouth front, if it's as bad as still getting SEGVs that just stop the boot very early (as of lucid beta2), wouldn't it be wiser to make plymouth a removable non required component? Yes, it's more work but it's also the safer thing to do and better for the users for whom plymouth either doesn't work or is something they could really do without.

    Now back to trying to fix lirc on my mythtv as it's been broken for a week after the upgrade (after 3 kernel recompiles and 2 upgrades of lirc userland stuff), but that's likely not ubuntu's fault but more likely the random suckiness that comes with upgrades and the fact that lirc still hasn't been deemed kernel merging worthy yet.
    *update* lirc was actually broken as shipped in lucid, I filed this bug. Man, lucid was a painful upgrade for my mythtv...


    More pages: November 2023 October 2023 September 2023 May 2023 August 2022 March 2022 November 2021 February 2021 June 2020 May 2020 March 2020 January 2020 December 2019 November 2018 July 2018 May 2017 September 2016 May 2016 September 2015 May 2015 April 2015 December 2014 July 2014 April 2014 March 2014 October 2013 May 2013 April 2013 January 2013 October 2012 September 2012 July 2012 May 2012 April 2012 December 2011 November 2011 July 2011 April 2011 March 2011 December 2010 November 2010 October 2010 August 2010 July 2010 June 2010 April 2010 March 2010 February 2010 December 2009 November 2009 October 2009 September 2009 August 2009 June 2009 May 2009 April 2009 March 2009 February 2009 January 2009 December 2008 November 2008 October 2008 June 2008 May 2008 April 2008 March 2008 November 2007 October 2007 September 2007 May 2007 March 2007 December 2006 November 2006 October 2006 September 2006 August 2006 June 2006 May 2006 February 2006 January 2006 December 2005 November 2005 October 2005 October 2004 August 2004 June 2004 May 2004 March 2004 September 1997 July 1996 September 1993 July 1991 December 1988 December 1985 January 1980

    >>> Back to post index <<<

    Contact Email