@MSGID: 3:633/10 34536849
@REPLY: 3:633/10 77ef973a
@PID: PyGate 1.5.15
@TID: PyGate/Linux 1.5.15
@NOTE: tin/2.6.4-20241224 ("Helmsdale")
(FreeBSD/14.4-STABLE (arm64))
@CHRS: ASCII 1
@TZUTC: 1100
@REPLYADDR: bp@www.zefox.net
@REPLYTO: 3:633/10 UUCP
@RFC-Message-ID: <10vb201$3sndh$2@dont-email.me>
The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 28/05/2026 16:38, Mike Scott wrote:
>> On 28/05/2026 16:27, Mike Scott wrote:
>>> there seems to be no obvious fault with the ssd as such - it was 
>>> working as expected when put into storage, and a scan with badblock -w 
>>> is currently at 80% with no errors.
>>>
>> 
>> I should add, the pi4 is running from the spinner, while checking the 
>> ssd. 89% checked, 0 errors as I write.
>> 
>> Also, a second pi4 has the same issue, so it`s not a faulty pi4.
>> 
> Some disks with some USB adapters simply do not work
> 

Two thoughts: 

Try a different USB bridge on the SSD. 
Some behave better than others. 

Maybe try different software on the SSD. I`ve worked 
quite a bit with FreeBSD, It lets the Pi firmware
start u-boot to find the disk. Maybe that`ll work
or give some opportunity to tinker with the disk
probe (changing usb_pgood_delay in uboot.env has
been helpful in some cases). 

You`d want 
https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/15.0/FreeBSD-15.0
-RELEASE-arm64-aarch64-RPI.img.xz

FreeBSD won`t solve the problem, but it might provide some insights.
You might need a serial console to see what`s going on.

hth,

bob prohaska

--- PyGate Linux v1.5.15
 * Origin: Dragon`s Lair, PyGate NNTP<>Fido Gate (3:633/10)
SEEN-BY: 19/10 50/109 153/757 218/840 840 220/70
221/1 6 360 226/17 100
SEEN-BY: 229/426 240/1120 267/800 301/1 113 812
310/31 335/364 341/66 463/68
SEEN-BY: 633/10 280 414 416 418 420 422 509 2744
712/848 770/1 3 100 340 350
SEEN-BY: 772/210 220 230 5019/40 5020/715 848 1042
4441 12000 5030/49 722
SEEN-BY: 5030/1081 1474 5053/55 5061/133 5075/128
@PATH: 633/10 280 770/1 218/840 221/6 301/1
5020/1042 4441