Warning: iPartion does partitioning OSX86 but AHCI Probs

[mitch_de]

Hi,

i figured out (twice) that using iPartition (3.2) may harm your AHCI native boot!

Perhaps that happens only to MBR HDs not GUID. I tested it only twice with MBR Part Type.

 

It does repartitioning as it should (no problems !) but after that something wents wrong with very low level things (i believe MBR).

- At next boot time BIOS hangs if running in AHCI native Mode, only non AHCI Mode Boot working

- You even cant get into the BIOS Setup (DEL) to disable AHCI native , because BIOS hangs

- You must first disconnect the HD and boot again in BIOS Setup, switch AHCI off, shut down, connect HD again

- Now it boots and you have access to the HD at least in Windows (waiting for root in OS X because non AHCI Mode). Partitions + DATA are OK

My solution:

Booting from Paragon 10 DISK (Paragon 10 supports also HFS+) , switch into Full Mode (leaf Restore Mode) , select the HD and update MBR (sure only for MBR disks!)

Now you can boot again with AHCI Mode ON - but as you guess MBR update overwritten Chameleon , so you must boot from an other HD in OS X and reinstall Chameleon on the other HD.

 

Paragon Boot CD (Version 9+, better 10) also very usefull to set an partition active. Normally chameleon installer do this (fdisk commands).

 

Beside thar major AHCI BIOS hang, all Data and partitions , untouched by Paragon, iPartition worked and got repartitioned (resize + add an partition) .

[pet1]

When creating a new partition. Sometimes you have to do just that. Rebuild mbr on the disk. You can still do all of this in ipartition I believe. For guid and mbr. There is an option to write mbr code to disk. You're going to have to install your boot loader again though after you do that. You may wanna take note for the future. I came across this on my own in the 5 years I've been involved with osx86.

[mitch_de]

When creating a new partition. Sometimes you have to do just that. Rebuild mbr on the disk. You can still do all of this in ipartition I believe. For guid and mbr. There is an option to write mbr code to disk. You're going to have to install your boot loader again though after you do that. You may wanna take note for the future. I came across this on my own in the 5 years I've been involved with osx86.

 

Yep i know this . MBR may sometime be overwritten or no active partition is set : OS X boot problems / bots from wrong partition.

 

THat BIG NIGHTMARE is different: You cant boot ANY system (not from HD, not from CD) when the BIOS is hanging/freezes in the AHCI BIOS part.

AHCI BIOS shows Port 0...x and then waits for ever at bios boottime!

You cant even disable AHCI native, because BIOS hangs (you cant get in the bios setup! until you disconnect the "problem" HD)

Maybe an bug in the 1.20E Version (i have on Gigabayte MB).

Pagagon bootet from CD, (after setting AHCI Mode of and reconnect the "bad" HD) didnt show the HD Name anymore (WD 27893489H2, Seagate F3,...). So something bad on low level actions must be done by iPartition. After updating MBR with Paragon that HD Name was shown again and also AHCI Native didnt hang/freeze the AHCI native at boot time (i mean BIOS boot time!).

 

Beside that AHCI boot hang , iPartition does all other things well - no data lost and also the shinked partition + new partition worked.

So something at very lowlevel (MBR , other low level things) may be the problem at least for MBR type HDs.

[firefox-bin]

I had this problem several times. Each time I would physically disconnect the disk, boot to linux and reconnect the drive on a live system. I would then see the disk and partitions under /dev/sdb1, /dev/sdb2, etc. Actually, I don't even remember now what I did in linux to get past the frozen BIOS upon the next reboot.

 

