On 28/05/2026 17:39, Richard Kettlewell wrote:

Mike Scott <usenet.16@scottsonline.org.uk.invalid> writes:

Hi all. I always seem to get impossible problems....

Take a pi4 and two disks - both sata connected by a sata to usb
adapter. One is a small real disk drive, the other a Kingston
SSD. Both have been in the spares cupboard for a while.

I put an old arm64 version of bookworm onto the spinner. Works fine.

I put the exact same onto the ssd. Won't boot, with messages like
timed out waiting for udev to be empty
or
read error on /dev/sda [details not recorded]

Boot the Pi from the spinning disk (or an SD card) and connect the SSD
to the Pi. See if you can access it and if not, have a look at the
kernel log.

Already did - I ran one full pass with baddisk -w which completed with
zero errors.


--
Mike Scott
Harlow, England

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi all. I always seem to get impossible problems....

Take a pi4 and two disks - both sata connected by a sata to usb adapter.
One is a small real disk drive, the other a Kingston SSD. Both have been
in the spares cupboard for a while.

I put an old arm64 version of bookworm onto the spinner. Works fine.

I put the exact same onto the ssd. Won't boot, with messages like
timed out waiting for udev to be empty
or
read error on /dev/sda [details not recorded]

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've swapped the pi4 psu for a pi5 psu in case supply current was an
issue. No change.

I've run dd over much of the ssd (under mint) both reading and writing,
but no errors.


Is there anything weird that I might have missed about booting from an
ssd rather than a real disk?


TIA for any thoughts.


--
Mike Scott
Harlow, England


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Mike Scott <usenet.16@scottsonline.org.uk.invalid> writes:

Hi all. I always seem to get impossible problems....

Take a pi4 and two disks - both sata connected by a sata to usb
adapter. One is a small real disk drive, the other a Kingston
SSD. Both have been in the spares cupboard for a while.

I put an old arm64 version of bookworm onto the spinner. Works fine.

I put the exact same onto the ssd. Won't boot, with messages like
timed out waiting for udev to be empty
or
read error on /dev/sda [details not recorded]

Boot the Pi from the spinning disk (or an SD card) and connect the SSD
to the Pi. See if you can access it and if not, have a look at the
kernel log.

--
https://www.greenend.org.uk/rjk/

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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

Peal currents may easily exceed USB ability as well

I've got similar issues here but I have not got to the end of that road yet

--
For every complex problem there is an answer that is clear, simple, and
wrong.

H.L.Mencken


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

--
Mike Scott
Harlow, England

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 28/05/2026 21:30, Mike Scott wrote:

On 28/05/2026 17:39, Richard Kettlewell wrote:

Mike Scott <usenet.16@scottsonline.org.uk.invalid> writes:

Hi all. I always seem to get impossible problems....

Take a pi4 and two disks - both sata connected by a sata to usb
adapter. One is a small real disk drive, the other a Kingston
SSD. Both have been in the spares cupboard for a while.

I put an old arm64 version of bookworm onto the spinner. Works fine.

I put the exact same onto the ssd. Won't boot, with messages like
timed out waiting for udev to be empty
or
read error on /dev/sda [details not recorded]

Boot the Pi from the spinning disk (or an SD card) and connect the SSD
to the Pi. See if you can access it and if not, have a look at the
kernel log.

Already did - I ran one full pass with baddisk -w which completed with
zero errors.

Why don't you tray what Richard suggested?


--
Chris

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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)

Mike Scott <usenet.16@scottsonline.org.uk.invalid> writes:

Richard Kettlewell wrote:

Mike Scott <usenet.16@scottsonline.org.uk.invalid> writes:

Hi all. I always seem to get impossible problems....

Take a pi4 and two disks - both sata connected by a sata to usb
adapter. One is a small real disk drive, the other a Kingston
SSD. Both have been in the spares cupboard for a while.

I put an old arm64 version of bookworm onto the spinner. Works fine.

I put the exact same onto the ssd. Won't boot, with messages like
timed out waiting for udev to be empty
or
read error on /dev/sda [details not recorded]

Boot the Pi from the spinning disk (or an SD card) and connect the
SSD to the Pi. See if you can access it and if not, have a look at
the kernel log.

Already did - I ran one full pass with baddisk -w which completed with
zero errors.

Never heard of baddisk, what is that?

Anyway from what you?ve said, Linux on the Pi can?t see the SSD during
early boot, but can see it when attached to the Pi later. That?s hard to explain, since it?s the same hardware and the same code looking for it
in each case.

Just to check, did you run your ?full pass with baddisk? _on the Pi_, as requested above?

