Octocontrabass wrote:
This is not the first report here of the firmware "helpfully" updating the BPB and corrupting the boot code as a result, but this is the first time anyone has claimed to see it on a partitioned disk. I have seen at least one PC that skipped the MBR and directly loaded the VBR, so it's not too surprising to see one that "fixes" the BPB in the VBR.
What filesystem type is indicated in the partition table? It's possible the firmware thinks it's trying to boot DOS, and DOS would be very unhappy if the BPB doesn't match INT 0x13.
Thanks very much for this.
I originally got my stuff on to the usb from linux using dd to move everything to the first partition and didn't think to mess with the partition table afterwards.
I hadn't paid much attention to the partition table, but having now done so doesn't give a plausible excuse for the firmware's behaviour (assuming that diagnosis is correct). The partition has a type identifier of 0x0b which is FAT32 and Disk Editor correctly presented a FAT32 template when inspecting the relevant VBR. This uses byte 0x40 of the VBR for the physical drive not byte 0x24, the offending location in my case. 0x24 is used by 16 bit FAT VBR type identifier 0x04. Still, I thought I didn't want my filesystem to continue masquerading as a FAT of any sort and so tried changing the partition type to 0x20 which is described in the Andries Brouwer list as "Unused. Rumoured to be used by Willowsoft Overture File System (OFS1), if there is such a thing". It would have been nice if some agreement could have been reached to dedicate a number to "Experimental and wacky systems only used by ludicrously hopeful one-man bands in their garden sheds"
Rebooting with this revision made not a bit of difference and byte 0x7c24 continues to appear altered to 0x80.
However, it's doing its job, if messily. I think the OS is a more interesting project than the bootloader!