#8 Partition sync creates FAT out of ext3

open-fixed
None
5
2006-12-27
2006-09-11
EdZaron
No

I am trying to install dual-boot linux/OS X on a new Mac Pro, running
10.4.7. Software update reports that my software is up to date.

Steps:
1) Used Boot Camp to create a 150GB windows partition (it complained
about max FAT32 size of 32 GB, but it seemed to work).
2) Installed rEFIt.
3) Used the Ubuntu Live/Install disk to boot into linux (required "irqpoll
no-hlt" boot options).
4) Created partitions and installed linux:
4.5) Output of parted print (from linux):
Disk geometry for /dev/sda: 0kB - 250GB
Number Start End File system Name Flags
1 20kB 210MB fat32 EFI System Partition boot
2 210MB 88GB hfs+ Customer
3 88GB 93GB linux-swap
4 93GB 250GB ext3 boot

I followed the directions at http://bin-false.org/?p=1? to create the
partition tables, install linux, and install lilo.

4.6) The rEFIt Partitioning tool says:
Starting gptsync.efi

Current GPT partition table:
# Start LBA End LBA Type
1 40 40969 EFI System (FAT)
2 409640 172376103 Mac OS X HFS+
3 172376104 180762664 Linux Swap
4 180762665 488392064 EFI System (FAT)

Current MBR partition table:
[identical]

Status: Tables are synchronized. No need to sync.

5) When I first ran the EFI partition tool, it did re-sync the partition
tables, but unfortunately, I did not write down the initial state.

6) From OS X, "diskutil list" presents the same information as above.

Is there a means within rEFIt to correct the partition table from the
rEFIt/OS X perspective?

It would be great if you have time to help me with this. I read in
another post that you were looking for a Mac Pro account. I may be
able to help you with this.

Discussion

1 2 > >> (Page 1 of 2)
  • StarQuake
    StarQuake
    2006-11-04

    Logged In: YES
    user_id=1330168

    I'm having the same problem.

     
  • Logged In: YES
    user_id=932606

    macbook - the same problem

     
  • Logged In: YES
    user_id=1061789

    Same problem here on a MacBookPro2,2 (Core 2 Duo). The refit sync tool changes partition type in the MBR from 0x83 to 0xEF,
    which prevents lilo from booting from it. As a workaround, you can correct this using fdisk in Linux. The partition was originally
    created using diskutil in Mac OS X with type "Linux", but both "diskutil list" and refit now display it as "EFI" in the GPT.

     
  • Logged In: NO

    Same proble on Macbook Late 2006 (core 2 duo).
    Thanks for any detailed tip on fixing that (restore type and name) without harming existing partitions.

     
  • Logged In: YES
    user_id=51640
    Originator: NO

    If the GPT table lists the Linux partition as type "EFI System Partition", then that's the fault of the partitioning tool that last touched the GPT -- that would be either GNU parted or Apple's diskutil. rEFIt's gptsync does not change the GPT. It will, however, trust what's listed in GPT and sync that to the MBR. Since this is a common problem, I may implement a workaround for this special case in the next version.

    That said, you really want to file a bug against the partitioning tool that puts "EFI System Partition" (C12A7328-F81F-11D2-BA4B-00A0C93EC93B) in the GPT in the first place. (I suspect it's GNU parted. If Apple's diskutil was misbehaving that badly, there would be much more noise about this.)

     
    • assigned_to: nobody --> chrisp
     
  • Logged In: NO

    same problem ...

    Was working fine with version 0.7 but after a complete reinstall ... doesn't work with refit .8

     
    • status: open --> open-accepted
     
  • Logged In: YES
    user_id=51640
    Originator: NO

    I checked the GNU parted source code. Its GPT handling is horribly broken. The internal abstract "boot" flag that is used to represent the "active" partition in an MBR table is also interpreted by the GPT handling code, but in a very different way. When used on a GPT disk, parted sets the partition type of any partition with that flag to "EFI System", regardless of the filesystem actually contained in it. This is just plain stupid and also happens to violate the EFI spec.

    I've already added file system detection to gptsync, and I'll add workaround code for this situation as well, so in the next release of rEFIt at least the MBR table will get the right partition type. There's not much I can do for the GPT side without writing a massive amount of code. gptsync is designed to be one way only (GPT -> MBR), and not to fix bloody mistakes in other partitioning tools (parted in this case).

    Feel free to complain loudly to the GNU parted project and to your Linux distribution about this problem.

     
    • status: open-accepted --> open-fixed
     
1 2 > >> (Page 1 of 2)