Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#10298 closed bug (fixed)

Creating GPT partition maps results in a "General system error"

Reported by: kallisti5 Owned by: axeld
Priority: normal Milestone: R1/beta1
Component: Partitioning Systems/GPT Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

This may be a duplicate, but I didn't see any close tickets.

Process:

  • Create GPT partition map on device in DriveSetup
  • Create a GPT partition (Haiku / BeOS) in DriverSetup
  • Receive general system error.

Can reproduce on any disk / usb disk

syslogs below:

KERN: EFI::Header: Initialize GPT, block size 512
KERN: EFI header: EFI PART
KERN: EFI revision: 10000
KERN: header size: 92
KERN: header CRC: 0
KERN: absolute block: 1
KERN: alternate block: 0
KERN: first usable block: 34
KERN: last usable block: 1465149131
KERN: disk GUID: 00000000-8e34-8020-04ba-0f80003c6391
KERN: entries block: 2
KERN: entry size:  128
KERN: entry count: 128
KERN: entries CRC: 0
KERN: KDiskDeviceManager::_ScanPartition(/dev/disk/usb/0/0/raw)
KERN:   trying: partitioning_systems/intel/extended/v1
KERN:   returned: -1
KERN:   trying: partitioning_systems/intel/map/v1
KERN: intel: pm_identify_partition(82, 8: 0, 750156372480, 512)
KERN: Error: Disk is GPT-formatted: GPT disks are currently unsupported.
KERN:   returned: -1
KERN:   trying: partitioning_systems/efi_gpt/v1
KERN: gpt: alternate header not in last block (0 vs. 1465149164)
KERN: EFI header: EFI PART
KERN: EFI revision: 10000
KERN: header size: 92
KERN: header CRC: -1948408414
KERN: absolute block: 1
KERN: alternate block: 0
KERN: first usable block: 34
KERN: last usable block: 1465149131
KERN: disk GUID: 00000000-8e34-8020-04ba-0f80003c6391
KERN: entries block: 2
KERN: entry size:  128
KERN: entry count: 128
KERN: entries CRC: 2874462854
KERN: EFI header: EFI PART
KERN: EFI revision: 10000
KERN: header size: 92
KERN: header CRC: -1948408414
KERN: absolute block: 0
KERN: alternate block: 1
KERN: first usable block: 34
KERN: last usable block: 1465149131
KERN: disk GUID: 00000000-8e34-8020-04ba-0f80003c6391
KERN: entries block: 18446744073709551584
KERN: entry size:  128
KERN: entry count: 128
KERN: entries CRC: 2874462854
KERN:   returned: 0.959
KERN:   trying: file_systems/bfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/devfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/packagefs/v1
KERN:   returned: -1
KERN:   trying: file_systems/rootfs/v1
KERN:   returned: -1
KERN:   trying: partitioning_systems/session/v1
KERN:   returned: -1
KERN:   trying: partitioning_systems/apple/v1
KERN:   returned: -1
KERN:   trying: partitioning_systems/amiga_rdb/v1
KERN:   returned: -1
KERN: googlefs: std_ops(INIT)
KERN:   trying: file_systems/googlefs/v1
KERN:   returned: -1
KERN: googlefs: std_ops(UNINIT)
KERN:   trying: file_systems/udf/v1
KERN: udf_recognize: Invalid sequence. status = -1
KERN:   returned: -1
KERN:   trying: file_systems/reiserfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/ntfs/v1
KERN: fs_identify_partition: boot signature NTFS doesn't match
KERN:   returned: -1
KERN:   trying: file_systems/write_overlay/v1
KERN:   returned: -1
KERN:   trying: file_systems/attribute_overlay/v1
KERN:   returned: -1
KERN:   trying: file_systems/nfs4/v1
KERN:   returned: -1
KERN:   trying: file_systems/nfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/iso9660/v1
KERN: identify(82, 0x93e2a250)
KERN:   returned: -1
KERN:   trying: file_systems/fat/v1
KERN:   returned: -1
KERN:   trying: file_systems/ext2/v1
KERN: ext2: invalid superblock!
KERN:   returned: -1
KERN:   trying: file_systems/exfat/v1
KERN: exfat: invalid superblock!
KERN:   returned: -1
KERN:   trying: file_systems/cdda/v1
KERN: usb_disk: unhandled ioctl 10102
KERN:   returned: -1
KERN:   trying: file_systems/btrfs/v1
KERN: btrfs: invalid superblock!
KERN:   returned: -1
KERN:   trying: file_systems/bindfs/v1
KERN:   returned: -1
KERN:   scanning with: partitioning_systems/efi_gpt/v1
KERN: efi_gpt_scan_partition(cookie = 0xf96a0710)

