PHD FAT volumes aren't recognized by WS2022's in-box FAT driver

[gjcolombo]

Repro steps: create a PHD VM with a virtio disk backed by a PHD FatFilesystem and run a test with a Windows Server 2022 guest.

Expected: The guest recognizes the disk's partition/volume structure and allows a drive letter to be assigned to the file system.

Observed: The guest recognizes the physical disk, but believes it has no partitions or volumes and doesn't allow it to be mounted.

This is annoying because it prevents tests from working with files on an in-memory disk using native OS file system APIs. Because the data on the disk is not recognized at all, it's not possible to use Powershell cmdlets or a diskpart script as a workaround, at least as far as I can tell. I believe it's still possible to muck around with the physical blocks on the disk from Cygwin with utilities like dd, though, if you specify something like \\.\PhysicalDrive1 as the relevant file path.

This doesn't affect cloud-init drives that are parsed by cloudbase-init (the cloud-init provider we recommend in the image builder) because it uses tools from the GNU Mtools suite to read the cloud-init drive's contents at the physical disk layer (i.e. it uses a tool in the suite to copy files from a VFAT cloud-init drive without using any OS filesystem drivers).

I have not tested this with other flavors of Windows but I imagine they'll have the same problem.

[luqmana]

I believe it's not happy with the lack of a partition table. Last I checked, Windows only supports such full disk filesystem devices on removable media (see superfloppy).

[pfmooney]

I believe it's not happy with the lack of a partition table. Last I checked, Windows only supports such full disk filesystem devices on removable media (see superfloppy).

Ah, nice find. Presumably something like mbrman would make it easy enough to lay down an appropriate table to paper over that issue. (Unless there's some pressing reason why we'd want to go GPT instead)