On first boot, NanoKVM creates /dev/mmcblk0p3 as exFAT but the MBR partition type is set to Linux (0x83).

That mismatch causes macOS (and potentially other OSes) to misclassify the partition, leading to mount failures in normal tooling and third-party drivers.

Impact

On macOS

• the partition is detected as Linux/ext instead of exFAT.
• /data fails to mount automatically
• Users may need manual recovery (mount_exfat) and MBR edits (0x83 -> 0x07).

Root cause

Partition 3 was created with:

On an MBR (msdos) disk label, this defaults to Linux type (0x83) even though the script immediately formats the partition as exFAT.

Reproduction

1. Provision a fresh NanoKVM image and boot once with /boot/usb.disk0 present.
2. Inspect partition table and mount:

# fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 29 GB, 31268536320 bytes, 61071360 sectors
954240 cylinders, 4 heads, 16 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device       Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/mmcblk0p1 *  0,0,2       2,10,9               1      32768      32768 16.0M  c Win95 FAT32 (LBA)
/dev/mmcblk0p2    2,10,10     995,243,17       32769   16000000   15967232 7796M 83 Linux
/dev/mmcblk0p3    1023,1,32   1023,1,32     16001024   61071359   45070336 21.4G 83 Linux

# mount | grep data
/dev/mmcblk0p3 on /data type exfat (rw,relatime,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro)

3. Observe p3 type is Linux (83) while filesystem is exFAT.

Fix

The partition entry for /dev/mmcblk0p3 should be created as a Microsoft basic data partition for NTFS/exFAT (0x07) so exFAT is correctly recognized. And, while we are at it, label the partition.

Expected result

• p3 MBR type is 0x07.
• Filesystem is exFAT.
• Volume label is data.