Change History (14)

comment:1 Changed 5 years ago by kallisti5

unplugging and replugging the usb device results in the "create" option being disabled.

This is all hrev46511 gcc2h

comment:2 Changed 5 years ago by kallisti5

Attempted with latest hrev47763 gcc4h on MBR filesystem:

KERN: EFI::Header: Initialize GPT, block size 512
KERN: EFI header: EFI PART
KERN: EFI revision: 10000
KERN: header size: 92
KERN: header CRC: 0
KERN: absolute block: 1
KERN: alternate block: 0
KERN: first usable block: 34
KERN: last usable block: 15347678
KERN: disk GUID: 00000001-0000-0000-c8ce-7f8234ce7f82
KERN: entries block: 2
KERN: entry size:  128
KERN: entry count: 128
KERN: entries CRC: 0
KERN: KDiskDeviceManager::_ScanPartition(/dev/disk/usb/0/0/raw)
KERN: intel: ep_std_ops(0x1)
KERN:   trying: partitioning_systems/intel/extended/v1
KERN:   returned: -1
KERN: intel: ep_std_ops(0x2)
KERN:   trying: partitioning_systems/intel/map/v1
KERN: intel: pm_identify_partition(67, 4: 0, 7858028544, 512)
KERN: Error: Disk is GPT-formatted: GPT disks are currently unsupported.
KERN:   returned: -1
KERN:   trying: partitioning_systems/efi_gpt/v1
KERN: gpt: alternate header not in last block (0 vs. 15347711)
KERN: EFI header: EFI PART
KERN: EFI revision: 10000
KERN: header size: 92
KERN: header CRC: -695728875
KERN: absolute block: 1
KERN: alternate block: 0
KERN: first usable block: 34
KERN: last usable block: 15347678
KERN: disk GUID: 00000001-0000-0000-c8ce-7f8234ce7f82
KERN: entries block: 2
KERN: entry size:  128
KERN: entry count: 128
KERN: entries CRC: 2874462854
KERN: EFI header: EFI PART
KERN: EFI revision: 10000
KERN: header size: 92
KERN: header CRC: -695728875
KERN: absolute block: 0
KERN: alternate block: 1
KERN: first usable block: 34
KERN: last usable block: 15347678
KERN: disk GUID: 00000001-0000-0000-c8ce-7f8234ce7f82
KERN: entries block: 18446744073709551584
KERN: entry size:  128
KERN: entry count: 128
KERN: entries CRC: 2874462854
KERN:   returned: 0.959
KERN:   trying: file_systems/bfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/devfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/packagefs/v1
KERN:   returned: -1
KERN:   trying: file_systems/rootfs/v1
KERN:   returned: -1
KERN:   trying: partitioning_systems/session/v1
KERN:   returned: -1
KERN:   trying: partitioning_systems/amiga_rdb/v1
KERN:   returned: -1
KERN:   trying: partitioning_systems/apple/v1
KERN:   returned: -1
KERN:   trying: file_systems/fat/v1
KERN:   returned: -1
KERN:   trying: file_systems/iso9660/v1
KERN: identify(67, 0xee319fb0)
KERN:   returned: -1
KERN:   trying: file_systems/exfat/v1
KERN: exfat: invalid superblock!
KERN:   returned: -1
KERN:   trying: file_systems/reiserfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/bindfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/udf/v1
KERN: udf_recognize: Invalid sequence. status = -1
KERN:   returned: -1
KERN:   trying: file_systems/attribute_overlay/v1
KERN:   returned: -1
KERN:   trying: file_systems/nfs4/v1
KERN:   returned: -1
KERN:   trying: file_systems/ntfs/v1
KERN: fs_identify_partition: boot signature NTFS doesn't match
KERN:   returned: -1
KERN:   trying: file_systems/write_overlay/v1
KERN:   returned: -1
KERN:   trying: file_systems/nfs/v1
KERN:   returned: -1
KERN: googlefs: std_ops(INIT)
KERN:   trying: file_systems/googlefs/v1
KERN:   returned: -1
KERN: googlefs: std_ops(UNINIT)
KERN:   trying: file_systems/cdda/v1
KERN: usb_disk: unhandled ioctl 10102
KERN:   returned: -1
KERN:   trying: file_systems/btrfs/v1
KERN: btrfs: invalid superblock!
KERN:   returned: -1
KERN:   trying: file_systems/ext2/v1
KERN: ext2: invalid superblock!
KERN:   returned: -1
KERN:   scanning with: partitioning_systems/efi_gpt/v1
KERN: efi_gpt_scan_partition(cookie = 0x8d8400f8)

