[00:38] <GrueMaster> Something like that.  I would explain it to you, but I have been beating my head against this wall for 4 days now.  At least I'm at the point of getting 4 different systems generating 3 different errors, all with the same seed.
[03:26] <twb> Stupid question -- in partman if you say something like 4T, you end up with an LV that's 3.7TiB.  Can I just type 4Ti into partman to have it DWIM?
[03:26] <twb> (That's not fs overhead; I'm looking at lvs output)
[06:12] <FourDollars> cjwatson: I file a bug about EFI boot partition error at https://bugs.launchpad.net/ubuntu/+source/partman-partitioning/+bug/972122 .
[06:12] <ubot2> Launchpad bug 972122 in partman-partitioning "Ubiquity pops out a warning message from partman-partitioning on UEFI BIOS when there is a EFI system partition existed." [Undecided,New]
[08:16] <twb> cjwatson: I just noticed that on my (allegedly) UEFI/BIOS hybrid mobo, with a 3TB disk, d-i uses grub-pc.  Is there a way to tell it to try using grub-efi instead?
[08:40] <cjwatson> twb: Ti> sorry, I think the parser is currently too stupid for that
[08:40] <cjwatson> FourDollars: thanks
[08:41] <FourDollars> cjwatson: np
[08:41] <cjwatson> twb: if you want it to use grub-efi, boot the installer itself in UEFI mode
[08:41] <twb> How do you do that
[08:41] <twb> I'm booting from a PXE rom
[08:42] <twb> I'm curious; I don't have a practical reason to touch UEFI until vendors start dropping BIOS support
[08:42] <cjwatson> PXE is a BIOS thing, IIRC; UEFI has its own netbooting arrangements
[08:43] <cjwatson> it's a lot easier to do from CD right now
[08:43] <FourDollars> There might be an "UEFI network" boot entry.
[08:43] <twb> Well fuck
[08:43] <cjwatson> no I suspect that we don't actually provide terribly UEFI-friendly d-i netboot packagings right now, so it's some assembly required
[08:43] <twb> FourDollars: there isn't.  The UEFI shell isn't even available unless I install a hard disk and (presumably) copy data from the mobo CD that the vendor forgot to send me
[08:46] <twb> if I already have the installed system booting under BIOS, can I just swap grub-pc for grub-efi-amd64 and follow the bouncing ball?
[08:50] <twb> Ah, apparently grub-efi absolutely requires a separate EFI partition
[08:51]  * twb wanders off to do some reading
[09:16] <twb> cjwatson: precise is better at aligning stuff (to avoid write amplification) than lucid is, right?  If I do a fresh install today, is it worth doing gpt/mdadm/lvm in precise partman, then reboot and tell lucid to reuse that layout?
[09:18] <cjwatson> possibly a bit due to bug fixes, although I thought I got most of the alignment stuff into lucid
[09:19] <twb> OK.
[09:19] <twb> I did ask precise's parted and it said they were optimally aligned, but I didn't believe it :-)
[09:20] <twb> I may have just been remembering hardy, but I'm pretty sure at least one of my lucid installs has shitty write amp
[09:22] <twb> http://paste.debian.net/161860/ iostat 30, eliding zero-I/O LVs
[09:22] <twb> Not as bad as I remember...
[09:23] <twb> (That's RAID1 not RAID5 btw)
[12:00] <CIA-32> ubiquity: cjwatson * r5350 trunk/ (debian/changelog debian/rules tests/run):
[12:00] <CIA-32> ubiquity: Work around LP #972324 by unsetting TMPDIR for xvfb-run and setting it
[12:00] <CIA-32> ubiquity: again for the inferior command.
[12:00] <ubot2> Launchpad bug 972324 in xorg-server "server fails to start up if TMPDIR is set to something on a different filesystem from /var/lib/xkb" [Undecided,New] https://launchpad.net/bugs/972324
[12:01] <CIA-32> ubiquity: cjwatson * r5351 trunk/debian/ (changelog tests/unit): Fix DEP-8 control file to stop trying to run Xvfb inside Xvfb.
[13:10] <CIA-32> ubiquity: cjwatson * r5352 trunk/debian/changelog: releasing version 2.10.6
[16:27] <cr3> ev: is there a trick to stop an automated install with ubiquity near the success_command?
[16:53] <ev> cr3: can you elaborate on what you're trying to do?
[17:57] <cr3> ev: I'm trying to troubleshoot a networking issue where the success_command can't seem to resolve domains
[17:58] <ev> and you want to jump in at that point? Why not just put a sleep inf in?
[17:59] <cr3> ev: that could work as well, I'll try that. thanks!
[17:59] <ev> sure thing
[19:46] <aperson_> Anyone have a pointer to the source code for the dhclient used by the installer?
[20:15] <superm1> cr3: if i was going to guess, /target/etc/resolv.conf isn't populated and you might need to copy /etc/resolv.conf into /target/etc/resolv.conf if that's the problem
[20:25] <cr3> superm1: the installed environment is fine, the problem seems to be a bug in casper when doing  network install where the success_command doesn't have any networking because 23networking sets the network interface to manual
[20:25] <superm1> oh
[20:25] <cr3> superm1: so, unless the nameserver is set explicitly somewhere in the preseed or somesuch, all network installs using casper can no longer rely on their dhcp server to provide nameserver information
[20:26] <cr3> superm1: this is a recent bug introduce a month or so ago in precise :(
[20:27] <cr3> obviously, nobody is insane enough to network install a live environment, so we're the only ones hit by that problem :)
[20:27] <superm1> cr3: if it's a recent bug, caused by r990 perhaps of casper bzr?
[20:29] <cr3> superm1: thanks for the heads up on that revision, I've taken a note to look into it tomorrow
[20:30] <superm1> sure np.
[21:41] <cjwatson> aperson_: You might be looking for debian/tree/busybox-udeb/usr/share/udhcpc/default.script in the busybox source package.
[21:41] <cjwatson> ./debian/tree/busybox-udeb/usr/share/udhcpc/default.script:76:          printf "$domain" > /tmp/domain_name
[21:41] <cjwatson> (Yes, it's a slightly shonky arrangement.)
[22:18] <aperson_> @cjwatson: I've narrowed it down to that dhclient-script is call with BOUND and correctly sets the resolv.conf file, BUT soon after that it gets undone. It's undone by time killall.sh is called. I've been purrusing the dhclient code to see if I can get a clue. But I'm not a C programmer.