[00:55] ubiquity: cjwatson * r3538 ubiquity/ (debian/changelog partman/check.d/partition_too_small): [00:55] ubiquity: Skip partition_too_small check during Wubi installs, as Wubi does some [00:55] ubiquity: of its own checks and the delay imposed by this check looks particularly [00:55] ubiquity: weird in Wubi. This may or may not be the cause of apparent hangs [00:55] ubiquity: towards the end of partitioning, but I suspect that it will at least get [00:55] ubiquity: rid of some conflated reports and make testing quicker. [01:07] ubiquity: cjwatson * r3539 ubiquity/ (155 files in 3 dirs): Update translations from Launchpad. [01:20] ubiquity: cjwatson * r3540 ubiquity/ (d-i/manifest debian/changelog): [01:20] ubiquity: Automatic update of included source packages: clock-setup 0.98ubuntu3, [01:20] ubiquity: flash-kernel 2.13ubuntu13, grub-installer 1.43ubuntu6, partman-auto [01:20] ubiquity: 89ubuntu2, partman-target 64ubuntu4. [01:43] ubiquity: cjwatson * r3541 ubiquity/debian/changelog: releasing version 2.0.1 === NCommander is now known as NC|Mobile === NC|Mobile is now known as NCommander [10:08] cjwatson, for your entertainment :) https://wiki.ubuntu.com/ARM/BabbageHeadlessKarmicDesktopInstall [10:12] nice [10:21] cjwatson in /bin/partman I have that PARTMAN_NO_COMMIT=1 [10:21] not sure where that is set, but that makes partman exit, is that normal? [10:22] ps mounting /host probably is orthogonal, was some spurious reboot-makes-it-work thing [10:23] have to go, hope the above helps [10:24] evand ^ [10:25] sigh, I can't conduct a conversation when people join and quit like that :-/ [10:33] cjwatson, i see bug 360925 returning on the imx51 vfat alternate images, intrestingly i can rename the file on the mounted vfat image from d-i's shell [10:33] Launchpad bug 360925 in mobile-meta "md5sum check of UNR image fails in one file" [Undecided,Invalid] https://launchpad.net/bugs/360925 [10:35] cjwatson, which makes me think we miss something at image build time here [10:52] cjwatson: Looks like the hang with formatting filesystems using parted_server is another weird powerpc gcc bug. I am just double checking, but it seems if I build parted_server/partman-base with -O2 for powerpc instead of -Os, thigns work fine. [10:53] aha [10:53] I'd never have found that, glad you did [10:53] happy to change that for post-RC, I think [10:53] Right. I am checking with a live CD, but want to check with alternates as well. [10:53] s/alternates/altnerate [10:54] remind me of the bug number? [10:54] one sec [10:55] if you can make sure a gcc bug is filed as well, I'd appreciate it [10:55] with preprocessed source [10:55] Ok, against which source gcc package? [10:55] its bug 450214 [10:55] Launchpad bug 450214 in parted "Parted server appears to hang when attempting to format a swap partition on powerpc." [Undecided,New] https://launchpad.net/bugs/450214 [10:55] gcc-4.4 [10:56] Ok./ Whats the easiest way to get pre-processed source? [10:56] build the package, copy and paste the gcc line that builds the relevant program, delete -c and -o parted_server, add -E [10:57] the gcc people will need to know where the hang is though ... [10:57] Ok, will confirm everything, and fix up bugs. Shall I open a task against gcc-4.4 on the same bug, or should I open a fresh bug? [10:57] so it's just partman-base that needs to be rebuilt, not parted as well? [10:57] I would think another task is ok [10:57] opening a task is fine, I think [10:58] This is what I am checking. I am booting avanilla live CD, copying rebuilt partman-base binaries in, and seeing what happens. [10:58] it could of course still be a parted_server bug that optimisation changes just happen to trigger [10:58] Right. [10:59] partman-base: cjwatson * r170 ubuntu/ (Makefile debian/changelog): [10:59] partman-base: Build with -O2 on powerpc to avoid a suspected toolchain bug [10:59] partman-base: (LP: #450214). [10:59] BTW timer "exceptions" aren't really exceptions, they're just the way parted progress information is propagated up [10:59] Right [11:08] Looking at the build logs, libparted is built with -O2 anyway. [11:13] Ok, with ubiquity/live CD with rebuilt partman-base binaries copied in, -O2 is allowing things to function as normal. I think we can go on this, but I'm going to check with the alternate just to be safe, since libparted is in udeb form and built differently. [11:16] I think I already mentioned in the bug where the hang occurred. If built with -Os, the hang occurs when calling ped_timer_new from a parted_server function, can't remember which one from the top of my head. [11:25] ok, won't upload straight away anyway, and I think there may be one more partman-base change we need [11:25] evand: did you get anywhere with that parted_server syslogging work? [11:26] Yeah of course. [11:26] cjwatson: no, I was having some trouble with it and temporarily moved on to other bugs. [11:27] re not uploading, due to RC and its ports after all. [11:28] evand: shout if you need a hand ... [11:28] xivulon: PARTMAN_NO_COMMIT=1 is entirely normal [11:29] partman is divided into two phases in ubiquity; parted_server stays running between them [11:29] will do; I'll have another look as soon as I've got these kde issues sorted out [11:29] evand: I was wondering if there's an outside chance that it's causing occasional wubi hangs, you see [11:30] ah, noted. Priority bumped. [11:30] since at least some of those have been in the partman-commit phase too [11:30] well the first stage completes successfully I have no tracback on stage 2 [11:31] will try to get something tonight [11:33] No partman or any other shell script in /lib/partman is called after that as far as I can see [11:36] cjwatson, bah, my funny remote install fails in UserSetupApply [11:37] ogra: you might need to take some care with the user id [11:37] well [11:37] ogra: note that casper is very deliberately created at uid 999 [11:37] its not actually a supported way of installation anyway [11:37] use 998 :) [11:37] hmm [11:38] or actually, why not just set a password for the ubuntu user? [11:38] and ssh in as that [11:38] oh, right [11:38] * ogra tries that [11:41] cjwatson: Ok parted_server manages to format a swap partition, however I think mke2fs is choaking in a similar way to parted_server, which makes me think that, once again, the e2fsprogs udeb is built with -Os for powerpc. [11:41] this is on the alternate [11:44] yes, see BF_CCOPTS in e2fsprogs/debian/rules [11:47] yep just found that myself [11:49] * TheMuso rebuilds with -O2 to see if there is a difference. [12:04] ubiquity: evand * r3542 ubiquity/ (2 files in 2 dirs): [12:04] ubiquity: Properly set the size of the partition to be created upon resizing [12:04] ubiquity: in the KDE frontend (LP: #455580). [12:09] cjwatson: ok rebuilding e2fsckprogs-udeb with -O2 has things working [12:13] ok, I'll add an e2fsprogs task to that bug [12:21] Ok. I'll get some pre-processes source for parted_server.c at least. [12:23] davmor2: updated bug 455653 requesting some details from you. [12:23] Launchpad bug 455653 in ubiquity "kubuntu unable to check format checkboxes in manual partitioning" [High,Incomplete] https://launchpad.net/bugs/455653 [12:24] evand: both but I'll be running checks on kubuntu shortly so I'll double check on that one for you [12:24] okay [12:25] for what it's worth, I cannot reproduce it in 20091019.2 [12:32] cjwatson: Ok I'll do other alternate tests tomorrow night for a few other common install cases, just to ensure we catch as much as possible. I suspect this happens with anything dealin with disks, so lvm, cryptsetup etc probably need checking. [12:34] ok, thanks [12:38] ubiquity: evand * r3543 ubiquity/ (debian/changelog ubiquity/frontend/kde_ui.py): [12:38] ubiquity: Hide the encrypt home radio button in the KDE frontend when in oem-config [12:38] ubiquity: mode (LP: #455479). [14:24] ubiquity: cjwatson * r3544 ubiquity/ (debian/changelog ubiquity/frontend/kde_ui.py): [14:24] ubiquity: KDE frontend: Fix incorrect error message when the slideshow doesn't [14:24] ubiquity: exist. [14:51] cjwatson: anything else you want to land in trunk before I do an upload? [14:54] evand: go for it, anything I discover with wubi is going to take a while [14:55] incidentally, I've run headfirst into the "Try (hd0,0): NTFS5:" issue on the test install I've been running in the background. [14:57] perhaps I'm forgetting a bit of history, but it seems odd that we set ubiquity/reboot to true in wubi. Of course usability issues are for a different time in the cycle. :) [14:57] try finding the top-level grub config file in the ntfs filesystem and putting 'set debug=all' at the top of it [14:58] will do [15:35] cjwatson: for what it's worth, http://people.canonical.com/~evand/tmp/wubi-failure-2.png [15:49] wow, my remote install which i started 6h ago on my babbage board finbally finished ... [15:49] package removal did crawl ... took several hours [15:53] interesting. Wait long enough and it boots, which I think is in line with what davmor2 was experiencing. [15:54] and it boots fine every time now. argh. [16:25] ubiquity: evand * r3545 ubiquity/debian/changelog: releasing version 2.0.2 === bdmurray_ is now known as bdmurray [16:45] evand: we went out for 2 hours the last time I had that issue and it hadn't started how long is a long time? [16:46] ten minutes or so [16:46] perhaps it was just a sufficient number of reboots / mounts [16:46] davmor2: reproduced this under strace, digging ... [16:47] (not that it's immediately illuminating, but) [16:55] without a doubt, something else is asynchronously opening stopfifo, and I'm pretty sure it isn't ubiquity [16:56] my suspicions are drifting back in the direction of sreadahead, so I'm going to give that a try [17:09] not sure if it's just as a result of me rebooting a third time, but diverting /sbin/readahead fixed the hangs I was getting in partman. [17:12] it's working well for me, though I removed /etc/init/sreadahead.conf [17:12] so far, anyway [17:13] Keybuk's comments on #ubuntu-release filled in the gaps of understanding I had on how sreadahead might be breaking it [17:13] (you mean /sbin/sreadahead?) [17:14] err yes [17:14] * evand reads up [17:15] 4/4 successful so far (I rebooted once it got to "Calculating files to skip copying") [17:16] now to try without strace, which will be faster [17:20] oh, and FWIW, ghastly rune for arranging to strace both parted_server and partman-commit was to put this in /scripts/casper-bottom/25configure_init in the initrd: [17:20] sed -i "s/return ('\/bin\/partman-commit'/import subprocess; subprocess.Popen(['strace', '-f', '-o', '\/tmp\/parted_server.trace', '-s', '1024', '-tt', '-p', subprocess.Popen(['pidof', 'parted_server'], stdout=subprocess.PIPE).communicate()[0].strip()]); return (['strace', '-f', '-o', '\/tmp\/partman-commit.trace', '-s', '1024', '-tt', '\/bin\/partman-commit']/" /root/usr/lib/ubiquity/ubiquity/components/partman_commit.py [17:32] casper: cjwatson * r720 trunk/ (debian/changelog scripts/casper-bottom/25configure_init): [17:32] casper: scripts/casper-bottom/25configure_init: Disable sreadahead on live CD [17:32] casper: boot. Not only does it profile the live CD boot to no benefit, but it [17:32] casper: also looks as if it may be responsible for breaking Wubi installs by [17:32] casper: reading from partman's synchronisation FIFOs (LP: #439279). [17:33] casper: cjwatson * r721 trunk/debian/changelog: releasing version 1.205 [17:36] cjwatson: will you back online latter I'll let you know how I get on with the new cds [17:38] I'll be off IRC for a couple of hours, then probably back later in the evening ('cos my life is so exciting) [17:39] I don't know what you mean I'll be burning and testing cd's till midnightish [17:40] hah [17:40] hopefully this lot will be a bit more rewarding, wubi-wise [17:42] \o/ [17:45] and there we go, rebooted fine for me [21:29] Hi colin, noticed you fixed 439279 thanks a lot [21:30] xivulon_: Just got to wait for the iso's to test it out fully now :) [21:30] yep! [21:31] * davmor2 is looking forward to a fully functioning wubi :) [21:31] Well actually I can test now with break=init + sed [21:33] I do think I tried to kill sreadahead in the past (as per colin suggestion), hmm [21:34] but that was definitely after chroot... [21:34] xivulon_: yeah so did I but it was also held up by something just before it. [21:35] xivulon_: cjwatson solved that one and this one was left [21:36] ah cool [21:38] xivulon_: he tried it about 8 times before he had to shoot off. So he is hoping that that it is now :) [21:39] xivulon_: I think evand had a success doing the same thing too (but I could be wrong) [21:48] my karmic kvm jams randomly by the way [22:03] sedded 25configure_init, and did a full installation, the installer is way beyond the point where it usually jams [22:04] fingers crossed [22:08] of course I used break=mount not break=init [22:30] :) works here [22:31] cjwatson you get a bottle of champagne or a box of coffee at your choice [22:31] ^ that is real coffee, not the dark stuff I see you guys drinking... [23:19] xivulon_: hooray for workingness. I think this was probably the core of the problem all along, but there were some other random problems as well that were masking it [23:21] was a close one... fantastic job, as usual [23:22] well at least I know a bit more about partman :P [23:22] hard work tracking it down today, was still a guess in the end [23:22] couldn't actually catch the whole thing in the act except by stracing the *entire system* somehow ;-) [23:22] which didn't sound like much fun [23:23] guess have to top up my offer [23:23] hmm, thinking about it I suppose I could have inserted an lsof call into parted_server or similar, but meh [23:23] meh, it's my job :) [23:23] will you be at the release party? [23:23] most likely yes [23:24] I think I will be - have to take the dog to be neutered the next morning, but can probably stay for a short while [23:24] hope to see you there! [23:44] cjwatson: bug 456776 [23:44] Launchpad bug 456776 in os-prober "No second os showing up in d-i auto resize" [Undecided,New] https://launchpad.net/bugs/456776 [23:45] cjwatson: I've asked fader_ to confirm asap [23:49] cjwatson: anything else you want on that bug before I sod off to bed? [23:50] this is an install against karmic, I don't know if that is relevant [23:51] so you did one install on sda1 (/) sda5 (swap), then another install on sda6 (/) sda7 (swap), and only the second showed up in grub.cfg? [23:51] os-prober found it, at least, I can see that much in the log [23:51] cjwatson: looks that way yes unless I'm completely mis-reading it [23:52] I wonder if it then completely failed to parse grub.cfg [23:53] ... no, it's producing result: lines there [23:54] cjwatson: there are only 4 lines showing up on the menu. Current kernel, current kernel rescue and the 2 memtests [23:56] yeah, can see that in the generated grub.cfg [23:56] nothing obviously wrong, guess I'll have to try to reproduce this - shouldn't need anything else from you right now, thanks [23:56] cjwatson: Cool nn