Proper procedure to partition a (raw) disk

NTDEV
1

So for some time when we prep a disk with our filesystem, we simply open the \?\PHYSICALDRIVEx device,

  • write out our EFI partitions (sector 2-34),
  • primary EFI on sector 1
  • then PMBR on sector 0.
    (As well as backup labels at end of disk)
    This code come from illumos/FreeBSD/Linux/macOS.

But something recently has changed, the user talk about updating to 24H2.

Now what happens is Windows will "fix" the partition by overwriting it.

So I have been increasing properness (desperation) by adding more code to it.

Now I will (most desperate version)

  • Using FindFirstVolume, if GET_DEVICE_NUMBER and DISK_EXTENT match
  • Issue LOCK_VOLUME, and DISMOUNT_VOLUME
  • Write all-zero to sectors 0-34
  • Issue DISK_UPDATE_PROPERTIES
  • Connect to ROOT\CIMV2 and Offline DISK
  • Which lets us re-open disk without write-sharing (so userland exclusive)
  • write sector 2-34
  • write sector 1
  • write sector 0
  • issue DISK_UPDATE_PROPERTIES

and yet, Windows will "fix" the partition table. This happens before I have even closed the Handle, so it can ignore userland exclusive open, presumably comes from kernel then.

So what is the official proper way for me to partition a disk ? I avoid using CREATE_DISK as I do not want Windows to "own" it (as suggested by ChatGPT).

Users also noticed that if I purposely corrupt the sector 1 EFI label, ie, by changing "EFI Part" at offset 0, to say "_FI Part", Windows will no longer "fix" it. So if it is an invalid partition, Windows leaves it alone.

Output of a run:

# zpool create -f usb physicaldrive1
Expanded path to '\\?\physicaldrive1'
Volume locked successfully. (So available for use)
check_slice: failed to open \\?\Harddisk1Partition0
check_slice: failed to open \\?\Harddisk1Partition0
check_slice: failed to open \\?\Harddisk1Partition0
No slices to contend with, assuming WholeDisk.
efi_tryexclusive: fd 528
Volume \\?\Volume{27f138a5-25ab-11f0-864d-803253b6a8b8} is on PHYSICALDRIVE1
  Locked.
  Dismounted.
efi_tryexclusive: trying to offline disk
efi_tryexclusive: success
efi_tryexclusive: trying for exclusive access
efi_tryexclusive: success. fd is 752
efi_write wiping start of disk
efi_write writing labels
efi_write writing PMBR
efi_write sending DISK_UPDATE_PROPERTIES
verify_label: checksum mismatch
It appears something in Windows overwrote the OpenZFS partition.
Manual intervention might be required.
EFI read OK, max partitions 9
    part 0:  offset 0:    len 0:    tag: 0    name: ''
    part 1:  offset 0:    len 0:    tag: 0    name: ''
    part 2:  offset 0:    len 0:    tag: 0    name: ''
    part 3:  offset 0:    len 0:    tag: 0    name: ''
    part 4:  offset 0:    len 0:    tag: 0    name: ''
    part 5:  offset 0:    len 0:    tag: 0    name: ''
    part 6:  offset 0:    len 0:    tag: 0    name: ''
    part 7:  offset 0:    len 0:    tag: 0    name: ''
    part 8:  offset 0:    len 0:    tag: 0    name: ''

It seems to always "fix" it by writing a blank partition. It should have:

    part 0:  offset 800:    len 27fb000:    tag: 4    name: 'zfs-0000250b00000995'
2

OK so one could argue I should use IOCTL_DISK_SET_DRIVE_LAYOUT_EX to label the disk, but I can not find a way to leave "blank" partitions. I am trying to emulate how the Unix version labels the disk, with data on s1, and slop on s9. But Windows will always skip over blank partitions, making it s1 and s2.

I could make 1 sector partitions for 2-8, but that is somewhat ugly.

What it actually turned out to be, is the Unix sources in libefi, writes the 9 partition standard GPT, including the CRC for 9 partitions. Windows seems to only use 128, so it spots the incorrect CRC, and helpfully corrects it by writing the 128 partition CRC.

If I change MAX_NPART from 9, to 128, then everything works again as expected. No changes needed, but I might as well keep the LOCK, DISMOUNT etc code.