comment:3 Changed 4 years ago by kallisti5

Still exists as of hrev49307 x86_64

comment:4 Changed 4 years ago by kallisti5

Details of a test 100MB disk per linux gdisk:

$ gdisk test.raw 
GPT fdisk (gdisk) version 0.8.10

Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: damaged

Found invalid MBR and corrupt GPT. What do you want to do? (Using the
GPT MAY permit recovery of GPT data.)
 1 - Use current GPT
 2 - Create blank GPT

Your answer: 1

Command (? for help): r

Recovery/transformation command (? for help): p
Disk test.raw: 204800 sectors, 100.0 MiB
Logical sector size: 512 bytes
Disk identifier (GUID): 82009838-FFFF-FFFF-3898-0082FFFFFFFF
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 204766
Partitions will be aligned on 8-sector boundaries
Total free space is 1981 sectors (990.5 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          202791   99.0 MiB    EB00  

Recovery/transformation command (? for help): ?
b	use backup GPT header (rebuilding main)
c	load backup partition table from disk (rebuilding main)
d	use main GPT header (rebuilding backup)
e	load main partition table from disk (rebuilding backup)
f	load MBR and build fresh GPT from it
g	convert GPT into MBR and exit
h	make hybrid MBR
i	show detailed information on a partition
l	load partition data from a backup file
m	return to main menu
o	print protective MBR data
p	print the partition table
q	quit without saving changes
t	transform BSD disklabel partition
v	verify disk
w	write table to disk and exit
x	extra functionality (experts only)
?	print this menu

Recovery/transformation command (? for help): v

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 204766, but backup header is at
0 and disk size is 204800 sectors.
The 'e' option on the experts' menu will probably fix this problem

Identified 3 problems!

Recovery/transformation command (? for help): i
Using 1
Partition GUID code: 42465331-3BA3-10F1-802A-4861696B7521 (Haiku BFS)
Partition unique GUID: 00000000-0000-0000-0000-000000000000
First sector: 40 (at 20.0 KiB)
Last sector: 202791 (at 99.0 MiB)
Partition size: 202752 sectors (99.0 MiB)
Attribute flags: 0000000000000000
Partition name: ''

comment:5 Changed 4 years ago by kallisti5

Milestone: UnscheduledR1/beta1
Resolution: fixed
Status: newclosed

resolved in hrev49309. A todo item to assign the alternate header was preventing Haiku from creating the disk system properly. gpt headers / disk systems created with Haiku are now seen as valid by gdisk!

comment:6 Changed 4 years ago by miqlas

Hi Kallisti,

yesterday i tried to create a new partition on my GUID disk with DriveSetup (it was some hours before your commit hrev49309) on my HDD (it is a 1T HDD with 4K sector size)

DriveSetup listed nicely the GPT partitions, and the gap space between the partitions. I deleted a partition to get free space for a new partition, and made a new with BFS. I noticed, that Haiku made no gap space between the old and the new partition (<- it could be important, i don't know) but everything went without problem and i got no error message. After that i installed Haiku onto the new partition and installed the bootrecord into this partition.

After my primary OS was not able to read the partition system of the modified disk, so i lost all of my other partitions and data. Nothing serious, i just restored everything from backup.

Is your commit fixing this problem? If not, can we disable the partition creation on GPT disks? It would be bad experience for the users losing data because our unfinished or buggy GPT partitioning support.

Thanks! miqlas

comment:7 Changed 4 years ago by axeld

It would be great if you would have made copies of the blocks of your GPT disk after Haiku changed it. Could you still access those partitions from within Haiku?

If kallisti5's changes fixed that, I'd say the other OS's GPT is buggy, as it actually should be able to read it just fine -- that's why there are two GPT blocks to begin with.

comment:8 in reply to:  7 Changed 4 years ago by miqlas

Replying to axeld:

It would be great if you would have made copies of the blocks of your GPT disk after Haiku changed it. Could you still access those partitions from within Haiku?

If kallisti5's changes fixed that, I'd say the other OS's GPT is buggy, as it actually should be able to read it just fine -- that's why there are two GPT blocks to begin with.

Hi Axel,

no, i recreated the partitions and restored everything from backup yesterday midnight. I will test the kallisti's commit at weekend, but not on my productive HDD anymore (i know, i know...) I have some USB thumbdrive, i can create GPT partitionig system on that too, and then i can modify them in Haiku without risking my data. I think it could be a good test, right? If it doesn't fixed with this commit, i can provide the info what you need to debug this problem.

What i've seen: Haiku can reinitialize any GPT partition to BFS correctly, but during deeleting and recreating a partition on GPT in Haiku somewhere something went wrong.

I have no info about how good or bad is the GPT implementation of my primary OS (OSX 10.10.3 Yosemite), but i had no problems like this before.

comment:9 Changed 4 years ago by axeld

The bottom line is: if Haiku was still able to read the GPT table, other systems should be, too. If they can't they are likely too strict. I've created a GPT table years ago with Haiku, and didn't have any issues with it yet on various systems (Windows, and Linux).

comment:10 in reply to:  9 Changed 4 years ago by miqlas

Replying to axeld:

The bottom line is: if Haiku was still able to read the GPT table, other systems should be, too. If they can't they are likely too strict. I've created a GPT table years ago with Haiku, and didn't have any issues with it yet on various systems (Windows, and Linux).

Axel, maybe i made something wrong, or there was problem with my GPT partition scheme, i can't say for sure, that Haiku is guilty. OSX was unable to read the partition table, so i started to restore everything and i forgot to check the disk in another OS or in Haiku.

I will test and report back at weekend.

Thanks you guys!

comment:11 Changed 4 years ago by axeld

There is no question Haiku was guilty, it just might have been less interrupting for you if OS X would be more forgiving :-)

comment:12 Changed 4 years ago by kallisti5

@miqlas

"on my HDD (it is a 1T HDD with 4K sector size)" " After that i installed Haiku onto the new partition and installed the bootrecord into this partition."

4K sector size + bootrecord == #11796

I'd try it without the bootloader to see what happens... however i'm pretty sure our bootloader is also unaware of GPT.

I've yet to have a 4k disk to test haiku on. (I wonder if I can emulate one?)

comment:13 in reply to:  12 Changed 4 years ago by miqlas

Replying to kallisti5:

I'd try it without the bootloader to see what happens... however i'm pretty sure our bootloader is also unaware of GPT.

I doesn't explained it correctly, let me try again: I had a Haiku partition before this catastrophe on the same HDD, on GPT partition. I made the partition in OSX as FAT and then initialized in Haiku as BFS and installed bootrecord. It worked without problem, i was able to boot it with the Haiku bootmenu installed to a USB drive (MBR).

Now as I experimenting with Clover legacy boot i tried to recreate the partition in Haiku because Clover was not able to detect the "FAT-reinitialized-as-BeFS" partition as bootable partition. I thought maybe something wrong with the reinitialized FAT partition, because the diskutil tool in OSX told it is a "Microsoft Basic Data" partition.

So i started Haiku, opened the DriveSetup, and it presented the partition table:

  • USER partition
  • Empty space (gap)
  • HAIKU partition
  • Empty space (gap)

I deleted the Haiku partition, now DriveSetup presented the following partition table:

  • USER Partition
  • Empty space (gap)

I tried to recreate the Haiku partition, so i went to the menu, and created a new partition on this empty space. This is what i got:

  • USER Partition
  • HAIKU partition

See? No gap anymore. I'm not sure if it is requiment or not, but after this step OSX was not able to read the partition table anymore.

Sorry, i forgot to test the result in Haiku, but i was able to install Haiku into the new partition.

comment:14 Changed 4 years ago by kallisti5

see #12170 This is a new issue. Please keep in mind that this is all *extremely* young code in an alpha operating system... I wouldn't use the GPT functionality on live data for a little while.

Note: See TracTickets for help on using tickets.