initrd flash failed with "Error looking up object for device"

[CHNtentes]

Hi. I'm using Orin NX 16GB.

When I use initrd flash to flash nvme disk, occasionally (around 10%~20%?) the script will print something like this:

== Step 3: Sending flash sequence commands at 2023-08-30T11:15:08+08:00 ==
Waiting for USB storage device flashpkg from a5040405........[/dev/sdc]
Device size in blocks: 262144
Error looking up object for device /dev/sdc
ERR: could not mount USB storage for writing flashing commands
== Step 4: Writing partitions on external storage device at 2023-08-30T11:15:35+08:00 ==
Waiting for USB storage device nvme0n1 from a5040405...[got flashpkg when expecting nvme0n1]
ERR: could not find nvme0n1

Here is host-side log:
log.initrd-flash.2023-08-30-11.14.46.txt

And UART log from device:
flash_failure.txt

What shall I do to further analyse it? Thanks in advance.

[madisongh]

The Error looking up object for device error is coming from one of the udisksctl commands. It sounds from this that there might be sometimes be races that could cause failures of this sort. Are you seeing this consistently, or only once in a while? We might be able to add some retries in the initrd-flash script if this is something that happens a lot.

[CHNtentes]

Thanks for your reply.
I'd say it's not really frequent, and most of the time it works flawlessly.
If you don't want to affect others' code, you could instruct me on what code to add, and I'll do some test to see the result.

[madisongh]

I suspect the error is coming from the udisksctl mount command in the mount_partition() function in the initrd-flash script. Adding a retry loop there (maybe with a short sleep in between tries) might be enough to work around the problem. It's possible that adding in a wait for a change under /sys/bus/usb/devices/<bus>-<device> before attempting the mount might also help... but based on the discussion I mentioned above, though, I'm not sure there's a good way to ensure that the notification about the presence of the new device has been fully propagated into the udisks2 daemon.