Re: Filesystem errors on armv7 -current

On Mon, Oct 19, 2026 at 9:40 AM bob prohaska <fbsd@www.zefox.net> wrote:

> A Pi2B running
> FreeBSD pelorus.zefox.org 16.0-CURRENT FreeBSD 16.0-CURRENT #76
> main-n289925-6c305c3c3129: Sun Oct 11 15:20:02 PDT 2026
>  bob@pelorus.zefox.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm armv7
> 1600027 1600028
>
> is reporting errors during installworld of the form
>
> /usr: inode 67896768: check-hash failed
>
> and
>
> UFS /dev/da0s2d (/usr) cylinder checkhash failed: cg 846, cgp: 0xce917fd
> != bp: 0x4e2a15c5
>

So this is a data corruption bug. Almost certainly. It may be related to
caching (or memory observability), or it may be something else. If the
errors are on boot, then something is writing it before the system went
down. If this occurs at runtime, it is likely a transfer error.


> There's an old bug report,
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267654
>
> which looks somewhat similar but is marked "Closed FIXED".
>

So symptoms may be the same, but the root cause is likely different.


> So far, the errors have not resulted in any build or install stoppages,
> but the install and reboot haven't completed yet.
>
> Is it worth reporting this behavior as a new bug? Old bug? Other? Not?
>

New bug. For the love of all that's holy, do not reopen the old bug.


> It's true that the kernel lags world by one index digit. Not sure how
> that happened.
>
> I can post console output, but it's mostly repetitive, as if the
> errors correct eventually or are ignored.
>
> /etc/fstab contains
>
> # more /etc/fstab
> # Custom /etc/fstab for FreeBSD embedded images
> #/dev/ufs/rootfs                /               ufs     rw              1
>             1
> #/dev/msdosfs/EFI               /boot/efi       msdosfs rw,noatime      0
>             0
> #tmpfs                  /tmp            tmpfs   rw,mode=1777    0       0
>
> /dev/da0s2a     /       ufs     rw      1       1
> /dev/da0s2d    /usr    ufs     rw      1       1
> /dev/da0s1      /boot/msdos msdosfs rw,noatime 0 0
> /dev/da0s2b     none    swap    sw
>
> Swap is
>
> # swapinfo
> Device          1K-blocks     Used    Avail Capacity
> /dev/da0s2b       1843200    15644  1827556     1%
> so below the warning limit
>
> The storage device is SATA spinning rust on
> ugen0.6: <JMS578 SATA 6Gb/s JMicron Technology Corp. / JMicron USA
> Technology Corp.> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
>

So  what's the actual disk? It could be that the disk is going bad too.
Though JMicron has a history of dodgy adapters (though that history
pre-dates this one, I think).

tl;dr: This is rare data corruption, but any is bad. So far, though, there
doesn't seem to be enough to trace the problem.  I suggest A/B tests if you
can, starting with a different non-JMicron-based USB adapter.

Warner