--
https://www.greenend.org.uk/rjk/

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 09:19, Richard Kettlewell wrote:

Mike Scott <usenet.16@scottsonline.org.uk.invalid> writes:

Richard Kettlewell wrote:

Mike Scott <usenet.16@scottsonline.org.uk.invalid> writes:

Hi all. I always seem to get impossible problems....

Take a pi4 and two disks - both sata connected by a sata to usb
adapter. One is a small real disk drive, the other a Kingston
SSD. Both have been in the spares cupboard for a while.

I put an old arm64 version of bookworm onto the spinner. Works fine.

I put the exact same onto the ssd. Won't boot, with messages like
timed out waiting for udev to be empty
or
read error on /dev/sda [details not recorded]

Boot the Pi from the spinning disk (or an SD card) and connect the
SSD to the Pi. See if you can access it and if not, have a look at
the kernel log.

Already did - I ran one full pass with baddisk -w which completed with
zero errors.

Never heard of baddisk, what is that?

My bad - I meant 'badblocks'.

Anyway from what you?ve said, Linux on the Pi can?t see the SSD during
early boot, but can see it when attached to the Pi later. That?s hard to explain, since it?s the same hardware and the same code looking for it
in each case.

Just to check, did you run your ?full pass with baddisk? _on the Pi_, as requested above?

Yes.

The problem does look as though it was down to a combo of the ssd plus
one particular sata/usb adapter (I have 3). Using dd, I found transfer
rates down to <10MB with the ssd and that particular adapter.

The issue does seem to centre around the combo of ssd, that particular adapter, and the pi4. I get decent transfer rates using my desktop with
all the adapters; just the pi4 has issues with that one, fine with the
other 2.

Anyway, I have a system that has now booted several times without issue,
which is great.

Thanks to all for commenting.





--
Mike Scott
Harlow, England

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 29 May 2026 12:57:05 +0100, Mike Scott wrote:

My bad - I meant 'badblocks'.

I stopped using badblocks when I found it couldn?t handle drives
larger than about 4TiB.

I wrote my own utility for doing scans
<https://gitlab.com/ldo/scan_disks/>, that can work on larger drives.
This only does reads for now.

For writes, I still use dd.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 12:57, Mike Scott wrote:

The problem does look as though it was down to a combo of the ssd plus
one particular sata/usb adapter (I have 3).

Are these three different models, or just three pieces of kit that
should be the same but aren't?

It might be useful to the rest of us to know which makes/models or
USB/SATA adaptor you have found do work, and with which HDDs/SDDs, and
which do not.

--
Cheers,
Daniel.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/29/26 04:42, bp@www.zefox.net wrote:

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.

+1

My rpi4 UBS 3 sockets failed, I suspect due to feeding power back into
the port from a powered SATA to USB connector.

The USB 2 ports still work fine.

This USB failure was slow. USB 3failure started as occasional SSD write errors, gradually becoming more regular.

It took me a while to diagnose as the problem was intermittent and there
was nothing wrong with the disk itself.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 31/05/2026 23:57, Pancho wrote:

On 5/29/26 04:42, bp@www.zefox.net wrote:

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.

+1

My rpi4 UBS 3 sockets failed, I suspect due to feeding power back into
the port from a powered SATA to USB connector.

The USB 2 ports still work fine.

This USB failure was slow. USB 3failure started as occasional SSD write errors, gradually becoming more regular.

It took me a while to diagnose as the problem was intermittent and there
was nothing wrong with the disk itself.

I would be surprised if the fault was caused by back powering. The
superspeed signals are capacitor coupled. The client end of the
connection does not transmit anything until the host has
completed a probe operation to look for the correct termination
resistance at the client end. Therefore there would never
be any attempt at superspeed data transmission if the host was
unpowered.
John


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/1/26 10:35, John R Walliker wrote:

On 31/05/2026 23:57, Pancho wrote:

On 5/29/26 04:42, bp@www.zefox.net wrote:

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.

+1

My rpi4 UBS 3 sockets failed, I suspect due to feeding power back into
the port from a powered SATA to USB connector.

The USB 2 ports still work fine.

This USB failure was slow. USB 3failure started as occasional SSD
write errors, gradually becoming more regular.

It took me a while to diagnose as the problem was intermittent and
there was nothing wrong with the disk itself.

I would be surprised if the fault was caused by back powering.ÿ The superspeed signals are capacitor coupled.ÿ The client end of the
connection does not transmit anything until the host has
completed a probe operation to look for the correct termination
resistance at the client end.ÿ Therefore there would never
be any attempt at superspeed data transmission if the host was
unpowered.
John

