[00:43] <CIA-3> ubiquity: cjwatson * r4073 ubiquity/debian/real-po/ (81 files): debconf-updatepo
[00:47] <CIA-3> ubiquity: cjwatson * r4074 ubiquity/debian/ (83 files in 2 dirs):
[00:47] <CIA-3> ubiquity: Restore translations for oem-config-check and oem-config-udeb, lost in
[00:47] <CIA-3> ubiquity: oem-config merge.
[00:49] <CIA-3> ubiquity: cjwatson * r4075 ubiquity/ (8 files in 3 dirs):
[00:49] <CIA-3> ubiquity: Display simple progress feedback using debconf-apt-progress while
[00:49] <CIA-3> ubiquity: removing oem-config (LP: #558593).
[00:55] <CIA-3> ubiquity: cjwatson * r4076 ubiquity/ (bin/ubiquity-dm debian/changelog):
[00:55] <CIA-3> ubiquity: Write locale-gen output from ubiquity-dm to /var/log/installer/dm rather
[00:55] <CIA-3> ubiquity: than to the console.
[08:35] <ogra> cjwatson, is there any way to convince partman to let me create /boot as fat ?
[08:36] <ogra> i know it should work as long as /vmlinuz and /initrd.img are properly linked from the rootfs
[08:36]  * ogra just tried a netinst installing to the SD he booted from
[08:37] <ogra> omap uboot has probs loading from ext2 though
[08:42] <superm1> cjwatson, hm, so in trying a disk with that new casper it is hanging for a long time, with what appears to be looking for a dhcp address.  could you make that network start stuff optional instead?
[08:44] <ogra> cjwatson, just fyi, i'm properly getting a kernel now with the base-installer change
[08:52] <ogra> bah, i take that back, something failed
[08:53] <cjwatson> ogra: fat should be possible - what's going wrong?  are you getting an error dialog?
[08:53] <ogra> cjwatson, yes, telling me that using fat for /boot is impossible
[08:53] <ogra> i need to start over from serial console, the kernel has a bug that doesnt let me to switch ttys
[08:54] <ogra> so i cant get to the actual log atm
[08:54] <cjwatson> superm1: wait a sec though, that's odd, weren't you already doing url preseeding?  in that case you should already have been getting dhcp - I just moved it around
[08:54]  * ogra would also like to know what fails with kernel installation :/
[08:54] <cjwatson> ogra: well, fat for /boot does have some genuine problems in update-initramfs
[08:54] <ogra> yes, but you can work around them if you have the links on /
[08:54] <ogra> i did that before
[08:55] <ogra> its moaning but working
[08:55] <cjwatson> ogra: if it's your only choice, we can make a subarch exception from that dialog
[08:55] <ogra> well, i'll do some more tests
[08:55] <cjwatson> log - use "execute a shell" from the main menu?
[08:55] <ogra> right, but for now it threw me back into base install
[08:55] <ogra> which i cant stop
[08:56] <cjwatson> ok
[08:56]  * ogra twiddles thumbs
[08:56] <ogra> serial is better since i can capture stuff from the laptop :)
[09:04] <cjwatson> ogra: something like http://paste.ubuntu.com/414145/ look OK to you?
[09:24] <CIA-3> debian-installer: cjwatson * r1284 ubuntu/ (10 files in 6 dirs):
[09:24] <CIA-3> debian-installer: Tidy up the i386/netboot-xen configuration for Ubuntu, and enable it
[09:24] <CIA-3> debian-installer: (LP: #532547).
[09:26] <CIA-3> debian-installer: cjwatson * r1285 ubuntu/ (8 files in 2 dirs): Move to 2.6.32-21 kernels.
[09:33] <cjwatson> ogra: can I go ahead with that partman-basicfilesystems change I pasted?
[09:46] <ogra> cjwatson, it will just omit the error, right ? in case i find a way to use ext2 it wont get in my way ?
[09:46] <ogra> i think thats fine
[09:47] <cjwatson> right
[09:48] <ev>  anyone have an idea of how I could reproduce the network environment in bug 556831? I've tried killing DNS, as well as just flat out disconnecting the host (I'm using KVM), but neither surfaces the issue that superm1 is seeing.  I hit the NetworklessInstallFixes code path just fine.
[09:48] <CIA-3> partman-basicfilesystems: cjwatson * r583 ubuntu/ (check.d/mountpoint_fat debian/changelog):
[09:48] <CIA-3> partman-basicfilesystems: Allow armel/omap to use FAT for /boot, since the problems with it can be
[09:48] <CIA-3> partman-basicfilesystems: worked around while it's difficult to use anything else given uboot
[09:48] <CIA-3> partman-basicfilesystems: limitations.
[09:49] <cjwatson> ev: sounds like you want firewall configuration that permits DNS but excludes anything else
[09:49]  * ev dusts off the iptables manual
[09:49] <cjwatson> i.e. local name server, drop (not reject) packets sent to outside world
[09:49] <cjwatson> (a sensible firewall configuration would reject - but drop is the worst case)
[09:49] <ogra> bah, sigh ... so the kernel fails because mmcblk0p2 has no uuid in sysfs
[09:49] <ev> cjwatson: thanks, I'll give that a shot
[09:49] <ogra> well, mkinitramfs fails
[09:53] <ogra> hmm, no, its all there as it should be
[10:02] <ogra> gar !
[10:02] <ogra> initramfs-tools/hook-functions has no handling for mmc *at all* !
[10:03]  * ogra curses
[10:04] <CIA-3> partman-basicfilesystems: cjwatson * r584 ubuntu/debian/changelog: releasing version 63ubuntu4
[10:07] <ogra>                 block=${root#/dev/}
[10:07] <ogra>                 block=${block%%[0-9]*}
[10:07] <ogra> bah ... that turns mmcblk0 into mmcblk
[10:13] <dmarkey> is it on the roadmap to allow /boot to be on LVM?
[10:16] <cjwatson> I thought you already could
[10:16] <cjwatson> what error do you get when you try?
[10:38] <dmarkey> oh, i never tried :), so in short there can be a single partition on the disk, comprising of an LVM pv?
[10:45] <cjwatson> I think it should work, it's just subject to the bootloader understanding it
[10:45] <cjwatson> which grub2 ought to
[10:53] <dmarkey> i see. Must see if i can coerce the installer into doing that
[12:33] <ev> FINALLY.  cjwatson, superm1: I can reproduce the apt timeout bug.  I'll work on a fix after lunch.
[12:59] <ogra> cjwatson, Apr 14 11:57:47 base-installer: info: Using kernel 'linux-omap'
[12:59] <ogra> Apr 14 11:57:47 base-installer: info: Setting do_initrd='yes'.
[12:59] <ogra> Apr 14 11:57:47 base-installer: info: Setting link_in_boot='yes'.
[13:00] <ogra> cjwatson, how do i tell it to not set link_in_boot ?
[13:00] <ogra> since we need a link in / instead if /boot is vfat
[13:01] <cjwatson> currently that's only architecture-specific, not subarchitecture-specific
[13:01] <cjwatson> I'm guessing that isn't appropriate for other armel subarches?
[13:02] <ogra> right
[13:02] <ogra> imx has a very special setup for booting and dove has ext2 /boot
[13:02] <cjwatson> you'll have to hack it in base-installer/library.sh then
[13:02] <ogra> ok
[13:03] <cjwatson> i.e. if archdetect returns armel/omap, override what we get from debconf
[13:03] <ogra> i'm not bitten by it yet but i think update-initramfs will chocke on it
[13:03] <persia> In which package do the CD boot menus live again?
[13:03] <ogra> gfxboot
[13:03] <cjwatson> err
[13:03] <cjwatson> no
[13:03] <ogra> unless that changed
[13:03] <cjwatson> it's slightly spread around
[13:04] <cjwatson> gfxboot implements the bytecode interpreter that drives part of the CD boot menus.  it is unlikely to be the package you need to modify
[13:04] <cjwatson> persia: could you be more specific about the change you'd like to make?
[13:04] <persia> OK.  Specifically, I want to see if there's a way to disable the "Install UEC" feature from server CDs.
[13:04] <cjwatson> for yourself, or for server images in general?
[13:04] <ogra> is that in the main menu ?
[13:04] <ogra> i thought thats only in tasksel
[13:04] <cjwatson> ogra: no.
[13:04] <persia> On an arch-specific basis: UEC is currently [i386 amd64], but this isn't indicated anywhere (and CDs are oversize for powerpc/ia64)
[13:04] <cjwatson> it's in the main menu.
[13:05] <ogra> ah
[13:05] <cjwatson> persia: it'd be in cdimage, tools/boot/lucid/*
[13:05] <persia> For server images in general (well, actually, I'll work with kirkland to do it, but want to do prep work)
[13:05] <cjwatson> debian-cd rather
[13:05] <persia> Thanks :)
[13:05]  * ogra would like that to go away at some point on armel too ... but only from tasksel and its not for lucid 
[13:05] <cjwatson> but the Ubuntu branch, not the packaged version
[13:05]  * persia tries to figure out why `grep -rn UEC .` didn't return anything for debian-cd
[13:06] <persia> Aha!  I thoguht the package was refreshed from the Ubuntu branch.
[13:06] <cjwatson> because it's spelled "Install Ubuntu ^Enterprise Cloud"
[13:06] <cjwatson> it's already amd64/i386 only in debian-cd ...
[13:06] <cjwatson> as in, cloud.seed isn't used anywhere else
[13:06] <cjwatson> ./tools/boot/lucid/boot-amd64:362:  append $KERNEL_PARAMS file=/cdrom/preseed/cloud.seed initrd=/install/initrd.gz quiet --
[13:06] <cjwatson> ./tools/boot/lucid/boot-i386:360:  append $KERNEL_PARAMS file=/cdrom/preseed/cloud.seed initrd=/install/initrd.gz quiet --
[13:07] <cjwatson> so - in what sense is UEC [i386 amd64]?
[13:07] <cjwatson> eucalyptus-cloud | 1.6.2-0ubuntu29 |         lucid | amd64, armel, i386, ia64, powerpc, sparc
[13:08] <cjwatson> that's the reason the task shows up in tasksel
[13:08] <ogra> ah
[13:08] <cjwatson> it's sensitive to whether the package is available
[13:08] <persia> It expects KVM as underpinning.  kvm doesn't work on armel (no HW support), isn't ported to PowerVR, so can't work on powerpc.  I'm less sure about sparc/ia64.
[13:08] <ogra> right, no kvm on arm
[13:08] <cjwatson> so shouldn't we be removing it from the architectures where it doesn't work, and updating Packages-arch-specific and the package's Architecture field to match?
[13:09] <ogra> ++
[13:09] <persia> Quite possibly.  I'll be discussing that in about an hour.  I just wanted to make sure that I had the right information about the CD menus as well.
[13:09] <cjwatson> I don't see anything to do for the CD menus
[13:09] <ogra> at least until someone makes kvm work on the other arches
[13:10] <persia> No, it looks like the necessary bits are already done.
[13:10] <persia> Thanks for the pointer.
[13:10] <cjwatson> eucalyptus-nc only Recommends: kvm
[13:11] <cjwatson> (which should be qemu-kvm these days, I think, rather than going through the transitional package?)
[13:11] <ogra> i wonder if it can actually run in software emu
[13:11] <cjwatson> I don't know - but that explains why eucalyptus-nc is installable on armel right now
[13:11] <cjwatson> according to http://people.canonical.com/~ubuntu-archive/testing-ports/lucid_probs.html
[13:12] <persia> I'll check.  If it can work with bare qemu, then the package can be left alone, but the seeds may as well shift: something has to drop from the powerpc server disk to fit, and this seemed like a good candidate.
[13:16] <cjwatson> you could make it arch-specific in the seeds, and that ought to do
[13:17] <persia> That was my initial plan, but as with so many things, once one looks into something, one discovers it may be larger than anticipated :)
[13:23]  * ogra finds it really exciting that you can boot netinst d-i from SD and then overwrite the same SD during install
[13:31]  * ogra glares at "Preparing language-pack-gnome-en-base"
[13:36] <ogra> hrm ...
[13:36] <ogra> reconnects ...
[13:36] <ogra> yay, apart from the bootloader installation it seemd d-i survived on omap now \o/
[14:15] <cjwatson> superm1: comment on bug 482757 suggests that something called "Dell DataSafe Local Backup" may be using the embedding area immediately after the MBR and interfering with grub2.  Can you find out if this is true and do anything about it?
[14:15] <cjwatson> (bug metadata is probably wrong, never mind that ...)
[14:51] <ev> oo, just got an idea.  Instead of relying on debootstrap, we could provide a desktop ISO to the test runner.  It would then mount the squashfs and mount (and unmount) a aufs writeable layer on top for each test.
[14:59] <ev> granted, we could use an aufs mount either way
[15:03] <cjwatson> I thought the desktop team were doing some experimentation with EC2 testing
[15:03] <cjwatson> may be worth checking with them in case they have something already
[15:06] <ev> yeah, you had mentioned Launchpad doing that as well, I think
[15:06] <ev> will do
[15:42] <cjwatson> ev: what do you think about http://paste.ubuntu.com/414362/ ?  csurbhi requested something like this at the platform sprint, and I'm just now getting round to it
[15:42] <lamont> stupid question for someone able to parse and explain partman-auto/expert_recipe preseed values
[15:42] <superm1> cjwatson, No, it's not URL preseeding, it's a flat file.  at some ODMs there is limited internal network access during install and some there isn't.
[15:42] <lamont> d-i partman-auto/expert_recipe string foo :: \
[15:42] <lamont>         2000 242 4000 ext3      \
[15:42] <lamont>                 $primary{ } $bootable{ } method{ format } format{ } \
[15:42] <lamont>                 use_filesystem{ } filesystem{ ext3 } mountpoint{ / } \
[15:42] <lamont>         .       \
[15:42] <lamont> I want bigger for that.. what do the '2000 242 4000' magic numbers mean?
[15:43] <cjwatson> superm1: oh.  meh.
[15:44] <cody-somerville> lamont, minimal size, priority, and maximum size
[15:44] <lamont> in blocks, 1KB, or?
[15:44] <cjwatson> lamont: let me find you the documentation
[15:44] <lamont> cjwatson: oh, awesome
[15:44] <cody-somerville> http://d-i.alioth.debian.org/svn/debian-installer/installer/doc/devel/partman-auto-recipe.txt
[15:44] <cjwatson> let's please use Ubuntu references
[15:45] <cjwatson> in this case they're probably pretty similar but they aren't always
[15:45] <cjwatson> http://bazaar.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu/annotate/head%3A/doc/devel/partman-auto-recipe.txt
[15:45] <superm1> cjwatson, re datasafe local backup, i didn't think that it actually used anything in the MBR, but I'll inquire more details about it
[15:45] <cjwatson> superm1: so the reason that I did the dhclient thing was that it broke for me when trying to install a package which happened to be on the network
[15:46] <ev> cjwatson: looks entirely reasonable
[15:46] <superm1> cjwatson, that's what I had figured.  could it just be made into something optional?
[15:48] <cjwatson> if I can figure out a sensible option to use for it
[15:50] <cjwatson> preseed/allow-network or something?
[15:51] <superm1> sounds fine to me
[15:51] <cjwatson> can I default it to on?  I think that might be more generally appropriate
[15:51] <cjwatson> well, hmm, I wonder
[15:52] <cjwatson> I guess preserve-previous-behaviour is better
[15:52] <cjwatson> so preseed/allow-network=true then
[15:57] <cjwatson> superm1: fixed and uploaded
[15:57] <superm1> thanks
[16:23] <superm1> cjwatson, i've got the right contact and going to set up a meeting about datasafe local and what it's really doing to the disk.  as a consolation, could you maybe query the contents of that 30kb after the MBR to see what's there?  It's normally unused in scenarios that are plain windows, right?  If it's being used by something currently, maybe recommend installing to a partition for those folks
[16:24] <cjwatson> not feasible at this point
[16:24] <cjwatson> it's actually really hard to do even that
[16:24] <cjwatson> what's there might be a previous version of grub and it isn't easy for it to recognise itself
[16:24] <cjwatson> unfortunately
[16:25] <superm1> You mean previous versions of grub put stage 1.5 there right?
[16:26] <cjwatson> previous versions of grub2
[16:26] <cjwatson> a previous grub-install run
[16:26] <superm1> ah
[16:27] <cjwatson> blacklisting certain magic numbers or something might be more feasible - but I think it probably is what it is for lucid at this point, although I know it does cause some problems
[16:27] <cjwatson> I don't want to make precipitate changes as this stuff is really quite delicate
[16:28] <superm1> right.  well i'll gather what details I can about DDLB and share them at UDS.  could at least try to get it right for maverick and backport to the dot releases after making sure that it's stable
[16:28] <cjwatson> not that I'm happy about the current situation, it's not just this Dell software, it's other things
[16:28] <cjwatson> unfortunately right now I do not have a better solution in mind
[16:29] <cjwatson> all the alternatives also have fairly serious problems
[16:29] <cjwatson> that I've thought of so far, anyway
[16:30] <cjwatson> it may have to come down to a UI option, but the accompanying text would be thoroughly nasty
[16:36] <CIA-3> debian-installer: cjwatson * r1286 ubuntu/debian/changelog: releasing version 20081029ubuntu99
[16:39] <cjwatson> ev: can there be a ubiquity upload at some point today so that it's possible for people to test my oem-config UI change?
[16:40] <cjwatson> I'm heading out v. shortly ...
[16:40] <ev> cjwatson: absolutely
[16:40] <ev> I'll sort it out
[16:40] <cjwatson> thanks
[16:40] <ev> sure thing
[16:52] <dmarkey> cjwatson: i see some progress has been made on pae :)
[16:54] <cjwatson> dmarkey: yeah, aside from xenfs which is probably now too late for lucid, the rest should be in once that d-i builds
[16:54] <cjwatson> testing welcome
[17:00] <dmarkey> cool, xenfs isnt needed it turns out, when will i see a netboot image hitting the mirror?
[17:02] <cjwatson> later today
[17:03] <dmarkey> excellent, thanks
[17:03] <dmarkey> is there still a preseed argument to fallback to grub1?
[17:03] <cjwatson> yes, same as before
[17:04] <cjwatson> grub-installer/grub2_instead_of_grub_legacy=false
[17:05] <dmarkey> you think it would give out installing onto /dev/xvda?
[17:06] <cjwatson> no idea :)
[17:07] <dmarkey> and as far as i remember, the installer will pick up on grub-installer/grub2_instead_of_grub_legacy=false if its on the kernel command line?
[17:09] <cjwatson> yes
[17:10] <CIA-3> ubiquity: cjwatson * r4077 ubiquity/ (debian/changelog scripts/install.py):
[17:10] <CIA-3> ubiquity: Increase kernel flush times (dirty_writeback_centisecs to 3000, and
[17:10] <CIA-3> ubiquity: dirty_expire_centisecs to 6000) during bulk data copying. Surbhi
[17:10] <CIA-3> ubiquity: Palande suggests that this should make it easier for the kernel to pack
[17:10] <CIA-3> ubiquity: blocks contiguously, speeding up ureadahead after installation.
[17:26] <dafydd> Just a quick question regarding the Karmic ISO layout,
[17:27] <dafydd> I read the guide on CD customization,
[17:27] <dafydd> and the example seems to be different than the layout from the Karmic ISO
[17:28] <dafydd> Should my extra packages be put in /pool or in /dist/karmic/extras/binary-i386/pool/extras ?
[17:34] <CIA-3> ubiquity: evand * r4078 ubiquity/ (158 files in 3 dirs): Update translations from Launchpad.
[17:37] <CIA-3> ubiquity: evand * r4079 ubiquity/ (d-i/manifest debian/changelog):
[17:37] <CIA-3> ubiquity: Automatic update of included source packages: base-installer
[17:37] <CIA-3> ubiquity: 1.103ubuntu7, choose-mirror 2.29ubuntu3, partman-base 139ubuntu4,
[17:37] <CIA-3> ubiquity: partman-basicfilesystems 63ubuntu4, tzsetup 1:0.26ubuntu8.
[18:02] <CIA-3> ubiquity: evand * r4080 ubiquity/debian/changelog: releasing version 2.2.17
[23:13] <cjwatson> dafydd: it doesn't actually matter as long as the references in the Packages files are correct - however putting a "pool" directory under dists/ is just plain bizarre
[23:36] <CIA-3> partman-ext3: cjwatson * r764 ubuntu/ (3 files in 2 dirs):
[23:36] <CIA-3> partman-ext3: Add preseedable partman-ext3/lazy_itable_init question, which if true
[23:36] <CIA-3> partman-ext3: runs mkfs.ext* with '-E lazy_itable_init', greatly speeding up mkfs on
[23:36] <CIA-3> partman-ext3: large drives (LP: #556621). This defaults to false since it is
[23:36] <CIA-3> partman-ext3: currently unsafe for use on areas of disk that previously contained a
[23:36] <CIA-3> partman-ext3: filesystem.