Re: Filesystem errors on armv7 -current

On 10/19/26 08:57, Warner Losh wrote:
> 
> 
> On Mon, Oct 19, 2026 at 9:40 AM bob prohaska <fbsd@www.zefox.net
> <mailto:fbsd@www.zefox.net>> wrote:
> 
>     A Pi2B running
>     FreeBSD pelorus.zefox.org <http://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 <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

Unfortunately, Bob did not explicitly reference prior notes about his
problem. Hepreviously  published an example security-notice email file
with various types of error/warning reports and I had replied based on
what I noticed as distinct context properties from prior on-list
discussions. There were, for example, find: . . .: Input/output error
messages that repeat in different uses of the find command:

QUOTE
>
> I've placed a sample of security email at
>
http://www.zefox.net/~fbsd/rpi2/crashes/_-current_buildworld_stoppage/pelorus_security_email
> as it's the most complete report generated recently. It follows a cycle of
> git pull, system build and install, along with an update to poudriere
but no ports git pull.
> That makes a large chunk of the warnings normal, somewhat more look
like trouble.

The most significant thing I see is repeatability:

Checking setuid files and devices:
find: /usr/ports/devel/py-anyio3: Input/output error
. . .
find: /usr/src/contrib/llvm-project/llvm/lib/Target/AVR: Input/output error

Checking negative group permissions:
find: /usr/ports/devel/py-anyio3: Input/output error
. . .
find: /usr/src/contrib/llvm-project/llvm/lib/Target/AVR: Input/output error

Those lists exactly agree. Most of the messages look to be EIO related
messages indicating low level I/O failures. Some are "Invalid argument",
for which it is not clear to me just what leads to the message.

>
> I just noticed a small mismatch between kernel and world:
> # uname -apKU
> FreeBSD pelorus.zefox.org 16.0-CURRENT FreeBSD 16.0-CURRENT #71
main-n289010-f02f93e79147-dirty: Thu Sep 10 07:55:05 PDT 2026
bob@pelorus.zefox.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm armv7
1600025 1600027
> If that looks significant perhaps the machine should be rebooted to
> bring them into sync.

The FreeBSD kernel bias/design-goal is for newer kernels to support
older worlds (going back some distance). The other way around is not
guaranteed, even though the official package builders usually have older
kernel and newer poudriere jail worlds. (poudriere jails do no not run
as much software as the boot world does.)
END QUOTE

There might be more of note in:

<http://www.zefox.net/~fbsd/rpi2/crashes/_-current_buildworld_stoppage/pelorus_security_email>


(I probably should have mentioned the the newer poudriere jails are only
in the the context of main boot-kernel/boot-world/poudriere-jails.
Release poudriere-jails count was older than main.)


-- 
===
Mark Millard
marklmi at yahoo.com