FYI: Example USB3 boot failure on RPi4B ZFS-on-root system booting

[Mark Millard via freebsd-arm]

In upgrading from (grabbed from a system not updated yet):

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n246411-a6ca7519f89c-dirty: Sat May 1 19:07:50 PDT 2021 ***@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400013 1400013

to (using a debug-build variant here):

# uname -apKU
FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n246854-03b0505b8fe8-dirty: Sat May 22 16:25:04 PDT 2021 ***@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-DBG-CA72 arm64 aarch64 1400013 1400013

I was initially unable to boot. It seems to trace
back to getting the uhub_reattach_port notices
in the below sequence:

Root mount waiting for: usbus0 CAM
Root mount waiting for: usbus0 CAM
uhub_reattach_port: port 3 reset failed, error=USB_ERR_TIMEOUT
uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 3
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Solaris: NOTICE: Cannot find the pool label for 'zroot'
Mounting from zfs:zroot/ROOT/main-CA72-dbg failed with error 5; retrying for 10 more seconds
Solaris: NOTICE: Cannot find the pool label for 'zroot'
Solaris: NOTICE: Cannot find the pool label for 'zroot'
. . .
mountroot> ?

List of GEOM managed disk devices:


mountroot>

The USB3 SSD was the only storage media present.
Port 3 apparently had the USB3 SSD boot media (the
same media that the FreeBSD loader got the kernel
from before the above).

Cutting power and starting over did not get the
problem again (so far).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[tech-lists]

Hi,

Post by Mark Millard via freebsd-arm
The USB3 SSD was the only storage media present.
Port 3 apparently had the USB3 SSD boot media (the
same media that the FreeBSD loader got the kernel
from before the above).

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666 might be
relevant

[tech-lists]

Hi,

Post by Mark Millard via freebsd-arm
. . .
mountroot> ?
mountroot>
The USB3 SSD was the only storage media present.
Port 3 apparently had the USB3 SSD boot media (the
same media that the FreeBSD loader got the kernel
from before the above).

This happened with my experimental rpi4-boot-to-zfs-only system too, a
couple of days ago. Unfortunately I didn't note what it was made from in
git. Maybe a week ago?

Post by Mark Millard via freebsd-arm
Cutting power and starting over did not get the
problem again (so far).

If by "starting over" you mean cold booting, then yeah same thing
happened here. A buildworld/buildkernel/install has happened since then;
it's now on n246839, and the problem hasn't so far re-occurred.

[Mark Millard via freebsd-arm]

Post by tech-lists

Post by Mark Millard via freebsd-arm
. . .
mountroot> ?
mountroot>
The USB3 SSD was the only storage media present.
Port 3 apparently had the USB3 SSD boot media (the
same media that the FreeBSD loader got the kernel
from before the above).

This happened with my experimental rpi4-boot-to-zfs-only system too, a
couple of days ago. Unfortunately I didn't note what it was made from in
git. Maybe a week ago?

Post by Mark Millard via freebsd-arm
Cutting power and starting over did not get the
problem again (so far).

If by "starting over" you mean cold booting,

Sorry for the horribly ambiguous wording. Yes: just
turning on the power again.

Post by tech-lists
then yeah same thing
happened here. A buildworld/buildkernel/install has happened since then;
it's now on n246839, and the problem hasn't so far re-occurred.

Side note:

I'll note that using the likes of just "n246839" to
identify a specific commit is messy so far as I
know (even given the branch is known).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)