Marc's Public Blog - Linux Hacking

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

This page has a few of my blog entries about linux, but my main linux page is here
Picture of Linus

Here is a list of older linux event reports I made before my blog was started, then the rest are below
1996/11/18-21:Linux Pavillion Comdex Fall 1996 (photos only). I've been going since then to help at the linux pavillion.
1997/11/18-21: Linux Pavillion Comdex Fall 1997 (photos only)
1998/05/28-30: Linuxexpo 1998 (photos only)
1998/11/16-20: Linux Pavillion Comdex Fall 1998 (full report)
1998/11/11: Silicon Valley Tea Party (report with pictures)
1999/02/15: Windows Refund Day (report with pictures)
1999/03/20: SVLUG KTEH night (photos only)
1999/03/01-04: LinuxWorld Expo Winter 99 (complete report with many pictures)
1999/03/31: Mozilla Party one year anniversary (photos only)
1999/05/18-22: Linuxexpo 1999 (complete report with many pictures)
1999/06/07: June 99 Balug meeting with Linus
1999/08/09-12: LinuxWorld Expo Summer 99 (complete report with many pictures)
1999/11/15-19: Linux Business Show at Comdex Fall 1999 (full report with pictures)
2000/08/14-17: LinuxWorld Expo Summer 2000 (complete report with many pictures)
2001/01/17-20: 2001 (complete report with pictures)
2001/07/25-28: OLS 2001 (photos only)
2001/08/25: Linux 10th Anniversary (report with pictures)
2001/09/27-30: LinuxWorld Expo Summer 2001 report with pictures)
2001/11/05-10: ALS 2001 (photos only)
2002/06/26-29: OLS 2002 (photos only)
2003/01/20-25: LCA 2003 (photos only)
2003/07/23-26: OLS 2003 (photos only)
2004/01/12-17: LCA 2004 (photos only)
2004/07/21-24: OLS 2004 (photos only)
2005/04/18-23: LCA 2005 (photos only)
2006/01/24-28: LCA 2006 (photos only)
2007/01/17-21: LCA 2007 (photos only)

Here is a list of all the talks I've given:

And below are my blog posts:

>>> 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


  • 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 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: February 2004 March 2004 November 2004 April 2005 August 2005 January 2006 July 2006 August 2007 November 2007 January 2008 October 2008 November 2008 December 2008 January 2009 May 2009 July 2009 August 2009 September 2009 November 2009 December 2009 January 2010 March 2010 April 2010 June 2010 August 2010 October 2010 January 2011 July 2011 August 2011 December 2011 January 2012 March 2012 May 2012 August 2012 December 2012 January 2013 March 2013 May 2013 September 2013 November 2013 January 2014 March 2014 April 2014 May 2014 October 2014 January 2015 March 2015 May 2015 January 2016 February 2016 March 2016 June 2016 July 2016 August 2016 October 2016 January 2017 September 2017 January 2018 March 2018 December 2018 January 2019 January 2020 May 2020 September 2021 March 2023 April 2023

    >>> Back to post index <<<

    Contact Email