Update FreeDOS FAT16 boot record?

[marcosfrm]

Using FreeDOS 1.3 live CD and running format c: /q /s on a 1 GB FAT16 partition (type 0x06, created by FreeDOS' fdisk answering "No" for "large disk" support) produces this boot record:

00000000  eb 3c 90 46 52 44 4f 53  35 2e 31 00 02 20 01 00  |.<.FRDOS5.1.. ..|
00000010  02 00 02 00 00 f8 fa 00  3f 00 20 00 3f 00 00 00  |........?. .?...|
00000020  e1 38 1f 00 80 00 29 eb  15 6c 27 4e 4f 20 4e 41  |.8....)..l'NO NA|
00000030  4d 45 20 20 20 20 46 41  54 31 36 20 20 20 fa fc  |ME    FAT16   ..|
00000040  31 c0 8e d8 bd 00 7c b8  e0 1f 8e c0 89 ee 89 ef  |1.....|.........|
00000050  b9 00 01 f3 a5 ea 5e 7c  e0 1f 00 00 60 00 8e d8  |......^|....`...|
00000060  8e d0 8d 66 a0 fb 88 56  24 c7 46 c0 10 00 c7 46  |...f...V$.F....F|
00000070  c2 01 00 8c 5e c6 c7 46  c4 a0 63 8b 76 1c 8b 7e  |....^..F..c.v..~|
00000080  1e 03 76 0e 83 d7 00 89  76 d2 89 7e d4 8a 46 10  |..v.....v..~..F.|
00000090  98 f7 66 16 01 c6 11 d7  89 76 d6 89 7e d8 8b 5e  |..f......v..~..^|
000000a0  0b b1 05 d3 eb 8b 46 11  31 d2 f7 f3 50 01 c6 83  |......F.1...P...|
000000b0  d7 00 89 76 da 89 7e dc  8b 46 d6 8b 56 d8 5f c4  |...v..~..F..V._.|
000000c0  5e 5a e8 95 00 c4 7e 5a  b9 0b 00 be f1 7d 57 f3  |^Z....~Z.....}W.|
000000d0  a6 5f 26 8b 45 1a 74 0b  83 c7 20 26 80 3d 00 75  |._&.E.t... &.=.u|
000000e0  e7 72 65 50 c4 5e 5a 8b  7e 16 8b 46 d2 8b 56 d4  |.reP.^Z.~..F..V.|
000000f0  e8 67 00 58 1e 07 8e 5e  5c bf 00 20 ab 89 c6 8b  |.g.X...^\.. ....|
00000100  56 5c 01 f6 73 03 80 c6  10 8e da ad 83 f8 f8 72  |V\..s..........r|
00000110  eb 31 c0 ab 0e 1f c4 5e  5a be 00 20 ad 09 c0 75  |.1.....^Z.. ...u|
00000120  05 88 d3 ff 6e 5a 48 48  8b 7e 0d 81 e7 ff 00 f7  |....nZHH.~......|
00000130  e7 03 46 da 13 56 dc e8  20 00 eb e0 b4 0e cd 10  |..F..V.. .......|
00000140  5e ac 56 3c 00 75 f5 c3  e8 f5 ff 45 72 72 6f 72  |^.V<.u.....Error|
00000150  21 00 30 e4 cd 13 cd 16  cd 19 56 89 46 c8 89 56  |!.0.......V.F..V|
00000160  ca 8c 86 9e e7 89 9e 9c  e7 e8 d4 ff 2e 00 b4 41  |...............A|
00000170  bb aa 55 8a 56 24 84 d2  74 19 cd 13 72 15 d1 e9  |..U.V$..t...r...|
00000180  81 db 54 aa 75 0d 8d 76  c0 89 5e cc 89 5e ce b4  |..T.u..v..^..^..|
00000190  42 eb 26 8b 4e c8 8b 56  ca 8a 46 18 f6 66 1a 91  |B.&.N..V..F..f..|
000001a0  f7 f1 92 f6 76 18 89 d1  88 c6 86 e9 d0 c9 d0 c9  |....v...........|
000001b0  08 e1 41 c4 5e c4 b8 01  02 8a 56 24 cd 13 72 88  |..A.^.....V$..r.|
000001c0  8b 46 0b 57 be a0 63 c4  be 9c e7 89 c1 f3 a4 5f  |.F.W..c........_|
000001d0  b1 04 d3 e8 01 86 9e e7  83 46 c8 01 83 56 ca 00  |.........F...V..|
000001e0  4f 75 8b c4 9e 9c e7 5e  c3 00 00 00 00 00 00 00  |Ou.....^........|
000001f0  00 4b 45 52 4e 45 4c 20  20 53 59 53 00 00 55 aa  |.KERNEL  SYS..U.|

The executable code (0x03e through 0x200) is different from current br_fat16fd_0x3e.h.

On the other hand, the FAT32 one is still the same.

[pbatard]

I'm going to defer this issue for now as it doesn't look like there's much of an impact and I'd like to know what the actual differences are. Most of the FreeDOS updates I've seen for bootloaders in the past had to do with elements that had little to do with USB boot on modern machines, so I don't think it's worth rushing into updating something that, as far as I know, works just fine for our use.

Thanks for reporting on this though.

[marcosfrm]

I opened FDOS/kernel#99 btw.

[marcosfrm]

With

format c: /q
sys c: /force:lba

It changes two bytes at offsets 0x178 and 0x179:

-00000170  bb aa 55 8a 56 24 84 d2  74 19 cd 13 72 15 d1 e9  |..U.V$..t...r...|
+00000170  bb aa 55 8a 56 24 84 d2  90 90 cd 13 72 15 d1 e9  |..U.V$......r...|

https://github.com/FDOS/kernel/blob/ke2043/sys/sys.c#L1576-L1582

This "fat16lba" boot record I suppose is better for Rufus?

[pbatard]

From what I can see, the version of boot.asm from which ms-sys (and therefore Rufus) derives its br_fat16fd_0x3e.h code is the one that existed up to SVN revision 1482, i.e. from 2009-07-10 or earlier.

The differences to boot.asm started to be introduced in https://sourceforge.net/p/freedos/svn/1482/#diff-4, and especially with this part, which is the earliest difference in assembly code I could find:

;
; Note: some BIOS implementations may not correctly pass drive number
; in DL, however we work around this in SYS.COM by NOP'ing out the use of DL
; (formerly we checked for [drive]==0xff; update sys.c if code moves)
;
                mov     [drive], dl     ; rely on BIOS drive number in DL

There have been a few more changes since, and a few more after the project moved to GitHub in 2012.

For good measure I looked at the changes for boot32lb.asm while I was at it, but the only thing I can see is support for for file systems with 128KB cluster size (i.e. 256 sectors per cluster), which is not relevant for Rufus since 64KB cluster size is the max we support for FAT32. And the SVN code prior to the GitHub move has not been updated since 2004, which means we got the most up to date SVN version from ms-sys.

I'm still not super convinced that updating the FAT16 code is worth the trouble, since most people are expected to use drives that are large enough for FAT16 to be more or less irrelevant, but I'll see what I can do.

[marcosfrm]

nasm boot32lb.asm -o fat32lba.bin from the ke2043 tag (used by FreeDOS 1.3; 256 sectors per cluster commit is after that) produces the same code present in br_fat32fd_0x52.h.

For me is always cool have latest versions of everything: FAT16 BR updated to ke2043 tag used by FreeDOS 1.3... of course I say that because it is not me doing the work... :)

[pbatard]

I get you, but this creates 2 issues:

1. Everything needs to be re-tested in Rufus because possibly, the boot record may require a newer version of the kernel to work.
2. Because this is actually part of the ms-sys project and not Rufus, updating these records means upstreaming the changes to ms-sys, making sure this doesn't introduce regressions there, and then picking up these changes as part of an ms-sys update in Rufus, which is a lot of extra work for something that, so far, nobody seems to be complaining about (i.e. if there was an actual issue that Rufus users reported, and that the new BR's would be known to fix, this would be justified, but otherwise, not so much — for instance, the new code for drive number in DL is just an alternate approach for something that was already handled, so it doesn't provide a "new" fix that we could use).

Again, that's not to say I won't update the FAT16 boot record, but, in the absence of a clear "we need this latest version because otherwise, there is this scenario where X doesn't work") it's going to be a very low priority for me. As a matter of fact, I'm going to tag it as deferred for the time being. As a matter of fact, that's why I already tagged it as deferred.

[marcosfrm]

I get you, but this creates 2 issues:

1. Everything needs to be re-tested in Rufus because possibly, the boot record may require a newer version of the kernel to work.

Well, Rufus has KERNEL.SYS 2043 from FreeDOS 1.3 and FAT16 BR from FreeDOS 1.2 (or even earlier). I see low risk in updating FAT16 BR using the ke2043 tag from their repository (possibly with those two bytes changed), since that code is installed by the official 1.3 media.

2. Because this is actually part of the ms-sys project and not Rufus, updating these records means upstreaming the changes to ms-sys, making sure this doesn't introduce regressions there, and then picking up these changes as part of an ms-sys update in Rufus, which is a lot of extra work for something that, so far, nobody seems to be complaining about (i.e. if there was an actual issue that Rufus users reported, and that the new BR's would be known to fix, this would be justified, but otherwise, not so much — for instance, the new code for drive number in DL is just an alternate approach for something that was already handled, so it doesn't provide a "new" fix that we could use).

Again, that's not to say I won't update the FAT16 boot record, but, in the absence of a clear "we need this latest version because otherwise, there is this scenario where X doesn't work") it's going to be a very low priority for me. As a matter of fact, I'm going to tag it as deferred for the time being. As a matter of fact, that's why I already tagged it as deferred.

Understood. I can give it some testing if you need.

[pbatard]

Well, I got to chose my battles (meaning I have to choose what I spend my limited time on) and submitting a patch to ms-sys and then following up on it just to update on something that has not yet been demonstrated to be the source of any issue doesn't seem like a good time investment.

Therefore, if someone really cares about this, I will expect them to work with the ms-sys folks to update the bootloaders, so that I ultimately pick them up in Rufus. But I have now decided that I will not be the one leading that effort.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.