NetBSD Problem Report #59924
From mac@culver.net Fri Jan 16 22:44:42 2026
Return-Path: <mac@culver.net>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "mail.netbsd.org", Issuer "R13" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id 7CD311A923D
for <gnats-bugs@gnats.NetBSD.org>; Fri, 16 Jan 2026 22:44:42 +0000 (UTC)
Message-Id: <20260116224434.8155917C4C7D@ss.culver.net>
Date: Fri, 16 Jan 2026 22:44:34 +0000 (UTC)
From: mac@culver.net
Reply-To: mac@culver.net
To: gnats-bugs@NetBSD.org
Subject: NetBSD improperly does not update FAT0 on FAT12 MSDOS filesystem
X-Send-Pr-Version: 3.95
X-From4GNATS: "mac@culver.net via gnats" <gnats-admin@NetBSD.org>
>Number: 59924
>Category: kern
>Synopsis: when files are created/removed from MSDOS FAT12 filesystem, FAT0 is not updated
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Jan 16 22:45:00 +0000 2026
>Last-Modified: Mon Jan 19 05:15:01 +0000 2026
>Originator: mac@culver.net
>Release: NetBSD 10.1
>Organization:
>Environment:
System: NetBSD SS.Culver.Net 10.1 NetBSD 10.1 (MIKE-$Revision: 2025-Dec-27 $) #1: Sun Dec 28 19:39:48 UTC 2025 mac@SS.Culver.Net:/usr/src/sys/arch/amd64/compile/MIKE amd64
Architecture: x86_64
Machine: amd64
"MIKE" is just a rename of GENERIC kernel with no changes.
>Description:
Doing any FAT12 operation that requires updating the FAT fails due to FAT0 not being updated.
Since floppies using FAT12 are still used as an interchange medium, I marked the Severity as "serious".
>How-To-Repeat:
# dmesg | tail -6
[ 1643401.856636] umass3 at uhub1 port 2 configuration 1 interface 0
[ 1643401.856636] umass3: TEACV0.0 (0x0644) TEACV0.0 (0x0000), rev 1.10/2.00, addr 19
[ 1643401.856636] umass3: using UFI over CBI with CCI
[ 1643401.856636] atapibus0 at umass3: 2 targets
[ 1643401.876637] sd3 at atapibus0 drive 0: <TEAC, USB UF000x, 0.00> disk removable
[ 1643402.706681] sd3: 1440 KB, 80 cyl, 2 head, 18 sec, 512 bytes/sect x 2880 sectors
# newfs_msdos /dev/rsd3
/dev/rsd3: 2840 sectors in 355 FAT12 clusters (4096 bytes/cluster)
MBR type: 1 bps=512 spc=8 res=1 nft=2 rde=512 sec=2880 mid=0xf0 spf=2 spt=18 hds=2 hid=0
# fsck_msdos /dev/rsd3
** /dev/rsd3
** Phase 1 - Read and Compare FATs
** Phase 2 - Check Cluster Chains
** Phase 3 - Checking Directories
** Phase 4 - Checking for Lost Files
1 files, 1420 free (355 clusters)
# mount_msdos /dev/sd3a /a
# ls /a
# ls -l /root/floppy/bytes.bin
-rwxr-xr-x 1 root wheel 1536 Jan 1 1970 /root/floppy/bytes.bin*
# cp /root/floppy/bytes.bin /a
# ls /a
bytes.bin*
# umount /a
# fsck_msdos -n /dev/rsd3
** /dev/rsd3
** Phase 1 - Read and Compare FATs
Cluster 144 is marked free in FAT 0, as EOF in FAT 1
use FAT 0's entry? no
use FAT 1's entry? no
This is just the simplest manifestation of this error. when reading or writing files, it gets really screwed up.
I first discovered this by dd'ing this image http://culver.net/NetBSD/dd-msdos-fat12.img.xz
onto a blank floppy; that is an exact construction of 1,474,650 bytes -- it consists of FAT0, FAT1,
the 3 remaining sectors in Cylinder 0 coalesced into BYTES.BIN, and then 79 files, of the form
CYL000XX.BIN where xx goes from 01 to 79, and each file fills a complete cylinder; and the value of
the 18,432 bytes is the "xx" e.g. CYL00065.BIN is filled with the character 'A'.
This behavior can also be demonstrated using vnd:
# ftp http://culver.net/NetBSD/dd-msdos-fat12.img.xz
# unxz dd-msdos-fat12.img.xz
# ls -l dd-msdos-fat12.img
-rw-r--r-- 1 root wheel 1,474,560 Dec 23 03:02 dd-msdos-fat12.img
# md5 dd-msdos-fat12.img
MD5 (dd-msdos-fat12.img) = 67cb3c500cf779b5db6cb704694c4a39
# vnconfig -c vnd0 dd-msdos-fat12.img
# mount_msdos /dev/vnd0a /mnt
# ls /mnt
bytes.bin* cyl00010.bin* cyl00020.bin* cyl00030.bin* cyl00040.bin* cyl00050.bin* cyl00060.bin* cyl00070.bin*
cyl00001.bin* cyl00011.bin* cyl00021.bin* cyl00031.bin* cyl00041.bin* cyl00051.bin* cyl00061.bin* cyl00071.bin*
cyl00002.bin* cyl00012.bin* cyl00022.bin* cyl00032.bin* cyl00042.bin* cyl00052.bin* cyl00062.bin* cyl00072.bin*
cyl00003.bin* cyl00013.bin* cyl00023.bin* cyl00033.bin* cyl00043.bin* cyl00053.bin* cyl00063.bin* cyl00073.bin*
cyl00004.bin* cyl00014.bin* cyl00024.bin* cyl00034.bin* cyl00044.bin* cyl00054.bin* cyl00064.bin* cyl00074.bin*
cyl00005.bin* cyl00015.bin* cyl00025.bin* cyl00035.bin* cyl00045.bin* cyl00055.bin* cyl00065.bin* cyl00075.bin*
cyl00006.bin* cyl00016.bin* cyl00026.bin* cyl00036.bin* cyl00046.bin* cyl00056.bin* cyl00066.bin* cyl00076.bin*
cyl00007.bin* cyl00017.bin* cyl00027.bin* cyl00037.bin* cyl00047.bin* cyl00057.bin* cyl00067.bin* cyl00077.bin*
cyl00008.bin* cyl00018.bin* cyl00028.bin* cyl00038.bin* cyl00048.bin* cyl00058.bin* cyl00068.bin* cyl00078.bin*
cyl00009.bin* cyl00019.bin* cyl00029.bin* cyl00039.bin* cyl00049.bin* cyl00059.bin* cyl00069.bin* cyl00079.bin*
# umount /mnt
# fsck_msdos -n /dev/vnd0a
** /dev/vnd0a
** Phase 1 - Read and Compare FATs
** Phase 2 - Check Cluster Chains
** Phase 3 - Checking Directories
** Phase 4 - Checking for Lost Files
81 files, 0 free (0 clusters)
# mount_msdos /dev/vnd0a /mnt
# rm /mnt/bytes.bin
# umount /mnt
# fsck_msdos -n /dev/vnd0a
** /dev/vnd0a
** Phase 1 - Read and Compare FATs
Cluster 2 continues with cluster 3 in FAT 0, but is marked free in FAT 1
Use continuation from FAT 0? no
Use mark from FAT 1? no
Cluster 3 continues with cluster 4 in FAT 0, but is marked free in FAT 1
Use continuation from FAT 0? no
Use mark from FAT 1? no
Cluster 4 is marked as EOF in FAT 0, free in FAT 1
use FAT 0's entry? no
use FAT 1's entry? no
The AIs have some ideas: https://gemini.google.com/share/2d8a6f3be51a
"FAT #0 is located where NetBSD expects/guards the disklabel sector (sector 1).
Since that sector is protected by default, updates to FAT0 don’t land,
while FAT1 does -— producing the mismatch you’re seeing."
>Fix:
>Audit-Trail:
From: Michael Cheponis <michael.cheponis@gmail.com>
To: gnats-bugs@netbsd.org
Cc: mac@culver.net
Subject: Re: kern/59924: NetBSD improperly does not update FAT0 on FAT12 MSDOS filesystem
Date: Sat, 17 Jan 2026 12:58:46 -0800
--00000000000082580c06489bbbcd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
If you do:
# mount_mdos /dev/sd3a /a
# disklabel -W sd3
THEN you access files on /a normally: add/rm etc, when finished:
# umount /a
# disklabel -N sd3
# fsck_msdos /dev/sd3a
** /dev/rsd3a
** Phase 1 - Read and Compare FATs
** Phase 2 - Check Cluster Chains
** Phase 3 - Checking Directories
** Phase 4 - Checking for Lost Files
81 files, 0 free (0 clusters)
Everything works.
Maybe documentation needs to be updated to show this? Or maybe protection
of cluster 0 needs to be removed when mounting msdos?
On Fri, Jan 16, 2026 at 2:45=E2=80=AFPM <gnats-admin@netbsd.org> wrote:
> Thank you very much for your problem report.
> It has the internal identification `kern/59924'.
> The individual assigned to look at your
> report is: kern-bug-people.
>
> >Category: kern
> >Responsible: kern-bug-people
> >Synopsis: when files are created/removed from MSDOS FAT12
> filesystem, FAT0 is not updated
> >Arrival-Date: Fri Jan 16 22:45:00 +0000 2026
>
>
--00000000000082580c06489bbbcd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small">If you do:</div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small"><br>=
</div><div class=3D"gmail_default" style=3D"font-size:small"><font face=3D"=
monospace"># mount_mdos /dev/sd3a /a</font></div><div class=3D"gmail_defaul=
t" style=3D"font-size:small"><font face=3D"monospace"># disklabel -W sd3</f=
ont></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small">THEN you access=
files on /a normally: add/rm etc, when finished:</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small"><=
br></div><div class=3D"gmail_default" style=3D"font-size:small"><font face=
=3D"monospace"># umount /a</font></div><div class=3D"gmail_default" style=
=3D"font-size:small"><font face=3D"monospace"># disklabel -N sd3</font></di=
v><div class=3D"gmail_default" style=3D"font-size:small"><font face=3D"mono=
space"><br></font></div><div class=3D"gmail_default" style=3D"font-size:sma=
ll"><font face=3D"monospace"># fsck_msdos /dev/sd3a</font></div><div class=
=3D"gmail_default" style=3D"font-size:small"><font face=3D"monospace">** /d=
ev/rsd3a<br>** Phase 1 - Read and Compare FATs<br>** Phase 2 - Check Cluste=
r Chains<br>** Phase 3 - Checking Directories<br>** Phase 4 - Checking for =
Lost Files<br>81 files, 0 free (0 clusters)</font><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small">Everything works.</div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small">=
<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small">Maybe documentation needs to be updated to sho=
w this?=C2=A0 Or maybe protection of cluster 0 needs to be removed when mou=
nting msdos?</div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small"><br></div><div class=3D"gmail_default"=
style=3D"font-family:arial,helvetica,sans-serif;font-size:small"><br></div=
></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr=
" class=3D"gmail_attr">On Fri, Jan 16, 2026 at 2:45=E2=80=AFPM <<a href=
=3D"mailto:gnats-admin@netbsd.org">gnats-admin@netbsd.org</a>> wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">Thank you very muc=
h for your problem report.<br>
It has the internal identification `kern/59924'.<br>
The individual assigned to look at your<br>
report is: kern-bug-people. <br>
<br>
>Category:=C2=A0 =C2=A0 =C2=A0 =C2=A0kern<br>
>Responsible:=C2=A0 =C2=A0 kern-bug-people<br>
>Synopsis:=C2=A0 =C2=A0 =C2=A0 =C2=A0when files are created/removed from=
MSDOS FAT12 filesystem, FAT0 is not updated<br>
>Arrival-Date:=C2=A0 =C2=A0Fri Jan 16 22:45:00 +0000 2026<br>
<br>
</blockquote></div>
--00000000000082580c06489bbbcd--
From: RVP <rvp@SDF.ORG>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/59924: NetBSD improperly does not update FAT0 on FAT12
MSDOS filesystem
Date: Sun, 18 Jan 2026 08:47:06 +0000 (UTC)
```
qemu# uname -a
NetBSD qemu.local 10.1_STABLE NetBSD 10.1_STABLE (GENERIC) #0: Thu Jan 8 10:57:41 UTC 2026 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
qemu# unxz dd-msdos-fat12.img.xz
```
*** (Note the checksum difference, but no matter, the error is elsewhere...)
> # md5 dd-msdos-fat12.img
> MD5 (dd-msdos-fat12.img) = 67cb3c500cf779b5db6cb704694c4a39
>
```
qemu# md5 dd-msdos-fat12.img
MD5 (dd-msdos-fat12.img) = f4ddf3f4e2f0fc8e3b3219e4b2a92876
```
*** (Note the difference in device name throughout.)
> # mount_msdos /dev/vnd0a /mnt
>
```
qemu# ls -fl /dev/vnd0a /dev/vnd0 /dev/vnd0d
brw-r----- 1 root operator 14, 0 Jan 18 07:50 /dev/vnd0a
brw-r----- 1 root operator 14, 3 Jan 18 07:50 /dev/vnd0
brw-r----- 1 root operator 14, 3 Jan 18 07:50 /dev/vnd0d
qemu# mount_msdos /dev/vnd0 /mnt
qemu# ls /mnt/
bytes.bin cyl00014.bin cyl00028.bin cyl00042.bin cyl00056.bin cyl00070.bin
cyl00001.bin cyl00015.bin cyl00029.bin cyl00043.bin cyl00057.bin cyl00071.bin
cyl00002.bin cyl00016.bin cyl00030.bin cyl00044.bin cyl00058.bin cyl00072.bin
cyl00003.bin cyl00017.bin cyl00031.bin cyl00045.bin cyl00059.bin cyl00073.bin
cyl00004.bin cyl00018.bin cyl00032.bin cyl00046.bin cyl00060.bin cyl00074.bin
cyl00005.bin cyl00019.bin cyl00033.bin cyl00047.bin cyl00061.bin cyl00075.bin
cyl00006.bin cyl00020.bin cyl00034.bin cyl00048.bin cyl00062.bin cyl00076.bin
cyl00007.bin cyl00021.bin cyl00035.bin cyl00049.bin cyl00063.bin cyl00077.bin
cyl00008.bin cyl00022.bin cyl00036.bin cyl00050.bin cyl00064.bin cyl00078.bin
cyl00009.bin cyl00023.bin cyl00037.bin cyl00051.bin cyl00065.bin cyl00079.bin
cyl00010.bin cyl00024.bin cyl00038.bin cyl00052.bin cyl00066.bin
cyl00011.bin cyl00025.bin cyl00039.bin cyl00053.bin cyl00067.bin
cyl00012.bin cyl00026.bin cyl00040.bin cyl00054.bin cyl00068.bin
cyl00013.bin cyl00027.bin cyl00041.bin cyl00055.bin cyl00069.bin
qemu# umount /mnt
qemu# fsck_msdos -n /dev/vnd0
** /dev/vnd0
** Phase 1 - Read and Compare FATs
** Phase 2 - Check Cluster Chains
** Phase 3 - Checking Directories
** Phase 4 - Checking for Lost Files
81 files, 0 free (0 clusters)
qemu# mount_msdos /dev/vnd0 /mnt
qemu# rm /mnt/bytes.bin
qemu# umount /mnt
qemu# fsck_msdos -n /dev/vnd0
** /dev/vnd0
** Phase 1 - Read and Compare FATs
** Phase 2 - Check Cluster Chains
** Phase 3 - Checking Directories
** Phase 4 - Checking for Lost Files
80 files, 1 free (3 clusters)
qemu#
```
On Linux:
```
$ fsck.msdos -v dd-msdos-fat12.img
fsck.fat 4.2 (2021-01-31)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "MSDOS5.0"
Media byte 0xf0 (5.25" or 3.5" HD floppy)
512 bytes per logical sector
512 bytes per cluster
1 reserved sector
First FAT starts at byte 512 (sector 1)
2 FATs, 12 bit entries
4608 bytes per FAT (= 9 sectors)
Root directory starts at byte 9728 (sector 19)
224 root directory entries
Data area starts at byte 16896 (sector 33)
2847 data clusters (1457664 bytes)
18 sectors/track, 2 heads
0 hidden sectors
2880 sectors total
Checking for unused clusters.
dd-msdos-fat12.img: 80 files, 2847/2847 clusters
$
```
So, there's only 1 reserved sector, and FAT starts at byte 512. Looks like
A.I. might be right after all. :)
However, I think that since floppies don't have a MBR, you're supposed to
use the whole-disk device for mounting them.
-RVP
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/59924: NetBSD improperly does not update FAT0 on FAT12 MSDOS filesystem
Date: Sun, 18 Jan 2026 09:39:54 -0000 (UTC)
gnats-admin@NetBSD.org ("RVP via gnats") writes:
> So, there's only 1 reserved sector, and FAT starts at byte 512. Looks like
> A.I. might be right after all. :)
>
> However, I think that since floppies don't have a MBR, you're supposed to
> use the whole-disk device for mounting them.
If you access a partition (but not the raw partition) then the
"label sector" (== the partition table) is protected and writes
are blocked with an EROFS error. That allows either partitions
beyond the label sector or safe filesystems like FFS on a "whole disk"
that don't touch the label sector.
Unfortunately, write errors of a filesystem are hidden as they
occur asynchronously to the program doing the write. You may see
kernel messages on the console or logged in /var/log/messages. Only
direct accesses to the device (e.g. newfs writing to /dev/rvnd0a)
would see the error, but in the example newfs was used together
with the raw partition.
So, for a floppy image on a disk device, you need to use the raw partition.
But it is slightly more complicated :)
The driver for a physical floppy (i.e. not some USB stick where you
want to write a floppy image to but the real vintage thing) abuses
the label.
The different partitions are used to select different floppy formats,
e.g. b is a 1.44MB 3.5" disk, c is a 1.2MB 5.25" disk. You must
use the correct partition for the medium and even the 'raw' partition
is abused.
To make this work, the floppy driver has its own private routine
to check write boundaries, and that one just ignores the label
sector.
Writing to a physical floppy therefore doesn't have such problems.
From: Michael Cheponis <michael.cheponis@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
mac@culver.net
Subject: Re: kern/59924: NetBSD improperly does not update FAT0 on FAT12 MSDOS filesystem
Date: Sun, 18 Jan 2026 21:13:06 -0800
--0000000000003053970648b6c112
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I have figured out how to succeed with my use case, which is, indeed, to
use the raw floppy (via e.g. /dev/rsd3a).
And, if one does 'mount_msdos /dev/rsd3a /a[' and then 'disklabel -W sd3a'
then... standard reads / writes to files, deletion, creation, all work
properly.
The PROBLEM, as I see it, is: mount_mdsos needs to, effectively, ALSO do
"disklabel -W <disk>" because otherwise, other parts of the kernel protect
some sectors on cylinder 0 (prevent writes to it) because on other
filesystem types, that's the superblock etc. In the case of MS-DOS,
however, you must keep the two FATs synchronized (they are both in cylinder
0 on an actual 1.44 floppy). FAT 0 is not updated unless 'disklabel -W
<disk>' is performed first.
I created two small shell scripts
msmount:
echo example: msmount sd3a a
# this takes -x bit off msdos files
mount_msdos -m 0644 -M 0755 /dev/$1 /$2
disklabel -W $1
and the corresponding 'msumount' :
echo 'example: msumount sd3a a'
umount /$2
disklabel -N $1
This fixes the problem.
Thanks everybody,
Mike
On Sun, Jan 18, 2026 at 1:45=E2=80=AFAM Michael van Elst via gnats <
gnats-admin@netbsd.org> wrote:
> The following reply was made to PR kern/59924; it has been noted by GNATS=
.
>
> From: mlelstv@serpens.de (Michael van Elst)
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: kern/59924: NetBSD improperly does not update FAT0 on FAT12
> MSDOS filesystem
> Date: Sun, 18 Jan 2026 09:39:54 -0000 (UTC)
>
> gnats-admin@NetBSD.org ("RVP via gnats") writes:
>
> > So, there's only 1 reserved sector, and FAT starts at byte 512. Looks
> like
> > A.I. might be right after all. :)
> >
> > However, I think that since floppies don't have a MBR, you're supposed
> to
> > use the whole-disk device for mounting them.
>
>
> If you access a partition (but not the raw partition) then the
> "label sector" (=3D=3D the partition table) is protected and writes
> are blocked with an EROFS error. That allows either partitions
> beyond the label sector or safe filesystems like FFS on a "whole disk"
> that don't touch the label sector.
>
>
> Unfortunately, write errors of a filesystem are hidden as they
> occur asynchronously to the program doing the write. You may see
> kernel messages on the console or logged in /var/log/messages. Only
> direct accesses to the device (e.g. newfs writing to /dev/rvnd0a)
> would see the error, but in the example newfs was used together
> with the raw partition.
>
> So, for a floppy image on a disk device, you need to use the raw
> partition.
>
>
>
> But it is slightly more complicated :)
>
> The driver for a physical floppy (i.e. not some USB stick where you
> want to write a floppy image to but the real vintage thing) abuses
> the label.
>
> The different partitions are used to select different floppy formats,
> e.g. b is a 1.44MB 3.5" disk, c is a 1.2MB 5.25" disk. You must
> use the correct partition for the medium and even the 'raw' partition
> is abused.
>
> To make this work, the floppy driver has its own private routine
> to check write boundaries, and that one just ignores the label
> sector.
>
> Writing to a physical floppy therefore doesn't have such problems.
>
>
--0000000000003053970648b6c112
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small">I have figured out how to succeed with =
my use case, which is, indeed, to use the raw floppy (via e.g. /dev/rsd3a).=
=C2=A0=C2=A0</div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small"><br></div><div class=3D"gmail_default"=
style=3D"font-family:arial,helvetica,sans-serif;font-size:small">And, if o=
ne does 'mount_msdos /dev/rsd3a /a[' and then 'disklabel -W sd3=
a'=C2=A0 =C2=A0 then... standard reads / writes to files, deletion, cre=
ation, all work properly.</div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small"><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll">The PROBLEM, as I see it, is: mount_mdsos needs to, effectively, ALSO d=
o "disklabel -W <disk>" because otherwise, other parts of t=
he kernel protect some sectors on cylinder 0 (prevent writes to it) because=
on other filesystem types, that's the superblock etc.=C2=A0 In the cas=
e of MS-DOS, however, you must keep the two FATs synchronized (they are bot=
h in cylinder 0 on an actual 1.44 floppy).=C2=A0 FAT 0 is not updated unles=
s 'disklabel -W <disk>' is performed first.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small">I created two small shell scripts</di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small">msmount:</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small"><br></div><div class=3D"gmail_default" style=3D"font-size:small"><=
font face=3D"monospace">echo example: msmount sd3a a<br># this takes -x bit=
off msdos files<br>mount_msdos -m 0644 -M 0755 /dev/$1 /$2<br>disklabel -W=
$1</font></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small"><br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small">and the cor=
responding 'msumount' :</div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div clas=
s=3D"gmail_default" style=3D"font-size:small"><font face=3D"monospace">echo=
'example: msumount =C2=A0sd3a a'<br>umount /$2<br>disklabel -N $1<=
/font><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small"><br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small">This fixes =
the problem.</div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small"><br></div><div class=3D"gmail_default"=
style=3D"font-family:arial,helvetica,sans-serif;font-size:small">Thanks ev=
erybody,</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small">Mike</div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small"><br></div></div><br><div class=3D"gmail_quote gmail_quote_c=
ontainer"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jan 18, 2026 at 1:4=
5=E2=80=AFAM Michael van Elst via gnats <<a href=3D"mailto:gnats-admin@n=
etbsd.org">gnats-admin@netbsd.org</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">The following reply was made to PR kern/59=
924; it has been noted by GNATS.<br>
<br>
From: <a href=3D"mailto:mlelstv@serpens.de" target=3D"_blank">mlelstv@serpe=
ns.de</a> (Michael van Elst)<br>
To: <a href=3D"mailto:gnats-bugs@netbsd.org" target=3D"_blank">gnats-bugs@n=
etbsd.org</a><br>
Cc: <br>
Subject: Re: kern/59924: NetBSD improperly does not update FAT0 on FAT12 MS=
DOS filesystem<br>
Date: Sun, 18 Jan 2026 09:39:54 -0000 (UTC)<br>
<br>
=C2=A0gnats-admin@NetBSD.org ("RVP via gnats") writes:<br>
<br>
=C2=A0> So, there's only 1 reserved sector, and FAT starts at byte 5=
12. Looks like<br>
=C2=A0> A.I. might be right after all. :)<br>
=C2=A0> <br>
=C2=A0> However, I think that since floppies don't have a MBR, you&#=
39;re supposed to<br>
=C2=A0> use the whole-disk device for mounting them.<br>
<br>
<br>
=C2=A0If you access a partition (but not the raw partition) then the<br>
=C2=A0"label sector" (=3D=3D the partition table) is protected an=
d writes<br>
=C2=A0are blocked with an EROFS error. That allows either partitions<br>
=C2=A0beyond the label sector or safe filesystems like FFS on a "whole=
disk"<br>
=C2=A0that don't touch the label sector.<br>
<br>
<br>
=C2=A0Unfortunately, write errors of a filesystem are hidden as they<br>
=C2=A0occur asynchronously to the program doing the write. You may see<br>
=C2=A0kernel messages on the console or logged in /var/log/messages. Only<b=
r>
=C2=A0direct accesses to the device (e.g. newfs writing to /dev/rvnd0a)<br>
=C2=A0would see the error, but in the example newfs was used together<br>
=C2=A0with the raw partition.<br>
<br>
=C2=A0So, for a floppy image on a disk device, you need to use the raw part=
ition.<br>
<br>
<br>
<br>
=C2=A0But it is slightly more complicated :)<br>
<br>
=C2=A0The driver for a physical floppy (i.e. not some USB stick where you<b=
r>
=C2=A0want to write a floppy image to but the real vintage thing) abuses<br=
>
=C2=A0the label.<br>
<br>
=C2=A0The different partitions are used to select different floppy formats,=
<br>
=C2=A0e.g. b is a 1.44MB 3.5" disk, c is a 1.2MB 5.25" disk. You =
must<br>
=C2=A0use the correct partition for the medium and even the 'raw' p=
artition<br>
=C2=A0is abused.<br>
<br>
=C2=A0To make this work, the floppy driver has its own private routine<br>
=C2=A0to check write boundaries, and that one just ignores the label<br>
=C2=A0sector.<br>
<br>
=C2=A0Writing to a physical floppy therefore doesn't have such problems=
.<br>
<br>
</blockquote></div>
--0000000000003053970648b6c112--
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home