automatic partitioning broken on Intel Macs

As discussed, the system had gotten into a very strange state before the prior logs were attached. I booted the OS X installer disc, "erased" the drive, and re-ran debian-installer. I ran the manual partitioner to verify the format was similar to that I experienced in my first attempt to install, which it was (so the system should be restorable to this point repeatedly). I then tried to reformat the hfs+ parition for LVM, which failed. More logs attached.

I've identified two distinct problems here, which I would like to fix for beta-1 if at all possible. I'm leaving the debian-installer task as Confirmed for the time being because I'm not absolutely sure I've got all the pieces, but the ones I have identified are high-value.

The first problem is that, when we create an Apple-specific synced MBR for a GPT label which contains a bios_grub partition, the corresponding MBR partition table entry is not given the 0xEE partition type. This means that the Linux kernel will refuse to recognise this as a valid GPT label, completely breaking installation. I believe this is an easy fix in parted.

The second problem is one I noted in a comment in partman-auto a while back: the automatic label detection that decides whether we need to create a bios_grub partition during automatic partitioning does not work with partman-auto-lvm. This should be a matter of making sure that we're in an appropriate subdirectory of /var/lib/partman/devices/ before calling decode_recipe.

Should I mention that issue also affects non-automatic and non-LVM partitioning, using named above tools.
Refer to https://bugs.launchpad.net/bugs/538100 for more details.

Yeah, I know. I discussed this with Emmet on IRC although apparently wasn't particularly clear in my comment.

In fact, on further testing I see that a stray & introduced during the parted 2.1 merge means that we're writing out some basically completely random memory (well, within libparted's heap, but that's about as far as it goes) as the synced MBR! Removing that makes things rather happier. I'll make every effort to get at least this part fixed in beta-1.

This bug was fixed in the package parted - 2.2-1ubuntu3

---------------
parted (2.2-1ubuntu3) lucid; urgency=low

  * gptsync.patch (update): Set OSType 0xee (same as EFI System Partitions)
    for bios_grub partitions, since otherwise the Linux kernel won't
    recognise us as GPT on Apple systems. Also remove a stray & which
    completely broke GPT syncing on such systems (LP: #538536).
 -- Colin Watson <email address hidden> Mon, 15 Mar 2010 00:41:43 +0000

LVM autopartitioning is working for me now on a simulated Apple system, but it's only by a freakish cancelling out of bugs. I think it can stay as it is for beta-1, but I want to clean this up for beta-2.

Install attempted with the 20100315 server CD, from the system state left after the last install attempt. Process was to attempt a manual LVM install, which failed. Then to attempt guided LVM install, which succeeded in completing the installation, but did not result in a bootable system.

This bug was fixed in the package partman-auto-lvm - 33ubuntu3

---------------
partman-auto-lvm (33ubuntu3) lucid; urgency=low

  * Don't force the envelope partition to be primary. The consequence of
    this change should be that /boot ends up at the start of the disk again,
    where it belongs.
  * Ensure that we're in an appropriate subdirectory of $DEVICES when
    decoding the recipe (LP: #538536).
 -- Colin Watson <email address hidden> Wed, 31 Mar 2010 16:08:04 +0100

This bug was fixed in the package partman-auto - 89ubuntu4

---------------
partman-auto (89ubuntu4) lucid; urgency=low

  * Ignore $iflabel{ } specifiers if we aren't in a subdirectory of $DEVICES
    when decoding the recipe (LP: #538536).
 -- Colin Watson <email address hidden> Wed, 31 Mar 2010 16:12:08 +0100