Re: -current buildworld stoppage

On Sun, Oct 11, 2026 at 11:47:21AM -0700, Mark Millard wrote:
> On 10/11/26 08:27, bob prohaska wrote:
> > On Sat, Oct 10, 2026 at 03:08:18PM -0700, Mark Millard wrote:
> >>
> >> I'm not suggesting drive or cable failures, though I can not rule them
> >> out. If you had such, testing the an alternate same type of drive setup
> >> that would use the same drivers would be a cross check on such by seeing
> >> if only the one device gets failures. (Not that you have the means of
> >> doing such testing.)
> > 
> > It isn't obvious how to swap drives without also disturbing cables, somewhat
> > invalidating the test. 
> 
> No testing is even less information. In general any physical testing
> involves multiple subsystems that might be contributing. Testing is
> difficult but provides more information.
> 
> > In the past at least a few problems, usually on boot,
> > have been seemingly cleared by re-seating USB connectors or microSD cards.
> > 
> > In the last couple of days a string of lines resembling
> > find: input/output error <pathname> 
> > have been showing up in the daily security email.
> 
> 
> That means EIO (errno 5), if what I read is correct.
> 
> This suggests possibilities:
> 
> ) physical drive failures
> ) file system corruptions
> ) connection problems
>

At this point re-seating the connectors looks like a
reasonable thing to try.  
> (No network drive is involved as I understand.)

That is correct.

> 
> 
> Did you check you kernel messages in /var/log/messages* for the right
> time frames? (Recent live contexts you could use dmsg -a or the like.)
> Even without the detailed time frames for the specific find reports,
> finding any appropriate errors over the days is relevant to report.
>

The machine has been running installworld all afternoon and dmesg is
reporting a steady stream of errors but it isn't giving up, for example

/usr: inode 84028739: check-hash failed
/usr: inode 84028739: check-hash failed
/usr: inode 84028739: check-hash failed
/usr: inode 84028739: check-hash failed
/usr: inode 84028744: check-hash failed
/usr: inode 84028744: check-hash failed
/usr: inode 84028744: check-hash failed
/usr: inode 84028744: check-hash failed
/usr: bad dir ino 90930262 at offset 0: mangled entry
/usr: bad dir ino 90930262 at offset 0: mangled entry
/usr: bad dir ino 90930284 at offset 0: mangled entry
/usr: bad dir ino 90930284 at offset 512: mangled entry
/usr: bad dir ino 90930284 at offset 0: mangled entry

Am I correct in guessing it's succeeding after some
amount of re-trying?  
> Do you have smartmontools installed so that you could do a:
> smartctl -a /dev/... or the like?
> 
> 

I just checked and apparently don't, though I think the
drive does support smartmontools. I'll try compiling it
after installworld finishes, assuming it does finish 8-) 

> > The ssh 
> > window used didn't preserve the lines but I could try to
> > save them if it's of interest to anybody. In the meantime
> > the machine's been running a -j4 buildworld without disaster,
> > no errors on the serial console either.
> > 
> > Thanks for writing, I'll keep poking at the problem(s).
> > 
> > bob prohaska
> 
> 
> I will note that trying to repair a failing storage subsystem can make
> things worse, such as repairing via fsk use. Generally, if there is
> evidence of failures suggesting drive replacements, the point is
> normally to duplicate to some other media anything that should be
> preserved first, instead of disturbing it first. Repair attempts come
> after preserving what one can that one wants preserved.
>

Fortunately this is a test machine so nothing to lose. I did have hopes
that it might be backed down to a stable release and used as a nameserver,
that plan may have to wait.  
> For boot media, this normally means no longer booting the media and/oir
> having the media as strictly read-only.

The usual boot failures seem to be warm (shutdown -r), power cycling
always seems to boot hands-off. When boot fails, it's usually a hang
in uboot with loss of console control.  

It looks like the install has finished successfully. What's your guess
for the first thing to try? I think mine would be to shutdown to power
off, reset the USB connectors and attempt a restart. If something else
comes to your mind please let me know!

Thanks for writing,

bob prohaska