Anyhow, I think I have located the source of the problem and how to fix it immediately after using iPartition (from Mac OS X, of course). I had previously run fdisk -u /dev/rdisk1 to restore the MBR after using iPartition but to no avail. So it must be that iPartition is messing with the MBR partition table in such a way that was confusing the BIOS. So immediately after I used iPartition today, I looked at the partition table (it's a GPT disk so the MPT shows only one partition that spans the entire disk):

$ sudo fdisk /dev/rdisk1
Disk: /dev/rdisk1	geometry: 121601/255/63 [1953525168 sectors]
Signature: 0xAA55
        Starting       Ending
#: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
1: EE 1023 254 63  - 1023 254  63 [         0 -   16450560] <Unknown ID>
2: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
3: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
4: 00    0   0   0 -    0   0   0 [         0 -          0] unused  

The first partition entry looked suspicious to me. Maybe the starting CHS of 1023/254/63 is too far out in the disk for the BIOS to handle (it's a 1 TiB disk). Thereafter I edited the MPT by running fdisk in the edit mode as fdisk -e /dev/rdisk1 and edited the entry for partition 1 as:

sudo fdisk /dev/rdisk1
Disk: /dev/rdisk1	geometry: 121601/255/63 [1953525168 sectors]
Signature: 0xAA55
        Starting       Ending
#: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
1: EE    0   0   1 - 1023 254  63 [         0 -   16450560] <Unknown ID>
2: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
3: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
4: 00    0   0   0 -    0   0   0 [         0 -          0] unused  

 

viola! no more BIOS hangs upon subsequent reboots!

[Krazubu]

You can run gptsync after the modifying the partitions to get a clean MBR.

[MrZeroo00]

Have you guys ever tried to convert MBR to GUID (GPT) with iPartition ? I'm a little bit afraid.

[mitch_de]

You can run gptsync after the modifying the partitions to get a clean MBR.

Isnt that pnly for GUID type HDs not MBR type ?

How can i use that under OS X ?

 

ami$ gptsync --help

gptsync 0.2

 

Usage: gptsync [OPTION]... DEVICE [PARTITION[+/-[TYPE]]] ...

 

gptsync fill hybrid MBR of GPT drive DEVICE.

 

Specified partitions will be a part of hybrid MBR. Up to 3 partitions are allowed.

+ means that partition is active (only one partition can be active).

TYPE is an MBR hexadecimal type (use -t option to list recognized types).

 

Valid options:

-e, --empty create an MBR containing only the EFI Protective partition

-n, --nofill don't try to protect unused partition

-t, --types list the MBR recognized type codes

-h, --help display this message and exit

-V, --version print version information and exit

 

example: sudo ./gptsync /dev/disk1 1 2+af

hsi-kbw-078-042-003-227:~ ami$ gptsync -t

gptsync MBR recognized types:

   01  FAT12 (CHS)
   04  FAT16 <32M (CHS)
   05  Extended (CHS)
   06  FAT16 (CHS)
   07  NTFS/HPFS
   0b  FAT32 (CHS)
   0c  FAT32 (LBA)
   0e  FAT16 (LBA)
   0f  Extended (LBA)
   11  Hidden FAT12 (CHS)
   14  Hidden FAT16 <32M (CHS)
   16  Hidden FAT16 (CHS)
   17  Hidden NTFS/HPFS
   1b  Hidden FAT32 (CHS)
   1c  Hidden FAT32 (LBA)
   1e  Hidden FAT16 (LBA)
   82  Linux swap / Solaris
   83  Linux
   85  Linux Extended
   86  NT FAT volume set
   87  NTFS volume set
   8e  Linux LVM
   a5  FreeBSD
   a6  OpenBSD
   a7  NeXTSTEP
   a8  Mac OS X UFS
   a9  NetBSD
   ab  Mac OS X Boot
   ac  Apple RAID
   af  Mac OS X HFS+
   be  Solaris Boot
   bf  Solaris
   eb  BeOS
   ee  EFI Protective
   ef  EFI System (FAT)
   fd  Linux RAID

[srs5694]

Anyhow, I think I have located the source of the problem and how to fix it immediately after using iPartition (from Mac OS X, of course).

...

I looked at the partition table (it's a GPT disk so the MPT shows only one partition that spans the entire disk):

$ sudo fdisk /dev/rdisk1
Disk: /dev/rdisk1	geometry: 121601/255/63 [1953525168 sectors]
Signature: 0xAA55
        Starting       Ending
#: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
1: EE 1023 254 63  - 1023 254  63 [         0 -   16450560] <Unknown ID>
2: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
3: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
4: 00    0   0   0 -    0   0   0 [         0 -          0] unused  

The first partition entry looked suspicious to me. Maybe the starting CHS of 1023/254/63 is too far out in the disk for the BIOS to handle (it's a 1 TiB disk).

 

That's the way that OS X's Disk Utility creates the protective partition by default, so if you used Apple's utilities to partition the disk in the first place, it's not likely to be the problem. OTOH, this is contrary to the GPT specification, and I have run into a problem with one BIOS that chokes on disks with improper CHS geometries (by the usual MBR standards), as described here.

 

Also and FWIW, the specified CHS geometry works out to a bit under 8 GiB. That's one of the reasons that CHS has been abandoned, even on MBR-only computers; it's limited to such a small size that it's only accurate for smallish USB flash drives any more.

 

You can run gptsync after the modifying the partitions to get a clean MBR.

 

I'd argue that using gptsync creates a very unclean MBR, in that it's no longer valid from a strict GPT perspective. Using gptsync creates a hybrid MBR, which is an ugly and dangerous hack that Apple uses to enable Windows to boot on Macs, and that's also commonly employed in the Hackintosh community to simplify installing OS X on PCs. The GPT specification, though, clearly makes hybrid MBRs illegal.

 

That said, if you already rely on a hybrid MBR, running gptsync after making changes to your GPT partitions is probably in order. If you change your GPT partitions but don't change your MBR partitions, the two partition tables could contradict each other, which could lead to an MBR-using OS (such as Windows) attempting to write into a part of the disk it shouldn't.

 

Have you guys ever tried to convert MBR to GUID (GPT) with iPartition ? I'm a little bit afraid.

 

I've never used iPartition, but my own GPT fdisk (gdisk) can convert from MBR to GPT. Compared to a lot of disk operations, such as partition resizing, it's really not a very difficult conversion to do. That said, any partitioning tool can do serious damage to a disk if it's abused or if it contains bugs. Thus, backing up before performing such an operation is always wise.

 

There's also the issue of booting after changing from MBR to GPT. Boot loaders intended for MBR-based systems seldom or never work on GPT-based systems, so you'll need to update your boot loader. (I don't recall offhand how Chameleon works, but some, such as GRUB 2, have different sector-0 components for MBR and GPT disks, so re-installing the boot loader will cause the appropriate code to be written to the disk.)

 

(re: gptsync)

 

Isnt that pnly for GUID type HDs not MBR type ?

 

Yes. The gptsync program takes the first three GPT partitions (minus the EFI System Partition), or for some versions, up to three partitions that you specify, and creates a hybrid MBR that contains those three partitions and an EFI protective (0xEE) partition. As such, gptsync is useless on conventional MBR disks. At best it will do nothing. I've never tested it to see how it actually behaves on MBR disks.