Sorry for monologueing... it's for science!
So I decided to experiment and zero out those 420 bytes entirely.
Code:
dd bs=1 count=420 seek=90 if=/dev/zero of=/dev/sdj
and same for the backup sector. As a result, fsck.fat was happy, Linux was happy, Win10 was happy, Kobo was happy - or so I thought, after rebooting Kobo it's back to square one:
Code:
# fsck.fat /dev/sdj
fsck.fat 4.0 (2016-05-06)
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
494:ff/00, 495:ff/00, 496:ff/00, 497:ff/00, 498:ff/00, 499:ff/00, 500:ff/00
, 501:ff/00, 502:ff/00, 503:ff/00, 504:ff/00, 505:ff/00, 506:ff/00
, 507:ff/00, 508:ff/00, 509:ff/00
1) Copy original to backup
2) Copy backup to original
3) No action
?
Kobo set bytes 494-509 to 0xff at some point, and Win10 doesn't like it for some reason. Primadonnas...
Choosing 2) (which zeroes out those bytes since it's still zero in the backup) to make Win10 happy, that works again.
So I was wondering, what's the smallest change that makes it work (or makes it not work)? I zeroed out a single byte 509... didn't work, 508-500 still nope, ... seriously what am I even doing... 499-495 oh hey it works. So if 494 alone is 0xff that's fine for some reason. What the heck.
And for some reason, that sticks until reboot. Unplugging the Kobo, replugging it, 494 alone stayed 0xff and everything else stayed 0x00. After reboot it's bytes 489-494 that differ.
Code:
# fsck.fat /dev/sdj
fsck.fat 4.0 (2016-05-06)
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
489:8d/00, 490:ef/00, 491:02/00, 492:d2/00, 494:ff/00
1) Copy original to backup
2) Copy backup to original
3) No action
Yet, Win10 is still happy with this. So I've finally reached a state that all OS like and survives reboots of Kobo.
All in all this is incredibly frustrating.
Why does Win10 like, and not like, something that no one else cares about (bootloader code). Why are some byte combinations there problematic and others aren't. It all seems very random.
Why does Kobo sometimes overwrite bytes 495-509 with 0xff and sometimes leave them alone. How is this decision made. It seems very random, too.
A couple of unplugs, reboots later, Win10 is still happy with this Kobo partition. Equilibrium of randomness.
The main problem is reaching this state in the first place. If you just write zeroes to all 420 bytes, Kobo just 0xff everything afterwards. This happens even if you just punch the Reset button instead of doing a regular disconnect. (I tried the reset in case it was just some cache somewhere but nope.)
So you have to zero everything, reboot, and then zero bytes 495-509 again.
Code:
dd bs=1 seek=90 count=420 if=/dev/zero of=/dev/sdj
sync
# unplug, reboot kobo
dd bs=1 seek=495 count=15 if=/dev/zero of=/dev/sdj
sync
Or at least that's what I ended up with. Of course you could probably dump the working final state onto it directly and hope it sticks.
If someone can reproduce this, it could be put in a mod.
And if this is anywhere close to the mark, this should be in an official firmware update. Stop messing with this sector. And fix whatever may be problematic in there. Zeroing out entirely works but only if Kobo leaves it alone afterwards instead of spamming it with 0xff.