Bug#441033: parted does not undestand GPT/MBR hybrid
Osamu Aoki
retitle 441033 parted breaks GPT/MBR hybrid system (Intel Mac)
thanks
Hi,
When updating GPT partition table, parted assumes system is pure EFI
booted with GUID partition table (GPT). This is not the case for Intel
Mac or other newer MOBO if the user wishes to use BIOS emulation.
parted has 2 problems here:
* It erase first 444=(512-2-64-2) bytes where classic MBR bootloader is
installed. --> It should preserve it (at least when hybrid partition
is found)
* It erases partition data for /dev/sda2, /dev/sda4, and /dev/sda4
stored in the last part of MBR. --> It should update it following
updated GPT data like gptsync does for hybrid partition.
I suggest to add one more mklabel option: something like "gpt-hybrid"
For system with matching initial partition tables between GPT and MBR,
assume it as "gpt-hybrid".
For system with non-zero byte at the first byte of disk with GPT, ask
user about updating MBR contents if it is not in sync.
For "gpt-hybrid" system, never over write first 444=(512-2-64-2) bytes
and always update last 64+2 bytes by GPT configuration just like gptsync
in refit source package does. (I guess borrowing it into parted is good
idea.)
For people looking for workaround for debian-installer, see
http://wiki.debian.org/MacBook/DebianInstallTutorial
As for the original bug reporter's complain that partition type is the
same as windows, it seems it is by design. As I see
http://en.wikipedia.org/wiki/GUID_Partition_Table
under "Partition entries (LBA 2–33)", both OS uses "Partition type GUID"
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
Thus no way to distinguish them apart. If the original reporter does
not like message given by other partitioning tools such as gptsync
reporting it as "EFI System (FAT)", he needs to complain to that
program. msftres seems to be some macOS thingy though.
Cheers,
Osamu
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Osamu Aoki
Excuse me. I took a look at more carefully...
As for the original bug reporter's complain that "partition type of linux
is wong" is correct. As I use gptsync
osamu@snoopy:~$ sudo gptsync /dev/sda
Current GPT partition table:
# Start LBA End LBA Type
1 40 409639 EFI System (FAT)
2 409640 33701927 Mac OS X HFS+
3 33964072 100810791 EFI System (FAT)
4 101072936 134365223 EFI System (FAT)
5 134627368 142753831 EFI System (FAT)
6 143015976 147210279 Basic Data
7 147210280 156301447 Linux Swap
Current MBR partition table:
# A Start LBA End LBA Type
1 1 409639 ee EFI Protective
2 409640 33701927 af Mac OS X HFS+
3 * 33964072 100810791 83 Linux
4 101072936 134365223 83 Linux
Status: Tables are synchronized, no need to sync.
As I check gptsync source and http://en.wikipedia.org/wiki/GUID_Partition_Table
"Partition type GUID" gptsync
C12A7328-F81F-11D2-BA4B-00A0C93EC93B "EFI System (FAT)"
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 "Basic Data" <<< This is for linux/windows data
As I see parted source for gpt.c, it looks right
#define PARTITION_BASIC_DATA_GUID \
((efi_guid_t) { PED_CPU_TO_LE32 (0xEBD0A0A2), PED_CPU_TO_LE16 (0xB9E5), \
PED_CPU_TO_LE16 (0x4433), 0x87, 0xC0, \
Then I realized what OP meant by msftres.
But following looks strange:
if (fs_type) {
if (strncmp (fs_type->name, "fat", 3) == 0
|| strcmp (fs_type->name, "ntfs") == 0) {
gpt_part_data->type = PARTITION_MSFT_RESERVED_GUID;
return 1;
}
...
gpt_part_data->type = PARTITION_BASIC_DATA_GUID;
Also I am not sure why there is no ext2/ext3. If it is designed to pass this section, then
gpt_part_data->type = PARTITION_BASIC_DATA_GUID;??? So parted should
set ext2/et3 to EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 "Basic Data"
instead. There is something funny...