[10:52] <ev> cjwatson: thanks for fixing my retranslation bug
[10:52] <ev> r3920, that is
[10:53] <cjwatson> s'ok, was just looking for easy crash bugs to hoover up
[12:16] <happyaron> hi, could you have a look at this bug? https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/523789
[12:21] <cjwatson> happyaron: in future, please attach logs as separate files, it's easier for us
[12:23] <cjwatson> happyaron: looks like a consequence of bug 527641, which is fixed.  please try to reproduce with a current daily build
[12:25] <happyaron> cjwatson: oh thanks.
[12:26] <cjwatson> happyaron: heh, of course, the current daily doesn
[12:26] <cjwatson> 't have Chinese language packs on the CD
[12:27] <cjwatson> so you probably won't be able to tell.  In your logs, it tried to download them and failed
[12:28] <happyaron> cjwatson: but when you log out and select zh_CN at gdm, it will display in zh_CN
[12:28] <happyaron> cjwatson: I mean the bug is that the installer does not use the language pack that is already in the CD
[12:29] <cjwatson> happyaron: you misunderstand me
[12:30] <happyaron> ?
[12:30] <cjwatson> happyaron: the CD you were previously testing may have had Chinese language packs on it - but the *current daily build* does not
[12:30] <happyaron> oh
[12:30] <happyaron> see it
[12:30] <cjwatson> and as a result, you won't be able to tell whether or not this bug is fixed :(
[12:31] <happyaron> cjwatson: let me ask pitti soon about this issue, he told it will be included
[12:31] <cjwatson> langpacks are often dropped due to CD space constraints
[12:31] <cjwatson> pitti added the Chinese langpacks, and then had to remove them again later
[12:31] <cjwatson> this sort of thing always fluctuates throughout the release
[12:32] <happyaron> oh
[12:32] <cjwatson> it's not a bug in itself, we just can't physically fit everything in, and we try to prioritise as best we can but some people are always bound to lose out
[12:32] <happyaron> yes
[12:32] <cjwatson> looking at the current list, it should be testable with Spanish or Portuguese
[12:33] <cjwatson> or with German or Bengali on i386 onoly
[12:33] <cjwatson> only
[12:33] <happyaron> oh, my arch is amd64, and install with harddisk
[12:33] <cjwatson> is that "install to hard disk"?
[12:34] <cjwatson> (I'm sure my Chinese is much worse than your English - I just want to make sure I know what you mean)
[12:34] <happyaron> no
[12:34] <happyaron> I put the iso on hard disk
[12:34] <cjwatson> oh, that's not supported anyway *shrug*
[12:34] <cjwatson> if it works, you got lucky
[12:34] <happyaron> and use grub's function to load it.
[12:34] <happyaron> the installation works
[12:34] <cjwatson> like I say - you got lucky.  we may break that in the future.
[12:34] <happyaron> heh
[12:35] <cjwatson> the reason it's not supported is that having anything mounted off the hard disk means that the partitioner may have trouble in some cases
[12:35] <cjwatson> not in all cases, which is presumably why you got lucky
[12:35] <happyaron> oh
[12:35] <cjwatson> but we don't promise that this installation method will work
[12:35] <happyaron> I used umount -l /isodevice
[12:35] <cjwatson> doesn't matter
[12:35] <happyaron> and LiveCD can work
[12:35] <happyaron> but alternate cannot
[12:36] <cjwatson> if it works, good for you, if not, please don't complain :)
[12:36] <happyaron> yes I know
[12:36] <cjwatson> anyway, *probably* not really relevant to this bug as such
[12:36] <happyaron> yes
[13:04] <CIA-3> console-setup: cjwatson * r137 ubuntu/ (Keyboard/KeyboardNames.pl debian/changelog): releasing version 1.34ubuntu11
[18:55] <persia> I'm trying to install lucid server on a machine that requires EFI, using LVM, and it seems to skip setting up physical volumes for my volume group.  Does anyone have suggestions on how to investigate this?
[19:10]  * persia stops hunting and just formats the disk manually.
[19:39] <cjwatson> persia: no reason why that should be the case AFAIK; I would've started by putting 'set -x' in /lib/partman/lib/lvm-base.sh to dump out a full trace
[19:40] <persia> cjwatson: I'll try that, since I failed utterly at manual partitioning (no GPT support in fdisk, no parted available in default server install environment).
[19:40] <cjwatson> the only thing I can think of is that maybe VALID_FLAGS doesn't say lvm on gpT
[19:40] <cjwatson> GPT
[19:40] <cjwatson> even just /var/log/partman ought to expose that if that's the case
[19:40] <cjwatson> no parted available> anna-install parted-udeb
[19:40] <persia> But I'm currently finding kernel errors reading the partition table, and am trying to figure out if GPT is even supported by the -server kernel.
[19:41] <cjwatson> that might be another known parted issue ...
[19:42] <cjwatson> debian.master/config/config.common.ubuntu:1018:CONFIG_EFI_PARTITION=y
[19:42] <cjwatson> so all Ubuntu kernels should support GPT
[19:43] <cjwatson> my VALID_FLAGS hypothesis looks wrong
[19:47] <persia> anna-install worked great.  Since I first failed, I also tried a completly automated partitioning (guided, use whole disk), which also failed.  Would it be useful for me to start over again from scratch, attempt the LVM format, and file a bug with the logs?
[19:47] <cjwatson> yes please
[19:47] <cjwatson> it's interesting that plain whole-disk partitioning failed
[19:47] <cjwatson> it *might* be easier to debug that first
[19:48] <persia> OK.  I'll start with that case.
[19:48] <persia> Would it be useful for me to leave this machine uninstalled for now, and be a test case for you during the week?
[19:48] <cjwatson> if it's feasible for you to do so, yes
[19:48] <cjwatson> if there's a possibility that GPT is Just Broken, I want to stomp on that quickly
[19:49] <persia> Certainly.  It's a remote build server that I wanted to use to reduce load on my laptop, but it can wait for a few days.
[19:50] <cjwatson> were you selecting GPT manually in any way?
[19:50] <persia> No.  The disk came that way.
[19:52] <persia> Just to make sure I'm preparing good logs.  Once I get the error page ("Failed to create a file system"), do I just extract /var/log/parted and /var/log/syslog, or do I need to go back to the main menu first?
[19:53] <cjwatson> go back to the main menu first
[19:53] <persia> Thanks.
[19:53] <cjwatson> (and /var/log/part*man*, fwiw)
[19:54] <persia> Sorry.  I get a little sloppy at 5am.
[19:54]  * cjwatson tries a quick GPT install
[19:55] <cjwatson> bit tedious since if the "natural" format for the disk is MBR then you have to use expert mode
[19:56] <cjwatson> hmm.  thinking about it it's a bit silly that we force the biosgrub partition to be aligned
[19:56] <cjwatson> (don't mind me, just thinking out loud)
[19:57] <persia> Is that why I had all those strange <1MB bits of free space?
[19:59] <cjwatson> oh, those are showing up as free space?  we should suppress those somehow
[19:59] <cjwatson> maybe align the ends of new partitions too
[20:01] <cjwatson> actually it's odd that that didn't happen already
[20:01] <cjwatson> hopefully the logs will elucidate
[20:02] <persia> I just hope I didn't mess something up by fiddling with it previously.
[20:02] <cjwatson> we align to 1MiB boundaries a lot of the time now, because that's what various other things are coming to require, and it makes sure that we don't radically degrade performance when moved from disk to disk
[20:02] <cjwatson> with different topologies
[20:03] <persia> This makes sense, but the small bits look messy.  We should hide those, if we can.
[20:04] <cjwatson> we shouldn't actually end up with small bits, in general
[20:04] <cjwatson> if we align both start and end (which I thought we did, looking at the code), they should match up
[20:04] <cjwatson> anyway, will look at logs
[20:04] <persia> It's bug #538536
[20:05] <cjwatson> ok, thanks
[20:05] <persia> The leftover bits might have been because I tried to leave the original EFI partition alone.
[20:05] <persia> I'll just shut the machine down: let me know if you want me to play with it more.  I'd rather not construct too many CDs, because it doesn't have a boot-from-USB feature.
[20:35] <cjwatson> bug 538100 may be related
[20:36] <cjwatson> though I'm not *entirely* confident in the analysis there
[20:41] <persia> I suspect the original partition map was created in OS X, or by initialising a factory disk with a partition map from an OS X install.
[20:42] <persia> That analysis matches what I found from searching, which indicated that we use a "legacy mode" for GPT.  No idea how true that is, and one of the pages I found included a comment from you actively disagreeing with the suggestions.
[20:44] <cjwatson> the analysis is bogus for a reason I'm about to explain
[20:46] <cjwatson> posted.  now to see how much this applies to your bug.  I see you're on an Apple system
[20:47] <persia> Yes.
[20:48] <cjwatson> so, you indeed don't have an EFI System Partition (no FAT partition with the 'boot' flag set)
[20:48] <persia> I used to have one of those.  It got et.
[20:48] <cjwatson> which means ultimately that the kernel won't recognise your GPT table as valid
[20:48] <cjwatson> what happened to it?
[20:48] <persia> I'm not sure.
[20:49] <persia> It was there on first install attempt.
[20:49] <persia> It wasn't there after first Guided Install (entire disk) attempt.
[20:49] <cjwatson> it's not entirely obvious that it's there at the start, although it could be the one that's labelled "unknown".  I wonder why I see no evidence of the "boot" flag, though
[20:50] <cjwatson> do you know which partition it was at the start?
[20:51] <cjwatson> sda2 perhaps?
[20:51] <persia> Yes.
[20:51] <persia> Well, not quite.
[20:51] <cjwatson> that's kind of hyooge
[20:51] <persia>  /dev never showed any partitions for it
[20:51] <persia> But it was the second partition listed in the partman interface.
[20:52] <cjwatson> sda2 at the start of your installation is a 308GB partition
[20:52] <cjwatson> second, after a bit of free space?
[20:52] <persia> Originally, yes.
[20:53] <cjwatson> right, so sda1
[20:53] <persia> After doing the Guided Install, I lost that partition.
[20:53] <cjwatson> so two problems: (a) your original EFI System Partition wasn't detected as fat32, let alone as an ESP (b) autopartitioning didn't create an ESP
[20:54] <cjwatson> I guess there's no way to restore to the original state?
[20:55] <persia> I can take it to the shop and tell them it's broken.
[20:55] <persia> I could try an OS X install.
[20:55] <persia> Dunno if either of those really gets it to factory-original state.
[20:56] <cjwatson> an OS X install would probably be enough, though was that what was on it to start with?
[20:56] <cjwatson> the original state was: (some random partition, maybe efi system; big fat32; linux-swap)
[20:57] <persia> I presume so.  I try to avoid booting vendor-supplied operating systems.
[20:57] <cjwatson> fat32 doesn't sound characteristic of os x
[20:57] <persia> Indeed.  That doesn't sound like the original state.
[20:57] <cjwatson> nor does linux-swap for that matter :-)  that's a weird pairing
[20:58] <cjwatson> that's what PARTITIONS said at the start of your partman log.  did you boot d-i multiple times?
[20:58] <persia> I'll try to dig up the "restore" disk, and see if I can do a fresh install of OS X, and then an install of Ubuntu and replicate the issue.
[20:58] <persia> Thrice.
[20:58] <cjwatson> aha.
[20:58] <persia> Once with the LVM failures.
[20:58] <persia> Once again to try Guided Partiitioning.
[20:58] <persia> And then again to repeat the Guided Paritioning to get logs.
[20:58] <cjwatson> so that 1mb partition at the start might actually have been a biosgrub partition
[20:58] <persia> But I think I won't do that again :)
[20:59] <cjwatson> I think they're all the same thing
[20:59] <persia> That name sounds familiar.
[21:09] <persia> (one of) the problems with OS X is that it requires a mouse to install :(
[21:09] <cjwatson> so I can easily correct part of this in parted.  the tricky bit is identifying bios_grub partitions on the way in; they're essentially just data containers.
[21:26] <cjwatson> oh, and I left myself a comment a while back to note that the automatic creation of bios_grub partitions doesn't work with automatic LVM partitioning
[21:26] <cjwatson> for tedious internal reasons
[21:27] <persia> aha!  That's probably the issue with the guided parition then.
[21:27] <persia> The OS X reformat dance seems to have put back the original state.  LVM failure logs attached.  Shall I again restore state, and try Guided?
[21:30] <cjwatson> I don't think I should need that immediately - the original state was what I was most interested in
[21:33] <cjwatson> I think I have enough now to be going on with.  Thanks!
[21:33] <cjwatson> I'll ask you when I have something ready for testing
[21:34] <persia> Sure.  Thanks for jumping on this at such an hour.
[22:52] <cjwatson> persia: fortunately, there are hacks that allow me to reproduce this without having to sacrifice the Apple system that my wife is actively using at the moment ...
[22:55] <persia> excellent.  local repoduction is always best.
[22:57] <cjwatson> (documented in https://wiki.ubuntu.com/Installer/Development/Tips now)
[22:57] <persia> But do let me know if there's something you want me to run, or test.  I don't mind holding off finishing the install, and contrary to popular wisdom, believe Apple has the best price/volume ratio in small machines right now (the alternatives were larger, pricer, or not amd64-compatible).
[22:58] <cjwatson> I will certainly want an end-to-end test after fixing the issues I can reproduce
[22:59] <persia> OK.  I'm heading off to have a day soon, so it'll have to be during the week.
[23:00] <cjwatson> yup
[23:01] <cjwatson> thanks for the help so far
[23:02] <persia> By helping each other we help ourselves :)  I perceive this as you spending a lot of time helping me get my build server installed.  Thanks! :)
[23:02] <cjwatson> heh