exFAT problems, v2025.10.27

[65a]

Just got a BlueSCSI, and formatted an SD card as exFAT. It works great and I love it! I did run into the following.

I used it for a few days, and was cruising right along.

However, very concerningly, the disk image on the SD card is 100% empty. It can still boot, I can write files on the vintage mac, but these changes are not "visible" to a linux client.

I discovered this after trying to copy the image off of the original SD card to 3 different SD cards, all of which were unbootable. The original image looks like an empty file on linux, but my bootable hard drive to BlueSCSI.

I dug a little more. If I create the disk with truncate -s 1024M on the SD card, it's more likely to exhibit the above behavior. If I create it with dd if=/dev/zero it's very likely to be considered "fragmented" by bluescsi, and will retain data but not be bootable.

The only thing that worked for me was to dd from /dev/urandom to create the disk.

I am quite certain there are continuing issues from #258

Here's an easy repro for me, on various SD cards from various brands:

cfdisk /dev/sdb # One partition, DOS label, primary
mkfs.exfat /dev/sdb1
mount /dev/sdb1 /mnt
dd if=/dev/zero of=/mnt/HD01_disk.hda bs=4M count=1024 oflag=direct status=progress # or whatever
sync
umount /mnt
eject /dev/sdb1
eject /dev/sdb # extra caution

# Boot machine from Mac OS 7.6.1 install CD
# Initialize disk with Apple HDSC setup
# Update driver, reboot

The new drive will be detected as fragmented, and will not be bootable later on my particular machine and board. Non-"fragmented" drives are bootable.

The truncate -s 1024M case is probably the worst case, where the file will remain "empty" to Linux. I haven't tried to reproduce this one again, I made a backup to a drive initialized with /dev/urandom instead of /dev/zero. I don't think exfat has sparse files. Something weird is happening in both of the above cases.

[65a]

Just saw there was a recent release, is there hope it fixes the issue?

[erichelgeson]

Yes it should. Please retest.

[65a]

Tried two disks, both created on the SD, one made via dd if=/dev/zero and the other via truncate -s.

Neither disk show as fragmented in the log, so that's good.

The truncate -s disk has data in it from Mac OS 8, but appears empty on linux. That seems bad.

The dd if=/dev/zero has data in it from linux, which seems good.

Neither disk can be booted if set in the startup disks control panel, both result in a Sad Mac shortly after showing the happy one.

My other SD has a disk created with dd if=/dev/urandom, and that one boots reliably (it didn't when the first two methods were used).

[65a]

I will try again with the same SD with /dev/urandom method, as well as same SD on FAT32.

[65a]

Sad mac issue was related to a CPU (or possibly voltage...) issue. I think the main remaining problem is the "empty" disk drive with a hda created with truncate. I'll repeat the steps above with the more stable CPU.