I do not understand your comment. I do not understand the relevance of
super speed transmission, or possibly I don't understand what the term
means. I don't understand client/host.

For clarity, the back powering I observed was on powering down my rPi 4.
When I removed the standard rPi4 USB power supply the rPi4 would remain powered on. The rPi4 would only power down when the USB/SATA adapter
power was disconnected. i.e. In this scenario the rPi4 was being powered
by a USB 3 data port.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 31/05/2026 23:57, Pancho wrote:

My rpi4 UBS 3 sockets failed, I suspect due to feeding power back into
the port from a powered SATA to USB connector.

I use a Pi for a PVR, recording TV programmes to a spinning USB HDD that
is connected to a powered USB hub (so the HDD is not being powered by
the Pi's USB).

When I used a Pi3, this worked perfectly. When I switched to using a
Pi4, with the same HDD and hub, the Pi consistently hung very early in
the boot process. As soon as I unplugged the hub from the Pi (or removed
the hub's PSU) the Pi continued the boot process. (*)

It was a problem mainly if there had been a power cut and the power to
both the Pi and the hub was turned on at the same time (when the power
came back).

Someone suggested back-powering might be the cause, so I made up a
special cable which had its +5V line cut and connected it between the Pi
and the hub. Sadly this made no difference.

Powering the HDD from the Pi's power, via USB, worked fine - but I was
uneasy about drawing so much current from the Pi's PSU in case the
voltage ever sagged to the point that the Pi started to misbehave.

I solved the problem by changing to use a SATA HDD in a caddy that had a powered SATA-USB interface.


So the Pi4 seems to be more sensitive to powered devices than the Pi3.
I'm not sure about the Pi5 as I've only used USB-powered SD cards as
slave drives.



All of this is talking about an HDD that is used as a data disk. I still
boot off an SD card plugged into the Pi's motherboard, in the standard way.



(*) I forget how far the boot got before it hung. It might have been
before there was *any* image on a monitor connected to the HDMI port,
which isn't a great deal of help...

--- PyGate Linux v1.5.16
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hello NY!

12 Jun 26 20:58, you wrote to all:

On 31/05/2026 23:57, Pancho wrote:

My rpi4 UBS 3 sockets failed, I suspect due to feeding power back
into the port from a powered SATA to USB connector.

I use a Pi for a PVR, recording TV programmes to a spinning USB HDD
that is connected to a powered USB hub (so the HDD is not being
powered by the Pi's USB).

When I used a Pi3, this worked perfectly. When I switched to using a
Pi4, with the same HDD and hub, the Pi consistently hung very early in
the boot process. As soon as I unplugged the hub from the Pi (or
removed the hub's PSU) the Pi continued the boot process. (*)

It was a problem mainly if there had been a power cut and the power to
both the Pi and the hub was turned on at the same time (when the
power came back).

Someone suggested back-powering might be the cause, so I made up a
special cable which had its +5V line cut and connected it between the
Pi and the hub. Sadly this made no difference.

Powering the HDD from the Pi's power, via USB, worked fine - but I was
uneasy about drawing so much current from the Pi's PSU in case the
voltage ever sagged to the point that the Pi started to misbehave.

I solved the problem by changing to use a SATA HDD in a caddy that had
a powered SATA-USB interface.

So the Pi4 seems to be more sensitive to powered devices than the Pi3.
I'm not sure about the Pi5 as I've only used USB-powered SD cards as
slave drives.

All of this is talking about an HDD that is used as a data disk. I
still boot off an SD card plugged into the Pi's motherboard, in the
standard way.

(*) I forget how far the boot got before it hung. It might have been
before there was *any* image on a monitor connected to the HDMI port,
which isn't a great deal of help...

I have a pi3 and had a 4 and for both use a secondary Power adaptor where for the 4 bought a laptop adaptor with the correct power outputs.

The 3 uses a HDD and the 4 used a SSD but the adaptor for it will power a HDD.

Basically the supplied power adaptors for these units is does not have enough grunt for the power requirements i.e., amps etc.

Vincent


--- Mageia Linux v9 X64/Mbse v1.1.7/GoldED+/LNX 1.1.5-b20240604
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

On Fri, 12 Jun 2026 20:58:07 +0100, NY wrote:

When I used a Pi3, this worked perfectly. When I switched to using a
Pi4, with the same HDD and hub, the Pi consistently hung very early
in the boot process. As soon as I unplugged the hub from the Pi (or
removed the hub's PSU) the Pi continued the boot process. (*)

Did it matter when in the process the drive was mounted?

--- PyGate Linux v1.5.16
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)