[00:04] soren: so if this is at boot time, the /intent/ is that the bridging interface will be brought up once any of the child interfaces are brought up; but the Debian maintainer of ifenslave-2.6 brought up a concern that there might not be any locking here, so if both child interfaces start in parallel, one could miss. Does that sound like what you're seeing? === dendrobates is now known as dendro-afk [00:15] kklimonda, https://bugs.edge.launchpad.net/ubuntu/+source/glib2.0/+bug/638513 [00:15] Launchpad bug 638513 in glib2.0 (Ubuntu) "PyGtk App Core dumps" [Undecided,New] === evilnhandler is now known as nhandler === nhandler_ is now known as nhandler [00:47] rickspencer3: I've got a smaller testcase: http://pastebin.com/RwY03ht8 [00:48] huh, I thought I tried something like that, and it didn't repro [00:48] lets see if I can reproduce it in C [00:48] anyway, thanks for that [00:48] much better [00:57] I can't reproduce it with a hasty written C program but it's way too late for me to debug it further.. but I think that pygtk may be to blame after all [00:59] kklimonda, makes sense [00:59] thanks for looking into it === bjf is now known as bjf[afk] [02:07] slangasek, ping [02:07] andreserl: hey there [02:09] slangasek, hi. I just got your email. 1st. There was no FFe filed given that I understood these as a bug fix to get pacemaker in better shape, so I saw no need to file an FFe [02:10] second, the overriden warnings also appeared when the libraries were back in pacemaker itself [02:10] andreserl: fair enough; I happen to disagree that it doesn't need an FFe, but I see that it can be a matter of opinion whether this is a new feature vs. a bugfix [02:10] slangasek, third, what's your recommendation or approach to fix this :) [02:10] andreserl: the overridden warnings aren't new, yes - they're also not the reason for the reject [02:11] andreserl: my recommendation depends on how this package is intended to be used. Are you splitting these packages because another new package will be uploaded that uses libpacemaker-dev? [02:13] slangasek, not really. We, (me and ivoks) are trying to get pacemaker and cluster-glue into main. cluster-glue was rejected because of similar issue as pacemaker [02:13] so as discussed with ivoks, he came to a conclusion that the split was the best to make them *more policy* compliant [02:14] andreserl: heh - I would have rejected libcluster-glue as well if I had seen that :) [02:14] we've been trying to get this done in upstream (library split) however, they are not interested on it :) [02:14] what part needs done upstream? [02:14] slangasek, pacemaker, cluster-glue, and heartbeat have a similar separation of libraries [02:15] slangasek, upstream is working with debian on getting the packages, and as per ivoks discussion, they have rejected the need to have the library split in pacemaker and cluster-glue [02:15] I'm not sure what you mean, the libraries are already split [02:16] slangasek, I'm sure you;ll understand this better :) https://bugs.launchpad.net/ubuntu/+source/cluster-glue/+bug/527142/comments/13 [02:16] Launchpad bug 527142 in cluster-glue (Ubuntu) "[MIR] cluster-glue" [Undecided,Incomplete] [02:17] ok; so it's more about a delta from the Debian packages [02:17] upstream library split isn't terribly interesting to me one way or the other [02:18] there are plenty of source packages in the archive that build both libraries and executables, and that's fine - the key point is in how you /package/ the libraries so that things don't break on upgrade [02:19] oh; and there are multi-level library interdependencies, and the libraries don't use symbol versioning [02:20] so partial upgrades --> segfaults, yay [02:20] if only it was partial upgrades --> partial segfaults [02:21] if you mean upgrading from ubuntu2 to ubuntu3 (which includes library split), it upgrades as expected according to my tests. Now, if this is the case, the same behaviour should be seen in other packages such as cluster-glue [02:21] given that besides pacemaker, cluster-glue and all other related packages come from upstream [02:23] andreserl: I mean that if one library changes soname and the other doesn't, and the library that doesn't gets upgraded, but an application that linked against both libs is not upgraded, you get segfaults [02:24] i see [02:24] andreserl: so are the libraries in libpacemaker guaranteed not to have any soname changes? [02:24] if that's the case, then this can be accepted [02:24] but first the file conflict between pacemaker and libpacemaker-dev should be resolved [02:25] (so it needs a new upload, no matter what) [02:25] lifeless: which part would you like to segfault? :-) [02:25] slangasek, afaik they wont have soname changes but I'm not sure. I'd rather talk to upstream and get back to you on that [02:25] ok [02:26] that's the main thing I'm concerned about here - forward-planning [02:26] it's a lot harder to retrofit a solution when it comes to lib upgrades [02:27] I see (notice that I'm not a library packager expert, in fact, this is my first attempt to package libraries) [02:28] anyways, on the side of the file conflict between pacemaker and libpacemaker-dev, what's the best approach to address this?? [02:29] andreserl: well, the file that's conflicting doesn't belong in a -dev package because it's a runtime lib [02:29] so I guess putting it in pacemaker only would solve it :) [02:31] slangasek, oh I think I just realized what the issue is. So, yeah it's and easy fix [02:31] ok so, the only thing right now would be to guarantee that there won't be a soname change in future releases, correct? [02:33] andreserl: yes [02:34] slangasek, ok then. I'll discuss this with upstream and get back to you tomorrow. If this is the case, I'll have new packages ready for tomorrow :) [02:34] if not, you'll help me get the packaging in better shape :) [02:37] andreserl: sounds good :)( [02:37] :) [03:01] * psusi wonders what the deal is with canonicalizing device names from /dev/mapper/foo to /dev/dm-x [03:17] slangasek, should I address any other lintian stuff such as: E: pacemaker: postinst-must-call-ldconfig usr/lib/service_crm.so === dendro-afk is now known as dendrobates [04:05] andreserl: that one seems to be a false positive, given that this is the same file that returns the improper-soname error :) [04:29] slangasek, ok then :) First error is fixed, now just waiting for upstream's word on the sonames :) [05:34] ScottK: re python-defaults 2.6.6-2 [05:34] Sep 13 12:02:46 mwhudson: It it's not done by Wednesday, please remind me. [05:34] i don't think it's been done? === bjf[afk] is now known as bjf === almaisan-away is now known as al-maisan === bjf is now known as bjf[afk] [06:17] mwhudson: No. It hasn't. Unfortunately I'm heading to bed and it turns out I'll be offline almost all of tomorrow. You might also ask doko. [06:17] ScottK: ok, i'll poke him if i get the chance [06:50] Hrm.. installing on a Dell mini 1012 w/ netbook edition 10.10 beta.. it seems the installer window is only using half the width of the screen [07:39] Good morning [07:43] wow... installing from 10.10-beta on a netbook has been, so far, extremely painful [07:43] mutter and plymouth segfaulting.. hundreds of packages to update.. :-P [07:56] SpamapS: plymouth segfaulting, or being killed by the OOM killer? === Zic_ is now known as Zic [08:40] slangasek: Actually I think it was OOM killed [08:41] slangasek: either way, install on netbook was horrendous [08:41] and after upgrade, I can't login with a netbook session [08:44] I just get a blank white screen :-/ [08:56] slangasek: Nope, this dude only has one interface on the bridge. [08:57] whoa, and gnome help is all unicode sequences instead of characters [08:58] slangasek: So if someone has "auto br0" in his /e/n/i, the networking upstart job will attempt to configure it, and adding the interface will fail. Right? [08:58] slangasek: Err... assuming the physical interface hasn't turned up yet, I mean. === spike_ is now known as spikeWRK [09:55] Hello pitti! Is there a way to workaround this in apport-collect? It's a blocker bug. bug #628755 [09:55] Launchpad bug 628755 in w3m (Ubuntu) "Impossible to log in in Launchpad using apport from a tty console" [High,Confirmed] https://launchpad.net/bugs/628755 [09:57] btw, I'm thinking about marking it as "Critical". mmhh.. [10:28] primes2h: install links? [10:28] primes2h: apport-collect also prints out the URL, so if you have this problem on a remote server, you can just open the URL locally [10:28] pitti: that is ubuntu-bug, apport-collect don't do it. [10:29] at least, I haven't seen links. [10:29] s/don't/doesn't [10:39] primes2h: works here [10:40] $ apport-collect 12345 [10:40] The authorization page: [10:40] (https://edge.launchpad.net/+authorize-token?oauth_token=DEADBEEF [10:40] should be opening in your browser. [...] [10:40] pitti: Does it appear in a terminal? [10:40] yes, that was from a temporary test user I su'ed to [10:41] that's standard launchpadlib login_with() [10:46] pitti: I get the "The authorization page: bla bla" only when I quit w3m. I must run apport-collect on tty1 because GUI doesn't start. Does that link allow to upload info from the broken pc even if I put it on another pc browser? [10:46] yes [10:50] pitti: I remember that using ubuntu-bug there is an explicit advise about using the link on another pc, in apport-collect there isn't. It would be nice to add it as well. [10:50] that'd need to go into launchpadlib [10:50] but yes, would be nice [10:51] pitti: btw, I'm going to try it. [10:52] pitti: I can open a bug about that improvement [10:52] thanks [11:03] Hi guys I'm having issues with une this morning I upgraded and I get the new background and gdm, then once I log in I get a white background with a white arrow and that's all, no unity/icons/toolbar etc [11:08] davmor2, yup, known issue. no fix yet. sorry :( [11:08] gord: thanks :) [11:10] gord: is there a bug report for it do you know? [11:16] davmor2, i'm not aware of one [11:17] gord thanks :) [11:24] Is bug #604135 worth SRUing into Lucid? [11:24] Launchpad bug 604135 in mplayer (Ubuntu Lucid) "missing "Unsupported PixelFormat 10" fix patch" [Medium,Triaged] https://launchpad.net/bugs/604135 === smb is now known as smb-afk [11:27] tkamppeter: ok, got the speed up fixed and committed nwo [11:27] tkamppeter: for the epson drivers, the current debdiff still doesn't do anything to actually install the key, etc. [11:27] so we don't have any authentication at all [11:28] and installing that key isn't trivial either [11:32] pitti: Do you think bug #604135 should be SRUed? It is affecting everyone, though it occurs only with a certian type of file, and the fix is a single-line fix. [11:32] Launchpad bug 604135 in mplayer (Ubuntu Lucid) "missing "Unsupported PixelFormat 10" fix patch" [Medium,Triaged] https://launchpad.net/bugs/604135 [11:32] hey bilalakhtar, congratulations for joining the MOTU ranks! [11:32] pitti, i have an apport question ... [11:33] * bilalakhtar wonders how pitti came to know about his MOTU application [11:33] Thanks pitti ! [11:33] pitti, is it possible to somehow tell apport in the hooks to assign bugs to a different LP project (other than ubuntu) ? [11:33] bilalakhtar: SRU> seems fine, and the lucid task is already approved [11:33] bilalakhtar: I saw you getting added to ~motu :) [11:33] we'd need something like that for TI images [11:33] ogra: yes, it is [11:33] how ? i dont find it on the wikipage [11:33] ogra: ubuntuone-client already does exactly that to also support PPA builds [11:34] ah [11:34] ogra: some pointers: [11:34] yeah, its for a ppa [11:34] /usr/share/doc/apport/crashdb-conf.txt [11:34] /usr/share/doc/apport/package-hooks.txt.gz ("Customize the crash DB to use") [11:34] ubuntuone example: [11:34] - LP configuration: /etc/apport/crashdb.conf.d/ubuntuone-client-crashdb.conf [11:35] tsk, who would think to look in the shipped docs :P [11:35] /usr/share/apport/package-hooks/source_ubuntuone-client.py [11:35] ogra: yeah, it was an utter waste to write them :) [11:35] * ogra hugs pitti, thanks a lot :) [11:35] ogra: that hook does pretty much what you need, I think [11:35] if not apport.packaging.is_distro_package(report['Package'].split()[0]): [11:35] perfect, yeah, looks like [11:35] report['CrashDB'] = 'ubuntuone' [11:36] ogra: that means: "if the package is an Ubuntu native one, report it against Ubuntu, otherwise against the "ubuntuone" crash database [11:36] ogra: (i. e. a PPA version or local build) [11:36] yeah [11:36] ogra: the ubuntuone db is defined in untuone-client-crashdb.conf [11:46] pitti, so you have dropped the Epson thingy? [11:46] tkamppeter: s/dropped/not committed/ [11:46] tkamppeter: just followed up on the bug [11:46] I don't see an Epson specific hack which is significantly easier than just implementing the whole thing properly [11:47] and I don't think it's correct/okay to statically ship the Epson key in the Ubuntu keyring [11:47] we need to fetch the Epson key on demand and verify a trusted path to it [11:47] since it could change at any time [11:48] (which in this case means to fetch its fingerprint from the openprinting page and compare it) [11:48] pitti, so I have to tell Epson that we have no infrastructure to auto-download Epson driver, so best is a formal feature addition via UDS session? [11:49] pitti, I have hoped we get it in. For that I reported the bug already much earlier in the development period. [11:50] right, but as I said, I'm not on platform this cycle, so I didn't have time for it [11:50] and nobody else did it [11:56] pitti, did you not say after your first review on Monday that we restrict to Epson (what I did)? I also will advise Epson not to change the key for the time until Natty comes out (and we ship the real solution) and then we ship Epson's key with Maverick. [11:57] that's the problem with keys -- nobody wants to exchange them, but you have to if they get lost, or broken, or stolen [11:58] but we don't even have the code to import the current key yet [11:59] i. e. we need to get to know the key ID, fetch it from the mirrors, and run it by apt-key [11:59] pitti, could we perhaps SRU the package with the key in case Epson replaces it. [11:59] or hardcode the keyid, etc. [12:00] mvo: ^ is it possible/okay at all to ship third-party GPG keys into the default apt keyring? [12:00] mvo: e. g. if we want to support Epson printer drivers from openprinting.org? [12:00] The needed info about the key is here: [12:00] also, all this would need a FF at this point [12:01] https://linux.avasys.jp/drivers/lsb/epson-inkjet/key/fingerprint [12:01] pitti: that is possible, if we trust them enough to do that [12:01] This link is provided on all driver entry pages for the Epson drivers, like: [12:02] http://www.openprinting.org/driver/epson-ep-302/ [12:02] if the key needs to be exchanged we need to do a security update for the package [12:02] clicking on (Signed) at the download links (it is the same key for all packages). [12:04] mvo: what would happen if they replace it with a new key? I guess we can't tell apt right now "require a valid GPG key for this repository", so once the key changes, we'd go back to the simple warning mode, right? [12:04] once we start adding third-party keys in Jockey with apt-key, we'd need such a flag, I think [12:06] pitti: you can test that in the backend, there is a is_trusted property on the version [12:06] pitti: so jockey can just refuse to install packages that are unsinged [12:06] mvo, if i create a /usr/share/app-install/channels/maverick-ti-ppa.list (and eula), will that work for the new apturl implementation ? [12:06] mvo: ah, nice [12:07] pitti: you can also use /etc/apt/trusted.gpg.d/ to put keys in if you want to avoid using apt-key [12:07] ogra: it should [12:07] * ogra would like to just put a favorite .desktop on the TI images that enables the ppa and installs SW [12:07] mvo, how would it get the key ? [12:07] mvo: nice, just drop single .gpg keys there? [12:08] mvo: thanks, so it seems everything is there from the apt side then [12:08] pitti: yep [12:09] ogra: just add a mavreick-ti-ppa.key file [12:09] ogra: to the same package that ships the other stuff [12:09] If an SRU diverges away from Debian, I should use the version number -Xubuntu0.1 right? [12:09] where X is the debian version number [12:09] bilalakhtar: right [12:10] Thanks pitti ! [12:10] mvo, in /etc/apt/trusted.gpg.d/ ? [12:11] ogra: no, just alongside the .eula and .lsit files [12:11] ah, perfect [12:12] ogra: in etc it would be enabled by default, that is probably not what you want :) [12:12] well, it is :) [12:12] the TI specific images should have the TI ppa enabled anywa [12:12] y [12:12] ogra: oh, in this case, just drop it in the trusted.gpg.d and sources.list.d and don't bother with apturl [12:12] so it wont matter ... but its more elegant to have all files in one place [12:13] mvo, ti want a favorite .desktop file that holds the package list so i think i need apturl [12:13] s/ti/i/ [12:14] and i want a sexy way to show the TI eula :) [12:14] mvo, btw, thats just awesome ! [12:15] ogra: test it first, I'm not sure the eula is implemented in the new world order (but if not its trivial to add) [12:15] will do === MacSlow is now known as MacSlow|lunch [12:28] pitti, did mvo's help give us a solution for the Epson driver download? [12:30] tkamppeter: seems apt has all the building blocks that we need, yes; but the actual implementation of key retrieval, installation, and "is_trusted" checking still remains === al-maisan is now known as almaisan-away [12:58] pitti: Package cluster-glue is awaiting the queue for getting into -proposed. Looking at the queue, there are many old packages also there, so is there a need to ping a person from the SRU team to get the package in proposed? [12:59] bilalakhtar: no, it's mainly a matter for an SRU team person to make some time to review packages [12:59] pinging won't really help, I'm afraid [12:59] with the freeze being tomorrow, I guess everyone is busy with maverick until then [12:59] pitti: thanks [13:00] also, I was on vac last week, which didn't help SRUs either :) === dendrobates is now known as dendro-afk === MIH1406_ is now known as MIH1406 === MacSlow|lunch is now known as MacSlow === almaisan-away is now known as al-maisan [13:48] cking: ubuntu-security-sponsors unsubscribed === smb-afk is now known as smb [13:54] ari-tczew, thanks, sorry about that [13:54] cking: no problem, everyone can do mistake === ivoks-afk is now known as ivoks === ivoks is now known as ivoks-afk [14:51] apw, around ? === xfaf is now known as zul [14:52] smoser, hi [14:52] i'm really in need of some help on bug 606373 [14:52] Launchpad bug 606373 in linux (Ubuntu Maverick) "cloud-init output does not get to console when booted with pv-grub and ramdisk" [High,Confirmed] https://launchpad.net/bugs/606373 [14:52] i've gotten some second hand info from jjohansen on what we think the problem is and , thus, how we think we could work around it [14:53] but i've been unsuccessful in my attempts. [14:54] smoser, basically you lose the output at random i believe yes ? [14:55] well, in my experience random is "only early in boot" [14:55] you can see my init wrapper there [14:55] which would also make sense, if its the issue with the console right? [14:55] output to /dev/console just sometimes doesn't get there. [14:55] from upstart jobs right? [14:56] yes, from upstart jobs, but also reproduced in that little /sbin/init replacement (that then exec's upstart). [14:56] see the attachment there. [14:56] http://launchpadlibrarian.net/55625702/init-wrapper.txt [14:56] basically it just forks a process that keeps attempting to open and write to /dev/console every second [14:56] and then execs upstart [14:57] not all output from the forked process gets to the console. [14:57] smoser, so that forked process is opening and closing /dev/console repeatedly right (from a quick scan) [14:58] in the one i attached, i made sure to close all filehandles of the forked pid. but i've also tested without the closing of FDs (so that a handle on /dev/console would always be open) and got the same results. [14:58] apw, yes. [14:58] so that will definatly hit the issue [14:58] you should try something like this [14:58] #!/bin/bash [14:58] ( [14:59] sleep 120 ) & [14:59] sleep 1; exec real [14:59] and see if that sorts it out [14:59] i've basically tried that [14:59] you could also run your currnet debug as a third procerss to confirm it changes things if you get me [14:59] that was my first incantination [14:59] but in the existing one there, i tested without closing file descriptors [15:00] and the forked process, would then inherit stdio, stdin, stderr from the parent [15:00] and would, thus, keep a reference open [15:00] and the parent is connceted to console ? [15:00] you sure ? [15:00] thats why i am being explicit in opening the console [15:00] ramdisks exec /sbin/init /dev/console 2>&1 [15:00] additionally, I *do* get the "hello world" from the parent to the console [15:01] we get some output, then it goes away, then we get some more [15:01] well to avoid the race you have to keep it open [15:01] if its still going missing with a confirmed open then it may be a differnet bug [15:01] well i that forked process does not close it, then it is kept open [15:02] so if you imagine that script , but with the following line commented out [15:02] exec 1>&- ; exec 0<&-; exec 2>&-; [15:02] the example in there now does close them [15:02] then the original fd is still open [15:02] yes [15:02] right so the example there is useless for avoiding the issue [15:02] i tested last night with that commented out also [15:02] i can re-test that if you'd like [15:03] ok then next step ought to be to replace echo with a C program that records the real exit status of open etc and prints them to stderr [15:03] and retest ... we need to find out if open fails and if write fails and if close fails, and with what [15:03] for the one that goes missing [15:03] remembver to 2>>${out} [15:04] smoser, making sense ? [15:05] well, i also have python tests (cloud-init) that tried open() [15:05] and did never received failure [15:05] but i will try with C [15:05] ie, in cloud-init when it ran, i would loop over a try to open("/dev/console") and wait until it succeeded [15:05] but i never saw failures [15:05] well i care not what you test with, but in that context where we see 1 2 4 i want to know if userspace was told there was an issue [15:05] and i lost output [15:06] right. [15:06] so python was not [15:06] smoser, this is all in ec2 isn't it? [15:06] or kvm ? [15:06] i can probably reproduce in a vm [15:06] would you like me to try that ? [15:06] nope, i want to know where you are testing: "Where is this testing occuring?" [15:06] actually, yeah, thats obviously important [15:06] as they have different /dev/consoel implementations [15:07] what i'm reporting is in ec2 [15:07] yes [15:07] so we have no real idea if we sent the data out or not [15:07] and ec2 is somewhat nebulous [15:07] * apw has a look if we could log in the kernel [15:13] has python-aptdaemon's api changed since lucid? [15:14] smoser, what device is console on in ec2? [15:14] smoser, and have you ever had a report of this outside ec2? [15:15] i'm testing on eucalyptus (kvm) now. i dont recall having seen it outside ec2. [15:15] console on ec2 is /dev/console, but i believe our kernel is patched so that hvc0 == /dev/console [15:16] Doesn't EC2 pass console=/dev/ttyS0 ? [15:16] no. eucalyptus does [15:16] Or am I confused? [15:16] i can check that, but i dont think so. [15:16] we boot with pv-grub now, and our command line does not have that. [15:16] but we specify it [15:17] smoser, what does cat /proc/cmdline say [15:18] apw, we started seeing it reproducibly when 2 things changed. a.) ramdisk b.) using pv-grub as the loader rather then xen loading the kernel. [15:18] smoser, so ... a lot has changed [15:18] and didn't you change kernels then too? [15:18] yes. [15:19] lots have changed. we changed from a 'linux-ec2' to a -virtual kernel with pvops also [15:20] right so basicall we threw out the bathwater, baby, bath, and the house ... so it could be anything [15:20] so which console driver does it use in this mode# [15:20] the console is always been the xen console [15:20] /dev/hvc0 [15:21] ok .... [15:21] but no console= command line is passed [15:21] i am sure that /dev/hcv0 has changed between the kernels in quesion [15:21] i wonder if we can log what is trying to go out via it in dmesg so you can see if its getting that far [15:21] lucid command line: root=/dev/sda1 ro 4 [15:22] maverick command line: root=LABEL=uec-rootfs ro [15:23] we can control the maverick command line [15:23] smoser, so you use -virtual yes ? [15:23] we could not control it in lucid [15:23] lucid uname: 2.6.32-308-ec2 [15:23] maverick uname: 2.6.35-21-virtual [15:33] smoser, so i think i could log everything sent out via the console say at debug level [15:33] else it would be recursive of course [15:33] which woudl get to syslog ? [15:33] yeah it should i think [15:33] hm. [15:34] but that might not benefit us [15:34] as syslog isn't going to be up until upstart starts it [15:34] oh [15:34] but there is that buffer for syslog [15:34] right ? [15:34] yeah, it'd be in dmesg [15:34] that would be useful i think [15:34] so we could use that to try and work out if its gets that low or not [15:34] of course i have no way to debug it [15:34] ie to test it before hang [15:34] hand === njpatel_ is now known as njpatel [15:36] soren: ah, the networking job; yes, that could cause a problem, indeed === bjf[afk] is now known as bjf === ara_ is now known as ara [15:43] apw, ok, so: http://paste.ubuntu.com/494225/ is console output (the most recent boot) with /sbin/init of http://pastebin.com/q7kE2bbf [15:43] slangasek: Ok, so if I want a bridge, br0, with a single attached interface, eth0, what's the correct configuration? Do I have an "iface eth0" stanza at all or do I just have an "iface br0" stanza with bridge_ports eth0? What about "auto br0" or "auto eth0"? [15:43] for 6 seconds, output to stdout of that forked process went no where. [15:44] it went to console, then disappeared for 6 seconds, then returned. === dendro-afk is now known as dendrobates === deryck is now known as deryck[lunch] [16:06] cjwatson, Keybuk, does plymouth do anything clever with console output while it is on the screen ? === rgreening_ is now known as rgreening [16:07] apw: lots [16:07] it takes it and buffers it, and logs it, and redirects it [16:07] and sometimes adds salt [16:07] Keybuk, as in /dev/console output ? [16:08] and if so, how is it getting in the stream ? [16:10] ioctl [16:11] urgle so we have a period during boot on ec2 of about 6 seconds around when mountall says its running where there is a gap in console output [16:11] Keybuk, ^^ might that be expected behaviour with plymouth around [16:12] err. not sure [16:12] I don't think so [16:12] does it go into /var/log/boot.log ? [16:12] smoser, ^^ ? [16:13] slangasek, howdy!! I talked to upstream about the soname changes in pacemaker, and well he pretty much told me that they are not guaranteed to change, because they will, but that doesn't happen very often (as in bumping versions) [16:13] looking [16:13] awesome [16:13] the lost data (and only the lost data) is in /var/log/boot.log [16:14] Keybuk, so does that mean that plymouth was running during that period ? [16:14] Isure [16:15] Keybuk, do we have any control over whether plymouth repeats its input to the real console, or is it gone while plymouth runs [16:15] gah wish i understood plymouth better [16:16] yes, plymouth plugins dictate which does what [16:16] plymouth's details plugin is supposed to repeat things to the real console [16:16] (src/plugins/splash/details/plugin.c) [16:16] smoser, is your missin init script output in there? [16:17] as well as the debug? [16:17] it may not display anything if it thinks it's waiting for the answer to a question [16:17] apw, yes. [16:17] its all there. [16:18] cjwatson, where would i see an indication that plymouth would be waiting for an answer to a question ? [16:18] Hey guys. Can someone confirm the white screen that I get after logging in in uptodate Maverick Netbook? I cant use it anymore. Update on way? [16:18] filesystem will be clean (pristine image boot) [16:19] smoser: if it were, it ought to be the last visible line on the console [16:19] i can't think of any questions it migth be asking though it might be offering cancel for fsck's i guess ? for the shortest time [16:19] not htere. [16:19] Wubbbi: you're not the first person to report that today, but I don't do any netbook work myself so I know no more than that [16:19] not there. [16:19] and anyhow we lose it for 6 seconds which sounds likely to be 'all' of the time plymouth is active during a boot ? [16:20] peraps the repeating just isn't working, disabled perhaps [16:20] Hmmm ... ok. But you must understand, that I cant use my Netbook now anymore. Well I can go to init 3 and do updates but no working. Well I know its Beta. I just wanted to tell you that this is a emergancy issue! :) [16:21] ubuntu just got first spam blueprint [16:21] https://blueprints.edge.launchpad.net/ubuntu/+spec/new-background-ubuntu [16:23] apw, i did sudo sh -c 'for x in /etc/plymouth*.conf; do mv $x $x.disabled; done' [16:23] then reboot [16:23] http://paste.ubuntu.com/494238/ [16:23] the console log now has everything [16:23] zyga, we have a ton of spam blueprints already [16:23] zyga: That’s not spam, it’s just trolling. [16:23] * zyga didn't know [16:24] smoser, i think that points squarly at plymouth then, especially as it itself logs the missing data as well [16:24] i think so too :) [16:24] Wubbbi, fingers are being point at a mesa update [16:24] Wubbbi, see discussion on #ubuntu-x [16:27]