[00:00] <joaopinto> is there a reason for a deboostrap to take 5x more time on lucid than it did on karmic ? mostly on the unpacking phase
[00:00] <bdrung> bryceh: yes, ums would be only a workaround.
[00:10] <bdrung> Keybuk: regarding bug #507613: i am not satisfied with the solution. why can't mountall mount the partition once the network is up? udev should help there.
[00:11] <bdrung> Keybuk: the second issue: pressing S or M does not have any effect.
[00:13] <Keybuk> oh sorry
[00:13] <Keybuk> I appear to have confused two bugs
[00:15] <Keybuk> bdrung: some poor sod got told to add _netdev to their /home I think
[00:16] <bdrung> Keybuk: i forced a reboot and something strange happend: first it look like it hang. one minute later the prompt asking whether you'd like to continue or drop to a shell appears. i pressed S and M. then the boot proceeds and the desktop appears with a mounted sshfs partition.
[00:17] <Keybuk> ?
[00:17] <Keybuk> if you have anything to add to the bug, please add information there
[00:18] <bdrung> something strange goes on there. i will try to reproduce the behavior
[00:20] <bryceh> pitti, slangasek, kees: I've added feedback from the three of you to the rootless-x blueprint page:  https://wiki.ubuntu.com/X/Rootless - it'll need further massaging to unify all the ideas, but that can be done post-uds.
[00:20] <bryceh> meanwhile feel free to elaborate on ideas further on that page
[00:21] <bryceh> not even really sure if we should still move forward with rootless-x for MM but if we do, sounds like there'll be a fair bit of work to do
[00:21] <bryceh> since 3 of the 4 of us will be off on other assignments, I phear for kees and raof ;-)
[00:22] <bdrung> Keybuk: adding _netdev worked.
[00:22] <Keybuk> bdrung: \o/
[00:22] <Keybuk> ok, mount man page says you had to have that
[00:22] <Keybuk> since fuse doesn't imply network
[00:24] <bdrung> Keybuk: since which release does this option exist?
[00:25] <Keybuk> err
[00:25] <Keybuk> sometime in the 1940s I think
[00:25] <Keybuk> certainly pre-Ubuntu
[00:25] <slangasek> kenvandine: um... ping
[00:25] <bdrung> Keybuk: :D
[00:26] <slangasek> kenvandine: the latest ubuntuone-client upload *still* has the string change in ubuntuone-preferences
[00:26] <bdrung> Keybuk: thanks for your help
[00:28] <YokoZar> cjwatson: I just removed libv4l from ia32-libs, you added it a long time ago, but we have lib32v4l now
[00:32] <bdrung> Keybuk: i updated the ubuntuuser wiki to avoid other user to have the same problem
[00:33] <Keybuk> schweet
[00:35] <bdrung> Keybuk: (and for me to not forget this parameter :)
[01:25] <Keybuk> slangasek: I gardened all the mountall bugs
[01:25] <Keybuk> can I have a lollipop?
[01:32] <slangasek> Keybuk: sure!
[01:33] <Keybuk> now to tell evolution I've read all the comments
[01:33] <Keybuk> keithp was showing me "notmuch" yesterday
[01:33] <Keybuk> I have never wanted a piece of software so much
[01:34]  * slangasek grins
[01:40] <psusi> Keybuk, I have marked up a bootchart with the area that appears to have almost no IO for about a second that seems to be caused by reading directory blocks during all of the open() calls by ureadhead for reference at http://imagebin.org/93343,
[01:41] <psusi> Keybuk, I was wondering if it would be possible ot hard link the files in the pack so they can be opend using that name where they all are in one directory
[01:41] <Keybuk> but then the path lookups wouldn't be cached
[01:41] <psusi> what happens if the file has multiple hard links?  does ureadahead go with the one that was used to open it when profiling?
[01:42] <Keybuk> it open()s both
[01:42] <psusi> hrm... good point
[01:42] <Keybuk> but only reads blocks once
[01:42] <Keybuk> there's benefit to getting those directory blocks into the page cache too remember
[01:42] <psusi> true... but you don't want to block waiting for a single 4kb read to do it...
[01:42] <psusi> hrm...
[01:42] <psusi> maybe you could readahead() the directory itself?
[01:43] <Keybuk> maybe, try it
[01:44] <psusi> guess I'll have to take a look at the tracing code now... I assume it was written to specifically filter out directories?
[01:45] <Keybuk> nope
[01:45] <psusi> hrm... it uses the same system blktrace does to trace?  so wouldn't it see the IO to the directories too?
[01:45] <Keybuk> no, it uses ftrace
[01:46] <Keybuk> well, trace_event specifically
[01:46] <Keybuk> I think blktrace uses something lower
[01:46] <Keybuk> though cbw
[01:46] <psusi> yea, it uses debugfs to relay trace events from the kernel
[01:47] <psusi> hrm... so you didn't have to filter out directories then?  so I guess yuod on't get them... hrm... damn..
[01:48] <Keybuk> apps don't tend to open() directories <g>
[01:48] <psusi> ohh, ftrace hooks the system calls of the processes to open()?
[01:48] <psusi> like with an LD_PRELOAD?
[01:49] <psusi> wait... no... hrm...
[02:07] <kenvandine> slangasek, it does?  debian/patches/revert_string_change.patch should be reverting it
[02:07] <slangasek> kenvandine: oh, it's under debian/patches, how quaint ;)
[02:07] <kenvandine> :)
[02:07] <slangasek> kenvandine: right - almost done reviewing, looks good so far
[02:08] <kenvandine> i didn't do it inline... to make it real clear :-D
[02:08] <kenvandine> thx
[02:08] <slangasek> I find this a strange definition of clarity :)
[02:09] <kenvandine> dpm has asked the translators if they will approve it, so they might want to revert... but i doubt it
[02:09] <kenvandine> this late
[02:09] <slangasek> yep
[02:10] <kenvandine> slangasek, well thx... i gotta go get these kids to bed :)
[02:29] <Keybuk> slangasek: I can tell I'm going to get distracted by writing a GTK+ interface to notmouch
[02:29] <Keybuk> notmuch too
[02:29] <slangasek> heh
[02:30] <slangasek> Keybuk: bug #537133> if I fix portmap, is there still an outstanding mountall bug?
[02:30] <Keybuk> slangasek: I'm not 100% sure yet
[02:30] <slangasek> ok
[02:31] <Keybuk> the patch works around the fact he never got SIGCHLD/wait() for the mount pid
[02:31] <Keybuk> which itself is a bit of an alarm
[02:31] <Keybuk> so would like a bit more debugging
[02:31] <Keybuk> need another machine to test NFS roots though, so will have to wait until I'm home
[02:31] <Keybuk> "Hi robbiew, I went to the Apple store and bought a new laptop because I needed a second one to test a bug while stranded in SF, hope that's ok"
[02:34] <akgraner> hi all I updated today and all my social from the start accounts are missing from empathy and gwibber, as if I never set them up and when gwibber trys to open I get more than 10 gwibber windows that open then I close them all and gwibber tried to reopen this time opening 5 gwibber windows  :-(
[02:34] <akgraner> has anyone heard of that happening today?
[02:37] <slangasek> akgraner: no, but there have been two gwibber uploads in the past two days; perhaps a bug report against that package is warranted
[02:39] <mhall> I am working on a kernel module which crashes when I try to load it due to some bug. Unfortunately plymouth on this lucide machine seems to be impossible to uninstall without also having forced uninstallation of mountall which seems dangerous. How can I cripple plymouth and just have a traditional pure ASCII VT with no framebuffer? Right now it prevents seen the crash dump, etc.
[02:39] <mhall> seeing the*
[02:42] <slangasek> mhall: boot without 'splash'
[02:43] <slangasek> not that this disables the framebuffer - plymouth isn't responsible for the framebuffer anyway, that's kernel+udev
[02:44] <mhall> yes but with splash off, the fb driver usually does not load fortunately
[02:44] <slangasek> not true
[02:44] <mhall> was empirically the case in the past on other machines for me at least
[02:44] <mhall> or perhaps it did load, but imperceptibly, and in a way which did not corrupt the dumps
[02:47] <slangasek> Keybuk: what's your availability this evening?  I'm going to put your new mountall ppa upload through its paces, wondering if I should try to get that done before you vanish for the evening
[02:47] <Keybuk> slangasek: I'm going to vanish in 43 minutes
[02:48] <slangasek> ok
[02:48] <slangasek> doubtful I'll have anything meaningful to report by then :)
[02:49] <Keybuk> I'll be back sometime later
[02:49] <Keybuk> unless I end up down the Castro ;)
[02:49] <slangasek> heh
[02:51] <psusi> god damnit... can't call readahead() on a directory fd... think it fails because directories don't get a mapping
[02:52] <mhall> psusi: what about madvise / mmap?
[02:52] <mhall> psusi: i suppose mmapping directories would not work
[02:52] <mhall> that's an annoying problem
[02:52] <psusi> yea, mapping doesn't work and it looks like the implementation of readahead() requires a mapping
[02:53] <mhall> psusi: d'oh
[02:53] <psusi> at least in the pagecache
[02:53] <psusi> and it looks like directories don't get pagecache mappings maybe?  not sure but that's where I see the code path returning EINVAL
[02:54] <mhall> psusi: it seems like the sort of thing which would be important for usenet, mail, etc.
[02:54] <mhall> psusi: typical Linux, implement something nice, but leave half of it totally broken for no clear reason. :D
[02:54] <Keybuk> someone is having a barbecue nearby, the smell is wafting into my room
[02:54]  * mhall barbecues plymouth
[02:54] <Keybuk> fortunately I'm going to a Churrascaria tonight
[02:56] <ion> Well, cat directory might as well output a bunch of struct dirents. :-P
[02:56] <slangasek> mhall: so does booting without 'splash' not let you see the crash dump?
[02:56] <mhall> slangasek: problem is, i removed all instances of splash from /etc/default/grub
[02:56] <mhall> slangasek: yet it keeps getting reintroduced on every update-grub
[02:57] <mhall> slangasek: and it is unclear what thing is reintroducing it... rww was assisting in main #u and was likewise baffled
[02:57] <psusi> read() refusing to work on a directory is fine, as is requiring O_DIRECTORY for open() to work on one ( doesn't seem to actually be required anymore ) but damnit, you should be able to readahead() the thing ;)
[02:57] <slangasek> mhall: it's being reintroduced *to /etc/default/grub*?
[02:57] <mhall> slangasek: reintroduced to the grub.cfg, sorry should have been more precise
[02:59]  * psusi wonders how the hell directories aren't mapped into the page cache... you'd think that would be rather large performance booster
[03:00] <mhall> psusi: i'm kind of horrified to hear it actually
[03:00] <mhall> psusi: perhaps they rely on the inode caching instead?
[03:00] <psusi> you mean dentry? yea, I guess so...
[03:00] <mhall> maybe they do not expect people to low-level hack on the directory FD
[03:01] <mhall> i mean, once you run 'find' on a dir, any operations inside or on the inodes there do go faster
[03:01] <mhall> so something is getting cached
[03:01] <psusi> yea but the kernel has to read the directory to parse the entries... it should just have it mapped in the page cache for easy access and caching....
[03:01] <psusi> well there is the dentry cache
[03:02] <psusi> once you namei() to translate a file name to an inode, that gets cached in the dentry cache
[03:02] <psusi> but you'd thing multiple nameis on files in the same directory would reuse the cached directory block... hrm..
[03:02] <mhall> psusi: perhaps because the pagecache is not a very efficient structure for holding dentries
[03:02] <mhall> psusi: maybe it makes more sense to store them in another way
[03:03] <psusi> well yea, the dentry cache is good, but while adding entries to the dentry cache you have to parse the raw directory... doing that should not require reading the block from disk every time... it HAS to be cached
[03:04] <mhall> but, let's say you read the dir, and push them all to the dentry cache
[03:04] <mhall> seems redundant to store the backing data in page cache eh?
[03:05] <psusi> yes but names only get put in the dentry cache when you try to open them
[03:05] <mhall> hmm
[03:05] <psusi> or stat...
[03:05] <mhall> so the block itself does not get cached anywhere
[03:05] <mhall> that's bad
[03:06] <mhall> so every new dentry from there needs to reread the block
[03:06] <psusi> it must be somewhere, just not in the usual pagecache way....
[03:06] <mhall> *facepalm*
[03:06]  * psusi reads more code
[03:12] <akgraner> slangasek, I'll file a bug just checked with some folks in my LoCo team they are having issues as well with empathy and gwibber - they need to be filed separately right?
[03:13] <slangasek> akgraner: that's best to start with, yes
[03:14] <akgraner> alrighty  - thanks
[03:14] <akgraner> :-)
[06:33] <Bacta> Hello
[08:01] <slangasek> Keybuk: mountall still no worky
[08:49] <slangasek> bryceh: xkeyboard-config> is an assertion that "this is how Windows does it" sufficient for us to change a keyboard layout?  And this layout already has the quotedbl symbol on the 2 key; eliminating the doublelowquotemark entirely means Russian-style quotation marks aren't supported
[08:51] <slangasek> bryceh: (I'm not surprised to be unable to find a description of Kazakh quote styles on the Internets, but the layouts here include "ruskaz" and "kazrus", which I would expect to support standard Russian orthography even if the quotes aren't used in Kazakh - http://en.wikipedia.org/wiki/Quotation_mark,_non-English_usage#Russian.2C_Ukrainian_and_Belarusian)
[08:55] <Bacta> Hello
[08:55] <Bacta> What's a good way to contribute code to Ubuntu?
[08:56] <Bacta> I have comitted some patches before but they weren't directly related to Ubuntu
[08:56] <owen1> dpkg shows  2:7.2.245-2ubuntu2    what does the 2: means?
[08:59] <imbrandon> epoc
[09:00] <imbrandon> 9.5-0ubuntu1 > 9.4-0ubuntu1 but 9.5-0ubuntu1 < 1:9.4-0ubuntu1
[09:00] <imbrandon> owen1: ^^
[09:01] <imbrandon> basicly its used when version numbers get wonky, but its best not to use it at all if possible
[09:07] <owen1> imbrandon: got it. so if i tell someone to install a version of a package, i should also mention those numbers?
[09:13] <imbrandon> no
[09:13] <imbrandon> its only for dpkg
[09:14] <slangasek> not exactly.  apt also uses it.
[09:14] <slangasek> so it depends on how you expect them to install the package
[09:14] <slangasek> if you're specifying a version on the commandline with apt, the epoch must be included in the version number
[09:15] <imbrandon> ahh my mistake, i thought apt ignored it also, well not ignored but would work without
[09:18] <cjwatson> YokoZar: thanks, fine by me
[09:18] <cjwatson> generally if you're describing a version number you should quote the epoch too
[09:19] <cjwatson> it gets left out of filenames to avoid causing problems with certain tools, that's all
[09:19] <cjwatson> but it's still part of the version number
[09:42] <bryceh> slangasek, I didn't really look into it very deeply, if you think it's not right, go ahead and punt out the package.  The patch should go upstream regardless, and if they take it we'll get it eventually.
[09:43] <slangasek> bryceh: the patch may be correct for the default keyboard variant, but I think it'll regress the variants that are meant to support Russian
[09:43] <bryceh> I figured since the guy is a Ubuntu translator for that language and submitted a patch to change it, he knew what he was saying, but perhaps he didn't
[09:44] <slangasek> bouncing the package, then
[09:51] <nigelb> the kazak keyboard quote bug?
[09:52] <slangasek> yes
[09:53] <nigelb> hm, even I was hoping upstream would give us a comment about it
[11:03] <slangasek> tjaalton: the pam-config integration you've proposed adding to sssd has some problems; the maintainer script integration is missing (calling pam-auth-update --package), and the 'password' entries indicate that password changes will not be possible for users with local-only accounts
[11:03] <slangasek> tjaalton: and the 'Priority' field doesn't seem to follow the guidelines in https://wiki.ubuntu.com/PAMConfigFrameworkSpec
[11:04] <slangasek> tjaalton: so I'm rejecting the upload; will follow up to the bug report
[11:05] <tjaalton> slangasek: oops
[11:06] <tjaalton> slangasek: if I fix those will you accept it?-)
[11:08] <slangasek> tjaalton: I would at least consider it; though I'm wary of such changes at the last minute, since the last pam config /I/ wrote broke all kinds of things for users that were only caught after upload, and I wrote pam-auth-update :-P
[11:09] <tjaalton> slangasek: ok, I could drop that too
[11:10] <tjaalton> then there would be only real bugfixes in the upload
[11:11] <slangasek> that would be fine
[11:11] <tjaalton> alright, will upload it without the pam-config
[11:18] <matumba> s.
[11:19] <matumba> slangasek, cause you're talking about pam-auth-update: could you check if i filed bug 564842 against the right package?
[11:21] <tjaalton> i'm having weird problems with winbind as well.. I get the krb ticket but still need a kinit to access my kerberized nfsv4 $HOME
[11:33] <aburch> Is there an extra channel for backports?  I was wondering why #550880 was not approved yet given that the dependencies are currently broken.
[12:03]  * antivirtel is back (gone 00:34:03)
[12:08] <stikonas> I've reported bug #565294 about the broken Lithuanian KDE translations.
[12:08] <nigelbabu> !away > antivirtel
[12:10] <ion> Uh. The private message feature is kind of moot if the bot sends a channel message anyway. :-P
[12:11] <nigelbabu> ion, not if the original message is around 4 or 5 lines long
[12:21] <Riddell> stikonas: I've added Ubuntu Translations to that bug report
[12:22] <Riddell> stikonas: dpm is the guy to poke, give him a ping on Monday if you haven't heard by then
[13:04] <tjaalton> slangasek: hmm, looks like on shutdown rpc.gssd is killed before the shares are unmounted, making shutdown take several minutes
[13:10] <wgrant> tjaalton: Kerberized NFSv4 home, or something more sinster?
[13:11] <tjaalton> tjaalton: yep
[13:11] <wgrant> Odd -- works fine for me here.
[13:11] <tjaalton> well, maybe the fact that there are 100 mounted shares has something to do with it
[13:11] <wgrant> Ah.
[13:11] <tjaalton> lots of users
[13:12] <tjaalton> so it's stuck flushing them
[13:12] <wgrant> Yep.
[13:13] <tjaalton> 15:11 < tjaalton> tjaalton: yep
[13:13] <tjaalton> wtf :)
[14:05] <joaopinto> is it plymouth do the KMS mode switch ?
[14:07] <joaopinto> argh, Canonical ppl shuld work on the weekends :P
[17:43] <ircipimp> hi
[17:44] <ircipimp> i'm still troubleshooting the nomodeset issue, since i'd like to have some "acceptable" boot process using fglrx. yesterday i was recommended using "nomodeset", but still the splash screen looks just like a 8bit magnified version of the standard splash.
[17:44] <ircipimp> is there a way to force plymouth into text-only mode?
[17:54] <ircipimp> plymouth-set-default-plugin text as used on fedora doesn't exist on ubuntu and changing the text.plymouth entry in /etc/alternatives doesn't work
[18:37] <ruthgard> !couchdb
[18:37] <ruthgard> !ubuntuone
[20:33] <jdong> at what stage of initramfs is plymouth supposed to draw a splash
[20:33] <jdong> on my nvidia system, it seems like the splash only shows up after the root mounts
[20:33] <jdong> and barely stays on the screen for 2 seconds before X starts
[20:34] <jdong> (but there is 5 seconds or so worth of blank blinking cursor after GRUB before plymouth)
[20:36] <ion> jdong: Sounds like the expected behavior to me.
[20:36] <ion> jdong: Not that the behavior is pretty or non-confusing, but that’s how it’s implemented for lucid.
[20:36] <kklimonda> yup, plymouth doesn't start from initramfs - it's launched pretty late on purpose (see bug 540801)
[20:37] <kklimonda> there is a nice command one can use to make plymouth start drawing a bit earlier..
[20:37] <ion> Yes, but it’ll make your system boot slower.
[20:37] <kklimonda> heh
[20:40] <jdong> ion: ok, gotcha.
[20:40] <ion> To get a pretty splash sooner, you have to load an assload of stuff before doing readahead, which is a loss.
[20:40] <jdong> ion: sounds logical -- just wanted to make sure
[20:45] <ScottK> jdong: OK.  Now that you're sure, go fix some bugs ...
[20:46] <jdong> lol hehe
[20:46] <ircipimp> http://pastebin.com/xChbj6D1
[20:46] <ircipimp> that's the list of packages jockey installs when setting up a brother network printer
[20:46] <jdong> what's unusual?
[20:47] <ircipimp> is this expected to happen... the list looks totally bloated to me, thinking that all there's needed was the correct .deb file supplied by brother
[20:47] <jdong> seems like it installs a QT4 based control panel and the Brother driver is an RPM?
[20:47] <ircipimp> yes, but it used to be a deb and i'm sure, brother-cups-wrapper-laser is all that's needed, as it used to be under karmic
[20:49] <ScottK> doko: Would you please look at Bug #542634 and make a recommendation.
[20:52] <ircipimp> i'm unable to select a driver from the printer settings. all possible printers are displayed but the "next" button is grayed out.
[20:52] <ircipimp> :(
[20:56] <c_korn> can someone confirm that vino-server consumes a lot of cpu after some minutes ?
[21:27] <slangasek> matumba: bug #564842 - I'm not sure if that should even be considered a bug
[21:28] <slangasek> tjaalton: oh; should we avoid stopping gssd on runlevel [06]?
[21:37] <matumba> slangasek, sudo reacts different on the same input depending on the existence of a totally unrelated package - doesn't sound like expected behavior (not that i would consider this anything but cosmetic)
[21:37] <slangasek> not unrelated at all
[21:37] <slangasek> winbind is an authentication-related package
[21:41] <tjaalton> slangasek: how exactly can I test if that'd help?
[21:42] <slangasek> tjaalton: well, I'm fairly certain it will help you, I'm just trying to think if there's a downside
[21:42] <tjaalton> slangasek: heh, right
[21:42] <slangasek> tjaalton: you can test it by editing /etc/init/gssd.conf and changing it to just 'stop on stopping portmap'
[21:43] <tjaalton> oh, of course
[21:45] <slangasek> mr_pouit: when updating xubuntu-meta, please use the debootstrap from the current Ubuntu dev release; using the Debian one causes germinate to throw an error for the next person to try to update :)
[21:45] <joaopinto> is anyone familiar with KMS issues with intel graphic cards, hanging during boot ?
[21:46] <ScottK> joaopinto: Which Intel?
[21:46] <ScottK> The i845 experience is known to be "unfortunate".
[21:46] <tormod> loads of i8xx cards were blacklisted for this in the last kernel
[21:46] <joaopinto> ScottK, I have been trying to help an user which has been on #ubuntu+1 since yesterday
[21:46] <joaopinto> bug 565109
[21:47] <joaopinto> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
[21:47] <joaopinto> disabling plymouth he was able to boot with an older kernel, that was the best we have achieved
[21:48] <ScottK> 945 I'm not aware of any major issues.  You might ask in #ubuntu-x.
[21:48] <ScottK> tormod: I think those were all 845.
[21:48] <slangasek> I have a 945 and it works fine; I've seen signs that there may be Dell-specific problems with 945+KMS
[21:48]  * ScottK has an 865 system that is a little fragile, but working not so bad (much better than Karmic)
[21:49] <slangasek> joaopinto: what happens when booting with 'nomodeset'?
[21:49] <joaopinto> isn't plymouth the one using the KMS ?
[21:49] <ScottK> No, it's a kernel option
[21:49] <ScottK> (as slangasek suggests)
[21:50] <joaopinto> hum, but how is it invoked ? the loads fine, he gets fine into the initramfs
[21:50] <joaopinto> so there is something after which invokes the mode set for the graphical mode
[21:50] <ScottK> joaopinto: To avoid it, add nomodeset to the boot parameters
[21:50] <joaopinto> slangasek, checking, he did so many things :P
[21:51] <joaopinto> ok, will do
[21:51] <slangasek> KMS is "kernel mode setting".  It's /used/ the first time something wants a graphical mode; initially that will be plymouth, after that it'll be X, generally any bugs in KMS will be seen with or without plymouth because plymouth doesn't do anything clever with KMS
[21:52] <joaopinto> slangasek, ok, like I was thinking, so if we have disabled plymouth, and we are booting into rescue mode, and it still hangs can't be KMS related, or shouldn't be
[21:52] <slangasek> true
[21:52] <slangasek> well - depending on what you mean by "disabled plymouth"
[21:52] <joaopinto> mv /etc/init/*plymouth* /etc/disabled
[21:53] <slangasek> don't do that
[21:53] <slangasek> you might be causing a *different* bug if you do that
[21:53] <joaopinto> however, disabling plymouth makes it boot with 2.6.28, and then it hangs on gdm
[21:54]  * hyperair wonders if the nosplash option works with plymouth
[21:54] <joaopinto> slangasek, it was just to be sure plymouth was not the one hanging :P
[21:54] <joaopinto> and according to some user which disabled like that it works :)
[21:54] <matumba> slangasek, err, you're obviously right (common-auth...), shame on me. so you think this bug report would rod in lp and nobody would care? if so, i'm fine with closing it.
[21:54] <slangasek> hyperair: no, 'nosplash' has never been a supported option
[21:54] <hyperair> slangasek: the lack of "splash" then.
[21:54] <slangasek> hyperair: we use 'splash' - if you don't want splash, take the 'splash' option /off/
[21:55] <hyperair> slangasek: so it can be disabled that way. i was just checking.
[21:55] <slangasek> matumba: probably so - the behavior of pressing ^C at a PAM prompt isn't defined, modules are totally allowed to retry
[21:55] <joaopinto> slangasek, "nomodeset" did not help, still hanging
[21:55] <slangasek> hyperair: dropping 'splash' means you don't get a splash screen.  plymouth still runs.
[21:55] <slangasek> hyperair: because even if you don't want a splash screen, something has to be there to serialize console I/O
[21:56] <hyperair> slangasek: ah i see.
[21:56] <slangasek> joaopinto: hanging with a splash screen up, or hanging when gdm starts?
[21:56] <joaopinto> uff, there should be some easy way to do step by step boot for this problems
[21:56] <hyperair> slangasek: strange, when we used usplash, it just completely didn't run, or did it? what serialized the console I/O then?
[21:56] <slangasek> joaopinto: and does the user have all packages up-to-date?
[21:56] <slangasek> hyperair: nothing, that's why we *got rid of usplash* :)
[21:56] <slangasek> it was inadequate for the task
[21:57] <hyperair> slangasek: okay, then why do we need to serialize console I/O? does it make a difference?
[21:57] <joaopinto> slangasek, yes, he did an update && upgrade with livecd+chroot
[21:57] <slangasek> hyperair: because in the general case, mountall and cryptsetup both need to talk to the user at boot time, and may each have more than one question, and something needs to arbitrate
[21:58] <hyperair> slangasek: aah i see. thanks for the info =)
[21:58] <slangasek> if you don't have plymouth, you have *no* way of talking to mountall
[21:58] <slangasek> and everybody kinda needs mountall
[21:58] <matumba> slangasek, it doesn't retry - it just shows the password prompt (as soon as i hit the enter key i'm back at the terminal prompt, even if the pwd was ok)
[21:58] <slangasek> matumba: oh; then that sounds like a low-prio bug, yes
[21:58] <hyperair> slangasek: what does the user need to talk to mountall for?
[21:59] <hyperair> slangasek: wasn't it for the recovery shell and fsck thing?
[21:59] <slangasek> hyperair: when a fsck fails, you're going to want to talk to mountall
[21:59] <slangasek> hyperair: or when you can't mount /home because the drive caught on fire, but you still want to be able to boot and recover
[21:59] <slangasek> or when you misconfigured /etc/fstab and it's waiting for a device in the gamma quadrant before continuing
[21:59] <matumba> slangasek, i'll edit the description to make that clear - but the package is samba and not pam, right?
[22:00] <slangasek> matumba: it is *probably* samba, but I would have to dig to see
[22:00] <hyperair> slangasek: nice descriptions =p
[22:01] <hyperair> slangasek: i remember being able to talk to both cryptsetup and mountall in karmic, though
[22:01] <slangasek> do you?
[22:01] <slangasek> my memories disagree with yours
[22:01] <slangasek> I remember cryptsetup+mountall in karmic being a total disaster
[22:02] <slangasek> you could talk to one of them, as long as the other didn't want your attention at the same time
[22:02] <joaopinto> slangasek, it hangs during text mode, no splash or error is shown
[22:02] <matumba> slangasek, k, i'll leave it at samba then. thx for your input :)
[22:02] <hyperair> slangasek: i use cryptsetup on a daily basis. and during the days of 2.6.32, ext4 gave me endless hell. every other time i booted up, mountall failed and i had to run a manual fsck.
[22:02] <tjaalton> slangasek: turns out that it's just as slow umounting them even with gssd running, so it's something else
[22:02] <slangasek> hyperair: cryptsetup for the rootfs, or cryptsetup for passphrase prompting post-initramfs?
[22:03] <slangasek> tjaalton: ok
[22:03] <hyperair> slangasek: rootfs. i guess that made the difference
[22:03] <slangasek> hyperair: yep - the initramfs is already serialized for you
[22:03] <hyperair> ah
[22:03] <slangasek> so doesn't count :)
[22:03] <hyperair> i see.
[22:03] <hyperair> heheh
[22:03] <joaopinto> btw, we have tried init=sulogin+exec init, it hang on init
[22:03] <hyperair> i'm glad i had a weird enough setup that avoided this bug =p
[22:04] <slangasek> hyperair: nah, that's how I'm set up too, but /I/ got to see all the bug reports from people who set up their systems differently.. :)
[22:04] <hyperair> slangasek: i don't envy you =p
[22:04] <slangasek> joaopinto: I've tried init=/bin/sh and it doesn't work, I haven't investigated why
[22:05] <slangasek> joaopinto: "no splash or error shown" - are you booting without 'quiet'?
[22:05] <joaopinto> I am sure it did that already, re-checking
[22:08] <joaopinto> I have checked the http://upstart.ubuntu.com/wiki/OMGBroken , it doesn't help much to debug upstart if we can't start it without automatically starting the "hanging" task
[22:09] <slangasek> joaopinto: if booting with an initramfs, 'break=init' works; you just have to run 'chroot /root /bin/bash' first before doing anything else
[22:10] <slangasek> (and init= failing is definitely a bug that we should get fixed in Lucid, I've just been too busy fixing the bugs that led me to *need* init= first...)
[22:10] <joaopinto> slacker_nl, well, booting with init=/sbin/sulogin works, and the / is already mounted
[22:10] <joaopinto> ops, slangasek
[22:10] <slangasek> does it?
[22:10] <joaopinto> it does
[22:10] <slangasek> interesting
[22:11] <slangasek> then maybe I just have a local bug
[22:11] <joaopinto> but then the  "exec /sbin/init" to lunch upstart will hang
[22:11] <slangasek> hmm
[22:12] <slangasek> try booting with '--verbose init=/sbin/sulogin'
[22:12] <joaopinto> --verbose is a kernel option ?
[22:12] <slangasek> no, it's an upstart option
[22:12] <slangasek> oh
[22:12] <slangasek> you could also just do 'exec /sbin/init --verbose' ;)
[22:12] <joaopinto> ok :)
[22:17] <joaopinto> btw, it boots fine from the livecd
[22:17] <joaopinto> slangasek, it hangs after "[    8.672448] EXT-fs: mounted filesystem with ordered data mode" with or without verbose
[22:20] <slangasek> joaopinto: oh?  this problem *only* happens when booting from disk?
[22:22] <joaopinto> slangasek, yes
[22:26] <tormod> joaopinto, try "nohdparm"
[22:27] <joaopinto> tormod, tomorrow, he is travelling
[22:28] <joaopinto> luckily he had a lot of patience, has been trying for about 24h
[22:29] <tormod> joaopinto, well you have a lot of it too :)
[22:30] <joaopinto> it was a good opportunity to re-learn the boot process, is not very interesting unless you have a problem to identify :P
[22:32] <joaopinto> after this I may be able to write a wiki page, there is nothing covering the boot process in general, you have one about kernel options, another about upstart, etc, but nothing general to guide
[22:32] <tormod> joaopinto, that would be awesome
[22:34] <joaopinto> it needs to cover: bios intro+grub2+kernel+upstart+core tasks: plymouth, mountall, gdm
[22:36] <tormod> joaopinto, I started on an overview once: https://wiki.ubuntu.com/Booting
[22:37] <joaopinto> tormod, oh looks great, we just need to continue it :)
[22:39] <tormod> that page mostly tries to explain how your disk is discovered independently three times after each other :)
[22:39] <ScottK> nhandler: Would you make me a debdiff out of 564070, suitable for sponsoring?
[22:39] <tormod> or in fact how this can be thee different disks
[22:39] <nhandler> Yeah, I can do that ScottK
[22:39] <ScottK> Thanks.
[22:53] <mr_pouit> slangasek: hmpf, because it harcodes the debootstrap version somewhere? annoying :]
[22:53] <mr_pouit> ah right, in debootstrap-version
[22:58] <c_korn> ok, I think vino-server crashes and it should be reproducible
[23:08] <c_korn> I filed bug 565633
[23:12] <c_korn> is there a tag I should add to notice that I have a backtrace ?
[23:14] <chrisccoulson> c_korn - are you sure you just enable remote desktop in vino-preferences? the backtrace shows vino-server got a SIGTERM
[23:14] <chrisccoulson> incidentally, i can recreate the CPU usage issue when stopping vino-server
[23:15] <c_korn> chrisccoulson: hm, yes. might be that the cpu consumption started after I stopped it. let me try again.
[23:15] <chrisccoulson> yeah, it looks like
[23:15] <chrisccoulson> it
[23:15] <chrisccoulson> urgh
[23:15] <chrisccoulson> oops
[23:20] <c_korn> indeed it crashes on stop
[23:25] <chrisccoulson> c_korn, yeah, that makes sense. so, i get your issue too
[23:25] <chrisccoulson> would you mind forwarding that upstream?
[23:27] <c_korn> chrisccoulson: is there some reportbug script for GNOME bugs ?
[23:27] <chrisccoulson> c_korn - not that i'm aware of
[23:31] <c_korn> chrisccoulson: https://bugzilla.gnome.org/show_bug.cgi?id=616063
[23:32] <chrisccoulson> c_korn - thanks
[23:33] <c_korn> chrisccoulson: how can I link the upstream bug in LP ?
[23:34] <chrisccoulson> c_korn - click on "Also affects project"
[23:34] <chrisccoulson> i just added the upstream link though
[23:35] <c_korn> chrisccoulson: oh, ok. thanks.