Posible bug en mkdosfs, no escribe byte de tipo de sistema de archivos en el MBR

Por razones académicas he estado investigando sobre el sistema
de archivos FAT32. En el proceso, creo que me he topado con
un bug en el programa mkdosfs (versión 3.0.3). Al parecer no es
capaz de escribir el byte identificador de tipo de partición en la tabla de
particiones ubicada en el MBR del disco.

En el man del programa, en la sección Bugs, dice que esta
aplicación no es capaz de crear particiones booteables. Este
tipo de particiones se identifican cambiando el primer byte que
la describe en la tabla de particiones a 0x80. No estoy seguro
si para hacer esta operación tiene que hacer otros cambios en el
MBR, de no ser así, este mismo Bug explicaría el que estoy
reportando.

Una forma fácil de reproducir el bug es con un pendrive. Usando
gparted hay que crear 2 particiones, una FAT32 y una ext4, para
poder compararlas. Aquí se pueden ver los resultados (se supone que ambas particiones estan montadas):

$ mount | grep sdb
/dev/sdb1 on /media/SD0625 type vfat (rw,nosuid,nodev,uhelper=devkit,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,flush)
/dev/sdb2 on /media/asdf type ext4 (rw,nosuid,nodev,uhelper=devkit)
$ fdisk -l /dev/sdb

Disco /dev/sdb: 4022 MB, 4022337024 bytes
255 cabezas, 63 sectores/pista, 489 cilindros
Unidades = cilindros de 16065 * 512 = 8225280 bytes
Identificador de disco: 0xe5fd66e5

Disposit. Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sdb1   *           1         470     3775243+   c  W95 FAT32 (LBA)
/dev/sdb2             471         489      152617+  83  Linux

Para obtener el MBR del disco:

# head -c 512 /dev/sdb > mbr.raw

El vaciado hexadecimal del MBR de mi pendrive da:

