Re: -current buildworld stoppage

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

(No network drive is involved as I understand.)


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.

Do you have smartmontools installed so that you could do a:
smartctl -a /dev/... or the like?


> 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.

For boot media, this normally means no longer booting the media and/oir
having the media as strictly read-only.


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