[00:22] cjwatson I get partman-auto-loop/unclean-host error although the virtual disk file is empty and should not generate that [00:25] i'm having trouble installing from today's desktop-amd64 installer, failing on formatting the partition [00:26] "The ext3 file system creation in partition #1 of SCSI1 (0,0,0) (sda) failed." [00:26] xivulon_: logs again, I guess :-/ Too late for me to attempt to debug it now [00:26] kirkland: same for you [00:26] (unless evand's handy) [00:27] cjwatson: not an emergency [00:27] well, it might be if other folks are seeing it [00:27] cjwatson: i'll gather for you though [00:27] cjwatson: yeah, i'm just doing some daily iso testing ;-) [00:27] oh, I should update partman-auto-loop for ext4, I notice [00:27] cjwatson: evand: I like the presentation of the encrypt-home bit! cheers for that! [00:27] all evand's work [00:28] cjwatson: particular logs you want? the usual? [00:28] partman-auto-loop: cjwatson * r47 ubuntu/ (autopartition-loop debian/changelog): Add ext4 support. [00:28] cjwatson I guess this is due to autopartition-loop, will have a quick go myself at it [00:28] kirkland: syslog and partman [00:29] cjwatson: sure [00:29] xivulon_: odd, I can't imagine how that would fire if there weren't really any images [00:29] 'mount -t auto -o loop,ro /host$path /tmpmountpoint' has to succeed [00:30] you might want to set -x it to see exactly what's going on [00:31] cjwatson: what should I file the LP bug against? [00:31] ubiquity [00:31] * kirkland always gets it wrong :-) [00:31] alternate => debian-installer, desktop => ubiquity [00:31] as a rule of thumb [00:32] already done that (-x) [00:32] cjwatson: ah, i usually file this sort of thing against partman [00:32] oh, you can do that but TBH it is tricky to figure out which partman component is involved without code inspection [00:32] I get it wrong on a regular basis [00:33] (I'd rather partman were just one big component really, but it wasn't my idea and it's pain to merge them) [00:36] cjwatson: that's the part i meant i always get wrong :-) [00:36] * kirkland always gets it wrong :-) [00:37] cjwatson: https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/317709 [00:37] Launchpad bug 317709 in ubiquity "jaunty: ext3 filesystem creation failed" [Undecided,New] [00:37] cjwatson: with partman, syslog, and screenshot [00:38] ok [00:38] Jan 16 00:30:33 ubuntu ubiquity: /bin/partman-commit: 23: stralign: not found [00:38] Jan 16 00:30:36 ubuntu udevd-event[7286]: mknod(/dev/pktcdvd/control, 020660, (10,62) failed: Too many levels of symbolic links [00:38] Jan 16 00:30:36 ubuntu partman: mke2fs 1.41.3 (12-Oct-2008) [00:38] Jan 16 00:30:36 ubuntu partman: Could not stat /dev/sda1 --- No such file or directory [00:38] the combination of all of that is not all that encouraging [00:40] can you check whether /dev/sda1 exists? [00:42] the stralign thing is harmless but I'll fix it anyway [00:43] cjwatson I zeroed the virtual disk and it works, looks like a left-over from a previous test (not sure why because I uninstalled) [00:44] xivulon_: hmm. oh well ... [00:44] well sort of works, seems to get stacked on the same point as last time [00:44] logs on their way [00:44] partman-base: cjwatson * r122 ubuntu/ (debian/changelog partman-commit): [00:44] partman-base: Resynchronise partman-commit with partman, fixing harmless warning about [00:44] partman-base: stralign. [00:45] kirkland: I'm wondering if the udevd failure there rendered it somehow unable to create /dev/sda1. Would be strange [00:45] or whether it actually wasn't /dev/sda1 at all. 'udevadm info --export-db' or similar might be worth hunting through [00:47] cjwatson: this a kvm, qcow2 disk [00:47] same as I use for testing [00:48] a single mknod() failing shouldn't break anything else, from my reading of udevd's code [01:11] cjwatson, paste.ubuntu.com/105383 [02:10] kirkland: cjwatson: the design was mpt's suggestion [10:35] cjwatson: there seems to of been an epic fail with ubiquity oem so I'm trying an alt install of it. If I get a fail I'll throw up the log files [10:37] encrypted lvm is causing issues with the ext2 /boot failing to partition [10:41] cjwatson: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/317618 [10:41] Launchpad bug 317618 in debian-installer "Xubuntu jaunty-alternate-i386.iso fails to re-partition 40GB drive w/multiple partitions" [Undecided,New] [11:50] davmor2: bug 317791 perhaps? [11:50] Launchpad bug 317791 in oem-config "oem-config-dm installer fails" [Undecided,New] https://launchpad.net/bugs/317791 [12:02] bugger, it's going to take over three hours to download the desktop image [13:40] cjwatson: sorry away just got back. [13:41] I can reproduce it every time the install is different to what is already on the hd [13:42] cjwatson: my hd has borked a bit on the test machine that I was installing oem on so I need to wipe and try again [13:42] davmor2: I didn't mention it here, but I figured out the problem [13:42] new parted upload is working its way through [13:43] will have affected both d-i and ubiquity, I'm afraid, probably pretty much hosing all partitioning :-( [13:43] :( [13:44] never mind give me something to do any ideas on when the new images will be up? [13:47] couple of hours - the new parted won't have finished publishing yet [13:47] slangasek is already going to hurt me, I'm sure [13:48] since it was due to a patch I shoved through at short notice for wubi [14:08] charlie-tca: there's a fix in place for the partitioning issue but it will need a respin on most of the images [14:08] Good news, then! [14:09] I am trying to be patient :-) [14:18] cjwatson: here borrow my stab/bullet/bomb proof vest for when you tell slangasek [14:24] * charlie-tca thinks it _can_ be that bad [14:28] I pushed in a late change which broke the world. That tends to make one unpopular [14:32] especially as the release date has been pushed back a day already :( [14:38] cjwatson: on a plus side most of the apps have been tested now so it's only the installer [14:40] mm [14:40] as long as nobody uploaded changes ... [14:40] and waiting for the images [14:40] no don't point that bit out to slangasek though ;) [14:50] cjwatson left you some logs yesterday night, not sure if you noticed, doesn't look to different from previous one [14:51] xivulon: I thought you said the problem was solved - anyway there was a parted bug I created by trying to fix your previous issue [14:51] so that could easily be it [14:51] will today iso include all relevant fixes? [14:51] I'm about to rebuild [14:52] today's is broken [14:52] good I will test tonight [14:52] thanks for the patches [15:04] reading https://wiki.ubuntu.com/UDSJaunty/Report/Foundations it seems that grub2 will happen for jaunty, my understanding of what happened at UDS (I missed that track) was quite different [15:05] it doesn't say that at all [15:05] it's in a section marked "These features involve development or other actions by the community, and thus we cannot guarantee their implementation within this release cycle" [15:05] not at all definite [15:06] thanks for clarifying [15:23] partman-target: cjwatson * r743 ubuntu/ (debian/changelog finish.d/fstab_removable_media_entries): [15:23] partman-target: Fix disk_containing function to use its argument rather than relying on [15:23] partman-target: $dev. [15:26] evand: assigned bug 317068 to you since you said you were working on the same thing yesterday [15:26] Launchpad bug 317068 in ubiquity "ubiquity crashed with InstallStepError in configure_user()" [Undecided,In progress] https://launchpad.net/bugs/317068 [15:27] xivulon, grub2 was supposed to be added as an option into the installer (and preseedable) so more feedback could be gathered on it this cycle from what I recall in discussions [15:29] I'd be willing to test it, and make it available [15:30] I think somebody needs to get its update-grub equivalent up to par with our Ubuntu modifications to grub first [15:30] and in general check all our modifications over - which will be a fairly long job unfortunately [15:30] hmm :) [15:30] I'll poke it next week [15:31] oh, that's not a part of the installer.. what does d-i need in order to be able to use it? [15:33] grub-installer already has basically the relevant code [15:33] Debian did that [15:33] right [15:33] although we've temporarily disabled it until such time as we actually want to use it [15:33] and what about the gtk+ frontend? [15:34] cjwatson: ok; thanks [15:34] tjaalton: no progress since you last asked [15:34] cjwatson, who wrote a majority of the update-grub modifications? perhaps since they are best versed upon what was changed they should be the one who opts to poke it? I added a few things in it in hardy at some point to bring it closer, but i'm sure there is still a lot missing [15:34] cjwatson: heh ok [15:34] superm1: err, a cast of thousands^Wseveral [15:34] no matter who does it it'll be a matter of painstakingly going through the diff [15:34] cjwatson, ah... [15:39] heh, debdiff is 12k lines :) [15:43] of the package, update-grub alone is ~1000 lines [15:52] well update-grub would be the only thing that needed updating though. [15:54] oem-config: cjwatson * r577 trunk/debian/ (changelog oem-config-udeb.postinst): Suppress user-setup's encrypted home directory question in OEM mode. [15:59] I see slangasek on the list of update-grub contributors :) [16:01] cjwatson, why suppress that question in OEM mode? Shouldn't users of preinstalled systems be able to have the same question presented? [16:02] had a couple of patches in the update-grub related to wubi, but if grub2 supports loop mounting and vfat/ntfs they might not need to be ported [16:03] I can play with that once I can get the installation to complete [16:03] superm1: the suppression is in the first stage; I haven't yet got round to *adding* the question to the second stage but I agree that that makes sense [16:03] superm1: i.e. it doesn't make sense for the OEM customisation user to have an encrypted home directory [16:22] cjwatson, oh okay :) === davmor21 is now known as davmor2 [16:44] xivulon: cjwatson: evand: Umenu is still coming up with invalid CD detected [16:47] wubi starts up and immediately starts downloading from the interweb [16:50] davmor2: jaunty or 8.04.2? [16:50] latest respin of jaunty [16:52] evand: this one 8e01f42693bb81a9b27bc4224cf5bb64 *jaunty-desktop-i386.iso [16:52] davmor2: we're on the cusp of replacing umenu and wubi with a python rewrite, but have not done so yet. So I'd hold off on testing them for the time being. [16:53] evand np's [16:53] * davmor2 moves onto m-a instead [16:54] sorry, didn't realise the rewrite was happening [16:54] well, at least not soon [16:55] cjwatson: np's I needed xp on for migration-assistant anyway :) [17:01] No worries. xivulon has been working on it, and it seems to almost be ready enough for the CDs. === You're now known as ubuntulog [17:59] partman-target: cjwatson * r744 ubuntu/ (debian/changelog finish.d/fstab_removable_media_entries): [17:59] partman-target: Fix use of udevinfo rather than udevadm info when checking if a disk is [17:59] partman-target: USB. [18:04] meh hd is playing up need to low level format it [18:29] cjwatson: is there a desktop iso yet that fixes the filesystem creation failure i had yesterday? [18:29] kirkland: yep, current one [18:29] it turned out to be a parted bug I introduced, once I reproduced it (albeit on alternate) [18:30] cjwatson: http://cdimage.ubuntu.com/ubuntu-server/daily/current/jaunty-server-amd64.iso ? [18:30] cjwatson: sorry, that's server [18:30] kirkland: not affected [18:30] wget http://cdimage.ubuntu.com/daily-live/current/jaunty-desktop-amd64.iso [18:30] yes [18:31] cjwatson: cool, thanks, i'm downloading [19:02] yay hd fixed try again === robbiew is now known as robbiew-afk === robbiew-afk is now known as robbiew === robbiew is now known as robbiew-afk === robbiew-afk is now known as robbiew [21:41] evand: just looking at the oem-config language screen - would it be worth sorting the languages down then right, rather than right then down? so: [21:41] A D G A B C [21:41] B E H rather than D E F [21:41] C F I G H I [21:42] I find it rather hard to read at the moment and am wondering if that's why - FWIW the gfxboot language screen is sorted the first way [21:43] I think people are typically used to reading right then down for flowing text, but down then right for columns (compare newspaper layout) [21:45] cjwatson: sure, I'm not tied to either way [21:49] hmm, except it isn't clear to me that you can tell an iconview to do that [21:52] it seems to be pretty set on laying them out in rows [21:59] yikes [22:02] I filed http://bugzilla.gnome.org/show_bug.cgi?id=568033 upstream [22:02] Gnome bug 568033 in GtkIconView "horizontal item ordering for GtkIconView" [Enhancement,Unconfirmed] [22:05] alt installer: where all is the username used? /home/user and /etc/passwd is all I can think of [22:08] I wouldn't like to try to list every possible place [22:08] programs have a bad habit of copying the username around [22:08] I'd just grep for it if you care [22:09] and 'find' as well, since it ends up in filenames (e.g. the crontab spool) [23:21] cjwatson: hmm, i still haven't successfully installed the jaunty desktop :-/ [23:22] cjwatson: latest try ended with a python backtrace [23:22] kirkland: with encrypt-home enabled? [23:22] cjwatson: tried to send an error report but my connectivity is poor at the moment (in the car) [23:22] cjwatson: yup [23:23] cjwatson: i'm trying without now [23:23] kirkland: that's known [23:23] cjwatson: ah, okay [23:23] cjwatson: evand looking at it, or does he need my help? [23:23] I've lost the bug number, but it's on the jaunty tech overview page [23:23] bug 317068 [23:23] Launchpad bug 317068 in ubiquity "ubiquity crashed with InstallStepError in configure_user()" [Undecided,In progress] https://launchpad.net/bugs/317068 [23:23] cjwatson: gotcha. so that's not going to be fixed in time for the alpha? [23:23] no, afraid not [23:24] :-/ :-/ :-/ [23:24] we only found out about it rather too late [23:24] i know, i understand [23:24] yeah, I'm disappointed, but there you go [23:24] i've downloaded an ISO a day trying it :-) [23:24] (2 some days) [23:25] well, on the bright side, we might get the filename encryption in the kernel and working before the next alpha [23:25] it wasn't helped by me screwing up parted ...