$ hexdump -Cv mbr.raw
00000000  fa 31 c0 8e d8 8e d0 bc  00 7c 89 e6 06 57 52 8e  |.1.......|...WR.|
00000010  c0 fb fc bf 00 06 b9 00  01 f3 a5 ea 20 06 00 00  |............ ...|
00000020  52 b4 41 bb aa 55 31 c9  30 f6 f9 cd 13 72 13 81  |R.A..U1.0....r..|
00000030  fb 55 aa 75 0d d1 e9 73  09 66 c7 06 8d 06 b4 42  |.U.u...s.f.....B|
00000040  eb 15 5a b4 08 cd 13 83  e1 3f 51 0f b6 c6 40 f7  |..Z......?Q...@.|
00000050  e1 52 50 66 31 c0 66 99  e8 66 00 e8 21 01 4d 69  |.RPf1.f..f..!.Mi|
00000060  73 73 69 6e 67 20 6f 70  65 72 61 74 69 6e 67 20  |ssing operating |
00000070  73 79 73 74 65 6d 2e 0d  0a 66 60 66 31 d2 bb 00  |system...f`f1...|
00000080  7c 66 52 66 50 06 53 6a  01 6a 10 89 e6 66 f7 36  ||fRfP.Sj.j...f.6|
00000090  f4 7b c0 e4 06 88 e1 88  c5 92 f6 36 f8 7b 88 c6  |.{.........6.{..|
000000a0  08 e1 41 b8 01 02 8a 16  fa 7b cd 13 83 c4 10 66  |..A......{.....f|
000000b0  61 c3 e8 c4 ff be be 7d  bf be 07 b9 20 00 f3 a5  |a......}.... ...|
000000c0  c3 66 60 89 e5 bb be 07  b9 04 00 31 c0 53 51 f6  |.f`........1.SQ.|
000000d0  07 80 74 03 40 89 de 83  c3 10 e2 f3 48 74 5b 79  |..t.@.......Ht[y|
000000e0  39 59 5b 8a 47 04 3c 0f  74 06 24 7f 3c 05 75 22  |9Y[.G.<.t.$.<.u"|
000000f0  66 8b 47 08 66 8b 56 14  66 01 d0 66 21 d2 75 03  |f.G.f.V.f..f!.u.|
00000100  66 89 c2 e8 ac ff 72 03  e8 b6 ff 66 8b 46 1c e8  |f.....r....f.F..|
00000110  a0 ff 83 c3 10 e2 cc 66  61 c3 e8 62 00 4d 75 6c  |.......fa..b.Mul|
00000120  74 69 70 6c 65 20 61 63  74 69 76 65 20 70 61 72  |tiple active par|
00000130  74 69 74 69 6f 6e 73 2e  0d 0a 66 8b 44 08 66 03  |titions...f.D.f.|
00000140  46 1c 66 89 44 08 e8 30  ff 72 13 81 3e fe 7d 55  |F.f.D..0.r..>.}U|
00000150  aa 0f 85 06 ff bc fa 7b  5a 5f 07 fa ff e4 e8 1e  |.......{Z_......|
00000160  00 4f 70 65 72 61 74 69  6e 67 20 73 79 73 74 65  |.Operating syste|
00000170  6d 20 6c 6f 61 64 20 65  72 72 6f 72 2e 0d 0a 5e  |m load error...^|
00000180  ac b4 0e 8a 3e 62 04 b3  07 cd 10 3c 0a 75 f1 cd  |....>b.....<.u..|
00000190  18 f4 eb fd 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 00 00 00 00 00  e5 66 fd e5 00 00 80 01  |.........f......|
000001c0  01 00 0c fe 7f d5 3f 00  00 00 17 36 73 00 00 00  |......?....6s...|
000001d0  41 d6 83 fe 7f e8 56 36  73 00 53 a8 04 00 00 00  |A.....V6s.S.....|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200

los 64 bytes en negro son la tabla particiones. Cada partición se describe en 16
bytes. Se puede ver que la primera partición es:

80 01 01 00 0c fe 7f d5 3f 00 00 00 17 36 73 00

y la segunda partición:

00 00 41 d6 83 fe 7f e8 56 36 73 00 53 a8 04 00

Como no existe la tercera y cuarta partición, los demás bytes de la tabla son nulos.

En cada entrada de la tabla, el cuarto byte indica que sistema de ficheros aloja
la partición (es el mismo que sale en la columna ID con fdisk -l). En la primera
partición este byte es 0x0c el cual es el código para FAT32. en la segunda es 0x83,
el código para ext4 (en realidad también es el código para ext2, ext3 y una que
usa por defecto opensolaris). Los demas bytes sirven para identificar los
límites de la partición, excepto el primero que india cual partición es booteable.

Luego de desmontar la segunda partición, se formatea en FAT32:

# mkdosfs -n asdf -F 32 /dev/sdb2

De la misma manera que se hizo anteriormente, se puede ver que la segunda partición
es:

00 00 41 d6 83 fe 7f e8 56 36 73 00 53 a8 04 00

Como se ve, el 4º byte indica que en esa partición se aloja una partición ext4,
lo que no es cierto, pues se acaba de formatear a FAT32. Esto queda mas claro con fdisk:

$ fdisk -l /dev/sdb

Disco /dev/sdb: 4022 MB, 4022337024 bytes
255 cabezas, 63 sectores/pista, 489 cilindros
Unidades = cilindros de 16065 * 512 = 8225280 bytes
Identificador de disco: 0xe5fd66e5

Disposit. Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sdb1   *           1         470     3775243+   c  W95 FAT32 (LBA)
/dev/sdb2             471         489      152617+  83  Linux

Pero efectivamente la segunda partición si está formateada en FAT32:

/dev/sdb2 on /media/asdf type vfat (rw,nosuid,nodev,uhelper=devkit,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,flush)
/dev/sdb1 on /media/SD0625 type vfat (rw,nosuid,nodev,uhelper=devkit,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,flush)

¿Has comprobado que el dispositivo este correcto y no tenga algun bloque defectuoso para mkdosfs , es la opcion -c.?, es solo una idea generica, la verdad es que tiene pinta de ser un bug por lo que cuentas, pero chequear si tienes el pendrive bien me parece positivo para determinar la naturaleza de bug o no.

no tiene bloques defectuosos, y lo he probado en tres pendrives