#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: | ||
| 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 by , 11 years ago
comment:2 by , 10 years ago
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:4 by , 9 years ago
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 by , 9 years ago
| Milestone: | Unscheduled → R1/beta1 |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
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 by , 9 years ago
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
follow-up: 8 comment:7 by , 9 years ago
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 by , 9 years ago
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.
follow-up: 10 comment:9 by , 9 years ago
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 by , 9 years ago
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 by , 9 years ago
There is no question Haiku was guilty, it just might have been less interrupting for you if OS X would be more forgiving :-)
follow-up: 13 comment:12 by , 9 years ago
@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 by , 9 years ago
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 by , 9 years ago
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.
unplugging and replugging the usb device results in the "create" option being disabled.
This is all hrev46511 gcc2h