[00:00] slangasek: tell me about it [00:01] status should exit non-zero if the job isn't running [00:02] I think my notes say that it should even exit non-zero if job is starting or stopping - but different non-zero to "not running at all" [00:02] Keybuk: excellent, you've saved me an email [00:03] Can you fix it for Lucid? [00:03] huh [00:03] if slangasek lets me ;P [00:04] oh, I see - it got lost in the move to using D-Bus Properties [00:05] Keybuk: I thought service had a few exit 0's in places as well [00:06] Keybuk: perfectly fine [00:06] Keybuk: now, can you tell me why plymouth now falls on its face in the initramfs looking for /proc/cmdline, when it didn't before? :) [00:10] hmm; maybe that's not the reason it's falling over [00:10] apparently break=bottom is too late to test, because /proc has already been unmounted again by that point :P === rmcbride__ is now known as rmcbride [00:11] cjwatson, using the previous installer (the one that actually supports hard drives), we're now failing to set up encryption when the crypto partman method is used. Is that known? I don't find a bug for it. [00:12] Partitions get created, but there's no LUKS header. [00:12] jbebel: is that the bug that was in the beta1 release notes about LVM+encryption? [00:13] That's a different bug, I think. We were seeing that one, and this is substantially different. [00:13] Keybuk: aha, got it - --attach-to-session doesn't work without /dev/pts :P [00:14] with the release notes bug, partitioning, LUKS, LVM, and the root filesystem were setup, just swap wasn't created. now, we aren't even making it past LUKS. [00:14] hmm, ok [00:18] slangasek: which is why I patched initramfs-tools to mount it ;-) [00:18] Keybuk: ah, but without a versioned dep [00:18] it doesn't break it [00:18] right, I'll grab that then [00:18] it just means you get console splurge [00:18] hm [00:19] (the parent exits 69, but it seems that the child carries on regardless) [00:19] quickly can be used for C/C++ ? [00:19] Keybuk: actually, after plymouth fails to start in the initramfs, it *also* fails to start in the root fs; haven't diagnosed that yet to see if it's the same cause [00:20] and since I was testing post-initramfs passphrase prompting at the time, I had a right mess [00:22] the post-initramfs failures may just be unhappiness with my /usr-as-separate-partition === rgreening_ is now known as rgreening [01:12] Keybuk: ah, and after upgrading initramfs-tools, can't reproduce the failure of the plymouth job post-initramfs. [01:12] so I guess things are working :) [01:23] http://news.opensuse.org/2010/03/25/opensuse-11-3-milestone-4-release/ [01:23] THE APOCALYPSE HAS COME! :D [01:31] Keybuk: congratulations, your vga16fb renderer has been reported as a bug. :-) [01:31] "My $1,000 nVidia card should be able to do more than 16 colors" ? [01:32] yep [01:33] though it would be nice to have a crisper logo on vga16fb, that's certainly not the renderer's fault [01:33] right, Design were supposed to have furnished us with one long ago [01:33] we made them aware of the need for it from the very beginning [02:09] Hello, could be automake 1.11 upgraded to 1.11.1 ? Automake 1.11 are known to be suffering from critical security issues [02:09] https://bugs.launchpad.net/ubuntu/+source/automake1.11/+bug/526035 [02:09] Ubuntu bug 526035 in automake1.11 "Upgrade package version to 1.11.1" [Undecided,Fix released] [02:10] the request is for karmic, lucid already have the 1.11.1 version [02:10] should I file a new bug? [02:14] jjardon: given that the justification for an update in karmic is a security issue, you should talk to the Ubuntu Security Team, who are already subscribed to the bug; I've added a new bug task for karmic on that bug [02:15] slangasek, thanks a lot [02:30] Le sigh, an apparmor update broke the system again. === snow___b is now known as ls === ls is now known as Guest62552 [04:05] hi [07:19] <_minerva> anyone who would be interested in mentoring "truely system wide proxy" for gsoc [07:26] <_minerva> anyone who would be interested in mentoring "truely system wide proxy" project for gsoc !! [07:33] _minerva: It's either Friday evening or Saturday for everyone now; it's not a good time for finding people online :) [07:40] <_minerva> RAOF: k thanks anyway [11:11] ion: can you file a bug? === xomas is now known as xomas_ === xomas_ is now known as xomas [11:23] jdstrand: Bug #458299 [11:23] Launchpad bug 458299 in linux "apparmor_parser: page allocation failure. order:5" [Medium,Confirmed] https://launchpad.net/bugs/458299 [11:23] ion: thanks === xomas is now known as xomas_ === xomas_ is now known as xomas [13:29] ArneGoetje: what's going to happen to the branches in Bug #46318 - I'll try to get them from the sponsors' list [13:29] Launchpad bug 46318 in tutos2 "Change dependency from postgresql to postgresql-client" [Medium,Fix released] https://launchpad.net/bugs/46318 [13:42] hey, are there any amd64 builds of UNR planned for lucid? (or lucid+1) [13:42] gilir: just looking at bug #523433. how about deferring that to lucid + 1 and then making a backport for lucid? [13:43] Launchpad bug 523433 in ubuntu "[need-packaging] [FFe] pcmanfm2" [Wishlist,New] https://launchpad.net/bugs/523433 [13:43] yeah it'd be good if were amd64 builds because the new N450 atom processor is 64bit [13:44] it's in the MSI Wind series atm http://www.msi.com/index.php?func=prodpage2&maincat_no=135&cat2_no=582 other vendors will follow [13:44] what are the benefits of amd64 on netbooks anyway? [13:45] i would have figured it was worthwhile if the chip supported it. [13:46] http://ark.intel.com/Product.aspx?id=42503 :P [13:54] slangasek: plymouth-set-default-theme went missing in the last plymouth upload, was that intentional? [13:54] *latest [13:55] there seems to be plenty of mess with plymouth nowadays [13:56] sistpoty, there is incompatible changes in pcmanfm2, if you use a backport version, you need also changes in others packages [13:57] sistpoty, it will also be less easy to switch for v1 to v2, as the backport will override the previous one automaticly if you are using backports [14:09] slangasek: nevermind, seems like some theme packages have not migrated [14:13] gilir: what needs to be changed in other packages? why would the backport override the previous one? === dendro-afk is now known as dendrobates [14:30] can anybody review SRU? bug 421684 [14:30] Launchpad bug 421684 in obexd "bluetooth send malformed files " [Undecided,Confirmed] https://launchpad.net/bugs/421684 === ls_a is now known as snow_ru [14:54] hello, how do I specify in my Makefile an "Input file with spaces.c" in gnu make? [15:00] otro_viajero7: escape the space with \ ... not too sure how well make handles spaces though (I think I read that there are limitations, but can't find it right now) [15:01] I tried that, but it does recognize it as two files [15:03] otro_viajero7: that works for me: http://paste.ubuntu.com/402439/ [15:04] otro_viajero7: however you won't be able to use $^ then, obviously [15:11] thanks sistpoty ;) [15:11] yw [15:12] sistpoty, because for lucid +1, it will stay as pcmanfm, there is no need to keep a pcmanfm2 after lucid [15:13] gilir: ah, I see, thanks [15:51] kenvandine, ping? [15:53] I need to know exactly how compiz is started on ubuntu === yofel_ is now known as yofel === korn_ is now known as c_korn === jldugger is now known as pwnguin === ember_ is now known as ember [17:23] Ahoi. Already talked to #virt about this, and no ideas. Ubuntu 10.04 Beta or 9.10, most recent kvm/libvirt available for either. Linux guests get ~20MBps disk throughput, windows xp guests get <3MBps at best. Tested both guests with all possible img types, preallocated. [17:24] I can push >40MBps to the linux guests dev/shm, but only 20MB to disk. the host disk is capable of 170MBps [17:24] the host disk is ext4 on lvm, on top of mdraid5 10 disks. [17:24] When I put the guest image in /dev/shm instead, I get proper performance. [17:25] Can't find any reference to this problem on the intarwebs. [17:25] Ideas? [17:26] (p.s. install time for a tinyxp guest (<300MB) was >10 hours with the guest image on the raid. <5 minutes on shm. [18:13] should do we update-maintainer in SRU? [18:21] ari-tczew: No. Minimal diff. [18:21] thanks [19:19] cjwatson, I am working on that libparted code and I'm not sure if it is throwing the correct type of warning because gparted seems to happily ignore it [19:24] ScottK: so we (Ubuntu) need to update the Maintainer when modifying packages in the development release, but can "skip" it in SRUs? [19:25] geser: That's my understanding. SRU is supposed to be a minimal diff. Changing maintainer isn't actually needed for the SRU, so I'd call it not minimal. [19:25] I could certainly be wrong. [19:27] I would have excepted that we need to update the maintainer in SRUs too (especially as it is risk-free). But I could be wrong too. [19:28] I remember that we didn't do it for SRUs in some older release before we started to systematically update the Maintainer field. [19:32] men, please specify a consensus [19:35] I must say, I [19:35] 've generally updated Maintainer in SRUs [19:36] but I can see the argument for not doing so; I don [19:36] 't think it matters either way [19:36] Clearly don't do it for a Dapper SRU. [19:36] I'm not sure either. I'm also not on the SRU team. [19:37] (sorry, ' is symbol-shift-m on the N900, while ctrl-m of course generates CR, and I keep missing) [19:39] okay, but if I made update-maintainer on lucid for package from lucid-1 and older is it OK? [19:42] men, please answer, I don't have a lot of time [19:42] * sistpoty thinks a change of the maintainer value doesn't effect the value of an SRU, so it's safe to do it [19:43] sistpoty: but not necessary right? [19:43] ari-tczew: if anything else is fine, changing maintainer or not can be done by the uploader, whatever the best practice is. [19:43] ari-tczew: nobody will argue if you omit the change; people might argue if you include the change [19:43] so it seems clear that if you are in doubt then there is a safe option [19:44] ok [19:44] ari-tczew: also, "men" sounds weird as a way to address a group like this (even leaving aside questions of sexism); I'd suggest not using that form [19:45] (might be lost in translation... good movie btw :)) [19:45] cjwatson, so have you any idea why gparted seems to happily ignore libparted warnings when it can't sync the partition table? from your comments on bug #540940 I got the feeling you are more familiar with it than I [19:45] Launchpad bug 540940 in parted "Regression: Unable to add a partition to a disk that has another partition in use" [High,In progress] https://launchpad.net/bugs/540940 [19:46] cjwatson: okay, so s/men/dear developers [19:46] psusi: can't look today - but it could well just be catching the exception and ignoring it? [19:47] psusi: can't look today - but it could well just be catching the exception and ignoring it? [19:47] psusi: gparted didn't inspire much confidence in me when I last looked at it, though at least most of the partitioning logic is still left to libparted [19:47] cjwatson, that's what it seems to do... but I'm wondering why... it seems it ignores the warning, then judges that everything seems ok, and continues [19:48] I stopped using it in ubiquity for several good reasons :) [19:48] anyway, got to put my daughter to bed, later [19:48] I'm also confused about extended partition handling... I swear that if you had primary slot 4 used for the extended partition, the kernel did not make a /dev/sda4, it just skipped straight to 5 and on for any logical partitions in the extended [19:49] but now it seems it makes /dev/sda4 with a size of 2... it maps the pseudo mbr and the next sector for some reason === radoe_ is now known as radoe [19:53] cjwatson, n900 ? [19:53] welcome to the club :) [19:56] psusi: yes, that's what I recall for extended partitions [19:57] psusi: actuall it still seems to be true for me with 2.6.32-16-generic #25 [19:58] +y [19:58] (amd64) [20:05] sistpoty, you sure? because for me I get a dev node for the extended partition of size 2 [20:09] psusi: that's what I get: http://paste.ubuntu.com/402553/ [20:12] psusi: so indeed, there seem to be devices for extended partions (not sure if that changed though), which contain the header as expected [20:13] psusi: it's certainly what I remember, although I don't know whether it's always been that way. It seems moderately useful for things like installing a boot loader to the EBR [20:14] psusi: /dev/sda3 doesn't have size 2 though: http://paste.ubuntu.com/402556/ [20:14] not maybe the most useful thing ever, but not useless either [20:15] ogra_cmpc: yeah, it's a pretty nice device [20:16] been meaning to blog first impressions [20:16] yep, i'm in love with it since i got mine [20:16] yep, makes inspecting a partion easier (and yes, I did write a program to look for partition header once, since I was an idiot who deleted a partition) [20:16] getting a bit late possibly :) [20:17] the keyboard isn't quite perfect, and there are a few annoying bugs, but it beats the hell out of S60 [20:17] and it seems competitive with Android - haven't any direct iPhone experience so can't say there [20:17] definately, to sad that maemo is dead though, imho it was a bad decision to drop it [20:17] mm [20:18] meego simply will take a while to get into such a state [20:18] I'm sort of reserving judgement until I see how meego turns out, though dropping the .deb format is a shame [20:18] yeah [20:18] yeah, switching technologies is going to suck [20:19] well, we have omap images since today ... people can start proting to it ;) [20:19] *porting [20:19] but at least meego will work (to some extent) on the n900, so we won't have to get new devices [20:20] I need to start developing for it in some way [20:20] at the very least fix the annoying xterm enter bug [20:20] anyway, OT I suppose :) [20:20] oh, btw, ppc d-i didnt find anna after my upload it seems (/me didnt have time to debug that yet) [20:20] grr, that might be a recurring buildd bug [20:20] lamont fixed that ... [20:21] is there a permission error on sources.list in the log? [20:21] i'll ping him on monday and will give it back (if no other upload happened) [20:22] hmm, i didnt notice one but i scrolled directly to the error msg [20:22] if so, don't just give it back, it needs a launchpad-buildd (re)fix [20:22] it was a consequence of upgrading the powerpc buildds to karmic [20:22] ah [20:24] cjwatson: which buildd? [20:24] cjwatson: monday I plan to roll a new lp-buildd, there's some dogfood testing first, then we'll blat it to the world [20:26] lamont: adare [20:26] cjwatson: Hello [20:27] cjwatson: Doest the code keep changing from new releases of Ubuntu ? [20:27] cjwatson: best way to find the umask of a running process? [20:27] kusum: of course; which code in particular? [20:28] GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH [20:28] fixored [20:28] i am sorry [20:28] when one edits the init.d, one should restart the service. [20:28] lamont: um, not sure, suppose it's somewhere in /proc but I can't check right now [20:28] lamont: ah :) thanks [20:28] i forgot to mention partman-auto-loop code [20:28] no worries - process older than init.d [20:28] so adare is fixed [20:28] giveback left as an exercise [20:29] kusum: hasn't changed a huge amount, but sure, it's changed [20:29] cjwatson: what are .nsh files ? [20:29] i did not really find useful info about them [20:30] something windowsy. I don't write Windows code so I don't know [20:30] ok [20:30] cjwatson: it is for ui code in windows ? [20:31] lamont: btw, did you reschedule ghc6 on armel? I'm a bit worried if it does make any process, though Laney is certainly more competent to tell this [20:32] lamont: (it seems to not progress since a few days, but as I wrote, Laney is the better person to ask) [20:32] kusum: I said I don't know :) [20:34] sistpoty: the jaboticaba build? yeah, I'm ignoring that on the grounds that it'll be interesting to see if it finishes before release [20:34] it's known/expected to not make progress. [20:34] OTOH, armel is keeping up just fine these days, so tying up jaboticaba to find out isn't really hurting anything. ergo, meh. [20:34] cjwatson: thanks for the information [20:37] kusum: did you try googling for "windows nsh"? links related to nsis should be relevant [20:37] * lamont wanders off to break networking [20:38] cjwatson: i finally understood when i googled "compile nsh files" [20:38] i was thinking nsis was wrong link [20:38] got it now :) [20:41] hi [20:41] tjaalton: yes, it's intentional that it's gone missing, theme packages need to use update-alternatives now instead [20:41] i have made a useful bash script I call "ubuntu experience". you can run it from within gnome, to add that unique ubuntu touch to your desktop windows. http://pastebin.com/DafZTLuk [20:44] (Yes its a joke, forgive me. i couldnt help myself). [20:50] cjwatson: thank you [20:57] kusum: you're welcome [21:08] sistpoty, what does cat /sys/block/sda/sda3/size say? [21:09] please review SRU bug 262235 [21:09] Launchpad bug 262235 in clutter "Does not work on 64bit properly" [Unknown,Fix released] https://launchpad.net/bugs/262235 [21:11] psusi: 2 [21:12] psusi: is that in blocks? then 2 would make perfect sense for an extended partition, I guess [21:12] sistpoty, yea... I think so... what's it map the second sector for? [21:13] I and I swear the kernel used to just not map them.... if you only had a extended partition you got sda5 and that was it... no 1-4... seems odd to map the extended container [21:15] psusi: not too sure, I admit that I don't recall the format for an extended header, but I think that I recall that it was two blocks (which you really shouldn't take for granted) [21:15] sistpoty, I noticed this because I had an error while testing my fix to parted... tried to create a logical partition starting at the start address of the extended+1... parted thinks it should work and tries, and the kernel rejects the addpart since it overlaps the second sector mapped by the extended partition [21:15] sistpoty, I thought it was just another pseudo mbr so should only be 1 block [21:16] psusi: there must be documentation somewhere to prove that speculation (both yours and mine :)) [21:18] hrm... seems fdisk doesn't want to start the logical partition for 63 sectors into the extended [21:19] psusi: crap, thought that I might help you but reading the wiki article shows that I really don't recall any details, sorry (http://en.wikipedia.org/wiki/Extended_partition) [21:20] oh weird... if I turn off the dos compat flag, fdisk won't start the logical until sector 2111 [21:24] hrm... yea, it should only be one sector [21:24] though due to customary cylinder alignment, typically has 62 unused sectors following it before the logical partition [21:24] psusi: When I dd my extended partition, I only get 1024b. [21:25] psusi: If it remember right. [21:25] arand, right... 2 sectors [21:25] I'm wondering first, why the extended has a dev node at all, I swear this did not used to be the case, and secondly, why it is 2 sectors long [21:26] when you put parted in sector mode it seems to think you can create the logical partition on the very next sector, but the kernel doesn't like it [21:26] psusi: I'm quite happy it has, since my main bootrecord is on there :) [21:26] what do you mean? [21:27] extended boot records are not bootable [21:28] psusi: I have my main mbr (vbr) residing in that 1024 space, yes. [21:29] arand, that doesn't make sense... by definition the mbr is sector 0 [21:29] psusi: Well, actually my proper mbr picks up which start key I press and delegate to either sda1 or sda4. [21:30] and sda4 is an extended partition? weird... what boot loader is this? [21:34] psusi: The one on the mbr-proper is some Dell mediadirect thingy ref. http://digiwanderlust.blogspot.com/2008/04/dual-boot-boot-linux-using-dell-media.html, on the extended vbr I have a 466b grub bit I dd:d over from a logical partitions vbr (since grub2 wasn't happy about installing to the extended's bootrecord). [21:35] hrm.... yea, and when I use parted to create several logical partitions, they start on the sector immediately following the ebr.... no second sector unused... [21:37] arand, ack... so you're using blocklists ;) [21:41] join #hackus [21:41] oops [21:44] damnit.... hw_sector_size and optimal_io_size in /sys/block/sdd/queue are not writable.... [21:53] nice to see that the kernel does not respect the hidden flag on gpt partitions [22:06] psusi: imo, none of this extended partition stuff should block your patch; if it's a problem, it isn't a new one [22:15] cjohnston, agreed... just cleaning it up now... think I have it working pretty good now [22:31] When might I expect linux 2.6.32-18.27 to get built/uploaded? [22:33] assuming it allows us to test Lucid installs again. [22:36] Also, I suppose a new d-i will need to be built too. [22:42] jbebel: the new linux debs are in the NEW queue and waiting on an archive admin looking at them. if they don't get a special treatment on this weekend, they should get accepted during the week (probably on monday) [22:48] When 10.04 is released, is it recommended to do a fresh install, or will updating be enough? [22:49] Upgrading should be fine. [22:51] Alright, thanks. [22:54] jbebel: um, didn't this morning's d-i build fix the missing modules already? [22:54] cjwatson, it doesn't appear to have. [22:55] well, can't look now ... [22:55] it's still using -17 and doesn't have sata modules. [22:55] I was going to take a closer look at why drive encryption was failing, but without drives that's a bit more difficult. [22:56] oh, for goodness' sake, I didn't realise they were going to bump abi and obviously ogra didn't check ... [22:56] no, i didnt [22:57] * cjwatson pulls out the laptop then [22:57] i would have noticed if the meta had hit ml laptop during the upgrade this morning but thats obviously still in new [22:57] s/ml/my/ [22:57] ups, sorry; smb had mentioned there'd be NEW processing, didn't realize that hadn't been communicated [22:57] sorry for that [22:58] oh well, I'll sort it out now [22:58] jbebel: thanks for the note [22:59] cjwatson, np [23:00] how about having a plymouth-i-want-a-pretty-boot package that forces plymouth into the initrd? :) [23:00] I'll just upload d-i in advance, it can dep-wait or whatever if it likes [23:01] cjwatson, do you think this new d-i and/or kernel has any chance of fixing drive encryption? I haven't gotten far figuring out what's wrong yet. [23:01] no. [23:01] well probably not [23:01] d-i's just the core, the initrd doesn't contain partitioning code [23:01] I filed a bug with partman-auto-crypto, but I'm thinking that was the wrong place. [23:02] Sarvatt: does it need to be a package? It's a one-line change to /etc/initramfs-tools/conf.d/ [23:02] jbebel: it'll do [23:03] jbebel: I prefer not to waste time reassigning between packages until I've actually analysed it; any vaguely plausible installer package is fien [23:03] *fine [23:03] fair enough. [23:04] just thinking about user friendlyness for that change even though it is easy to do and it is a common complaint :) guess it'd be more appropriate for something like ubuntu-tweak [23:05] jbebel: the race with swap creation is top of my list right now; if that doesn't turn out to fix your problem too, I'll look at it after that [23:05] Right now we're not even making it to the swap creation step though. I suspect you'll find the same thing. [23:05] I just mean that I want to debug one thing at a time. :-) [23:06] Sure. :) [23:06] races in this sort of area sometimes have multiple consequences, so we'll see [23:06] I kind of doubt that this is specific to swap creation, but I haven't narrowed it down yet [23:06] just worked through a problem where someone wasnt getting a splash for almost 30 seconds into the boot with this fstab setup - http://pastebin.com/tYgACis9 would adding nobootwait to one of those partitions fix that? [23:06] I can't even set up encrypted partitions manually anymore. [23:07] Sarvatt: many perfectly normal situations in lucid result in not having a splash for that sort of length of time; it may not be fixed for lucid [23:07] I wouldn't advise mucking with fstab to try to influence that === tkamppeter_ is now known as tkamppeter [23:08] the problem is a conflict between boot performance and boot experience, that needs non-trivial work to resolve [23:09] on hard disks, the most efficient way to boot is to run ureadahead to load everything, *and do nothing else while it's running* [23:09] yeah thats why I was suggesting maybe we should have a package people can install that puts plymouth in the initrd with OPTION=FRAMEBUFFER=Y without requiring manual editing [23:09] any disk activity at all will spoil its seek pattern and ultimately slow things dodwn [23:09] down [23:09] but it turns out that getting the splash up before that involves bottlenecking on waiting for the graphics drivers to initialise [23:10] Sarvatt: I assumed you didn't understand the problem because you were talking about fiddling with fstab :-) [23:10] therefore I thought an explanation might be worthwhile [23:11] though you were talking about efifb the other day so I assume you've looked into it ... [23:12] Sarvatt, did you actually make that user create a bootchart ? [23:12] might be an issue with dmraid or some such [23:16] ah ok, it looked like it was waiting for everything in this guys custom fstab to be ready before continuing because / was ready pretty early into the boot which is why I asked that. it wasn't loading gpu modules until after everything was mounted because they weren't in the initrd and packing in plymouth fixed that [23:18] I might be wrong, but I don't think it should wait for filesystems to be up [23:19] plymouth starts on starting mountall, and plymouth-splash starts on started plymouth and (your primary graphics device appeared, or other stuff) [23:20] right [23:21] I'm not actually sure what forces ureadahead to be serialised ahead of that, although my understanding is that it is [23:23] the usual problems we see are 1) ureadahead takes so long that the user is sitting at a blank screen for 30s or more before mountall actually starts mounting anything, or 2) the single-partition SSD install is so fast that gdm is ready to start as soon as udev has announced the video device [23:23] cjwatson: actually, I don't think anything *does* force it to be serialized; I think we may have just found a bug [23:24] it may be a bug we don't currently hit because upstart always walks /etc/init in the same order [23:24] but I don't think we're meant to rely on that [23:28] reverse alphabetical order? :) [23:30] cjwatson, I could be wrong, but I think the end-of-disk gap for md is what broke crypto somehow. [23:31] jbebel: seems odd, why would that make any difference? [23:31] it gets a fractionally smaller container, that's all, surely? [23:32] I agree, but it stopped working for us just about with that release of partman-base [23:32] I think I'd rather analyse first [23:32] Sure [23:34] oh... Hmm. It might have been something else in 139. I forgot that our mirrors got a bit behind. [23:34] it would be good if you could attach syslog as well as partman [23:35] jbebel: I fixed the bit about /boot landing at the end of the disk, BTW, I just haven't uploaded that yet [23:35] Ah. Excellent! [23:35] cjwatson: actually, since ureadahead itself doesn't block, /alphabetical/ order would be the one that gives better performance by starting plymouthd first instead of starting it while ureadahead is in the middle of running :) [23:36] partman-auto-lvm 33ubuntu3 will clear that up === xomas is now known as xomas_ === xomas_ is now known as xomas [23:36] slangasek: right, but I mean right now doesn't upstart block due to the 'expect fork' trick in ureadahead before it gets round to starting plymouth? [23:37] cjwatson: oh, I don't know - I was going by the comment in the job, which says "Forks into the background both when reading from disk and [...]" [23:38] maybe this all works the way it's supposed to, but if so it's sorely underdocumented :) [23:38] nih_dir_walk_scan sorts the list of filenames [23:39] I imagine it then inserts them into a linked list such that the last one ends up run first, or something [23:39] but haven't bothered to check that [23:39] * slangasek wonders if someone can decipher what's really going on in bug #541700, given that the submitter's statements are not credible :/ (aubergine screen with no ubuntu theme installed) [23:39] Launchpad bug 541700 in plymouth "plymouth: blank/unanimated screen at boot (cat /proc/fb: 0 VGA16 VGA)" [Undecided,New] https://launchpad.net/bugs/541700 [23:40] We did get bitten by suddenly needing to include partman/confirm_nooverwrite in the preseed after 139. That should probably be added to the example-preseed in the installation guide. [23:40] oh, yeah, I meant to do that [23:41] kickseed too [23:41] I thought about that and everything and forgot. Sorry [23:41] It's fine for us. I figured it out. :) [23:42] I can file a bug to add it to the manual if that would help. [23:43] no need, already committed a fix [23:44] and upstream [23:45] partman-base 139ubuntu1 is even less likely to have caused this; the core changes there were minimal compared to 138ubuntu4 [23:45] 138ubuntu3 and 138ubuntu4 were big changes [23:46] in fact all the 138ubuntu* series [23:48] Maybe our mirrors were more behind than I thought.