[08:01] <tjaalton> should the installer recognize win8 and offer to resize the partitions?
[08:01] <tjaalton> I have a machine where it doesn't work, and I wonder how hard it would be to fix
[09:14] <cjwatson> tjaalton: in principle ntfsresize is meant to work, yes
[10:28] <tjaalton> cjwatson: right, I see ntfsresize output on the syslog, it has recognized the partitions
[10:32] <tjaalton> but the partitioner doesn't recognize that win is installed
[10:33] <tjaalton> *win8
[10:37] <cjwatson> Maybe ubiquity.misc.windows_startup_folder is wrong or something
[10:38]  * cjwatson guesses wildly
[10:43] <tjaalton> ah, checking
[10:43] <tjaalton> googling showed that this is a common issue
[10:43] <tjaalton> there's probably a bug about it too
[10:50] <tjaalton> bug 1079056
[10:50] <ubot2> Launchpad bug 1079056 in os-prober (Ubuntu) "ubiquity does not detect Windows 8(UEFI)" [Undecided,Confirmed] https://launchpad.net/bugs/1079056
[10:51] <cjwatson> Ah, well, that's pending merge
[10:51] <tjaalton> oh, cool
[10:51] <cjwatson> xnox: ^- you're touched-it-last on os-prober and I think there's a branch awaiting sponsorship, possibly
[10:51] <cjwatson> Wait, that landed 23 hours ago
[10:51] <tjaalton> heh
[10:52] <tjaalton> ok I'll try todays image
[10:52] <cjwatson> Yeah, please do, would be good to know if that's fixed
[10:52] <tjaalton> sounds sru material?
[10:52] <tjaalton> perhaps for 12.04.3
[10:53] <cjwatson> Probably
[10:53] <cjwatson> There's a grub2 fix that goes along with it
[10:53] <cjwatson> But I'd like to know that it all works as a unit in saucy first
[10:53] <tjaalton> right
[10:53] <tjaalton> I'll know in 20min :)
[11:40] <tjaalton> cjwatson: doesn't work with the current image, os-prober update is included
[11:41] <cjwatson> any legwork you can do to debug this would be appreciated; tends to be horrific to debug remotely ...
[11:41]  * cjwatson is currently trying to reproduce GrueMaster's oem-config bug from yesterday
[11:42] <tjaalton> yeah I'll have a look at os-prober..
[11:43] <cjwatson> First check whether os-prober detects Windows at all, I suppose; could be a multi-part bug and now ubiquity needs to be fixed
[11:44] <tjaalton> I get a grub-probe error for the usb-stick, that's it
[11:44] <cjwatson> OK, well os-prober itself is not too complicated to debug
[11:49] <tjaalton> hmm how to enable the debug output?
[11:51] <cjwatson> You'll find it in syslog
[11:54] <tjaalton> eh, 05efi skips ntfs partitions
[11:54] <tjaalton> os-probes/mounte/05efi that is
[11:55] <cjwatson> The EFI System Partition isn't normally allowed to be NTFS
[11:55] <tjaalton> ah, well here it is
[11:55] <cjwatson> Note EFI System Partition != Windows /, usually ...
[11:56] <tjaalton> ok, that wasn't it :)
[11:56] <cjwatson> But, OK, does it work if you add an ntfs condition there?
[11:56] <tjaalton> no
[11:57] <tjaalton> "$partition is not a ESP partition: exiting"
[11:57] <cjwatson> So - what makes you think that this partition is an EFI System Partition?
[11:59] <tjaalton> was looking at the wrong partition
[12:00] <tjaalton> it has five, sda1 ntfs, sda2 efi, sda3 unused, sda4 ntfs, sda5 ntfs
[12:01] <tjaalton> "sda2 is fat partition, exiting"
[12:01] <tjaalton> there
[12:01] <cjwatson> Ah, maybe this is a grub-mount thing
[12:01] <cjwatson> compare:
[12:01] <cjwatson> ./os-probes/mounted/x86/20microsoft:21: fat) debug "$1 is a FAT partition (mounted by GRUB)" ;;
[12:01] <tjaalton> adding fat to 05efi fixed it
[12:02] <cjwatson> I'll fix that upstream, then, thanks
[12:02] <tjaalton> cool, thanks
[12:06] <tjaalton> restarting ubiquity didn't go as planned :)
[12:07] <cjwatson> Requires fairly considerable care
[12:07] <cjwatson> Probably best to reboot though
[12:08] <tjaalton> I'll lose the os-prober hack then :)
[12:08] <cjwatson> Not if you reboot to a live session and reapply it first
[12:08] <tjaalton> ah
[12:08] <cjwatson> (Restarting can work if you make sure to kill all relevant processes and rm -rf /var/lib/partman)
[12:09] <tjaalton> oh well, rebooted already
[12:14] <tjaalton> hm, ubiquity still doesn't play along
[12:16] <cjwatson> Could be looking in the wrong partition - os-prober would be telling it about the ESP but that doesn't have the Windows startup folder on it
[12:16] <cjwatson> I forget how that gets matched up normally ...
[12:17] <cjwatson> ev might remember
[12:17] <cjwatson> Or xnox
[12:17] <cjwatson> infinity: I pushed our outstanding mklibs changes upstream - 0.1.37 will be syncable once it's available
[12:18] <tjaalton> ok so it's missing something else
[12:18] <tjaalton> since os-prober just lists the efi partition now
[12:20] <tjaalton> "skipping legacy bootloaders on uefi system"
[12:20] <cjwatson> Right, what I mean is that os-prober is indeed only going to list the ESP (correctly), but ubiquity needs to know how to figure out where the Windows root partition is from that
[12:20] <tjaalton> oh
[12:20] <cjwatson> os-prober is only supposed to list the things that it's actually sensible to boot
[12:20] <tjaalton> gotcha
[13:26] <cjwatson> GrueMaster: Ah, I may have a lead
[13:26]  * cjwatson tests
[13:34] <cjwatson> Bingo
[14:09] <cjwatson> GrueMaster: https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/precise-proposed/revision/5433
[14:10] <cjwatson> (tested, works for me, etc.)
[14:11] <cjwatson> and heading into the unapproved SRU queue now
[15:24] <GrueMaster> cjwatson: Awesome!  I'll apply the patch and test here.
[16:29] <GrueMaster> Tested in both VM and raw hardware with 12.04 (amd64).  This fixes the issue.  Thanks.
[16:30] <GrueMaster> I'll keep a local .deb with the fix until it gets into the pool.  Deployment can't wait for SRU process, but it will make our work a LOT easier (and gets Ubuntu Server out more on preinstalled systems).
[16:38] <cjwatson> Great.
[19:05] <infinity> cjwatson: Hah, d'oh.  I was considering backing some of my mklibs changes out, since we no longer have linkers that live in deep paths, but I guess there's no harm in keeping that path handling safer either.
[19:21] <cjwatson> Well, you can back it out in Debian if you like; but as you say ...
[20:29] <infinity> cjwatson: IIRC, didn't it require a coordinated change mirrored to something else at the same time?  rootskel or something?
[20:29] <infinity> cjwatson: (Which was why we didn't push it during the d-i freezes)
[20:29] <infinity> rootskel (1.101ubuntu1) raring; urgency=low
[20:29] <infinity>   * Resynchronise with Debian.  Remaining changes:
[20:29] <infinity>     - Remove the lib64 -> lib symlinks, no longer necessary with the new
[20:29] <infinity>       mklibs.
[20:29] <infinity> ^-- That change.
[20:34] <cjwatson> Was that actually necessary?
[20:34] <cjwatson> Or just expedient?
[20:35] <infinity> I don't remember if it blows up without that change or if it was just the right thing to do.