I have the same problem. If I compare a working boot file-system from January 31st to the one modified by zypper in February and taking the observations from reporter I find boot file-system files having boot in the name:

# January boot file-system:
-rw-r--r--  1 auser users  690912 Feb 17  2023 u-boot.bin

# February update boot file-system:
-rw-r--r--  1 auser users  690912 Feb 17  2023 u-boot.bin
-rw-r--r--  1 auser users  270372 Jan 30  2023 u-boot.bin.20230130.xz

Assuming the u-boot.bin.20230130.xz has some purpose, I repeated the reporter's method but kept the u-boot.20230130.xz file on the boot file-system.
NO CHANGE, CAN'T BOOT FROM USB DISKS.
I get some message about "our firmware doesn't support a setup menu from a boot loader"

Used strings to look for identity information from the u-boot files from the January and February zypper updates, plus the expanded u-boot.bin.20230130.xz:

Zypper update January u-boot.bin:
U-Boot 2023.01 (Feb 13 2023 - 00:00:00 +0000)

Zypper update February u-boot.bin:
2H53F6CDBAU-Boot 2024.01 (Jan 12 2024 - 00:00:00 +0000)

The zypper update February u-boot.bin.20230130.xz after de-compressing:
U-Boot 2023.01 (Jan 27 2023 - 00:00:00 +0000)


The zypper update in February broke u-boot RPi systems booting from USB disks.

Zaoliang, I think you also found/reported a similar issue right?

I'm unable to get the solution from Stefan (Reporter) to work on 8GB RPi4b systems.

It fails loading the boot loader FUSE images (At least what are mounted from images on the rootfs:/boot/ directory as /boot/efi and /boot/grub2/<arch>, possibly grub /boot/vc as well).

I took a working micro-sd RPi Tumbleweed installation and on the rootfs tried moving /boot to /boot.brick and copying /boot from the micro-sd to the USB disk.

renamed /boot to /boot/.brick
copied the whole diretory tree /boot from the working sda to to the USB disk.
I made the file-systems ID the same on the USB disk as those on the micro-sd.

NO SUCCESS, I still have BRICKED RPi 4b devices. I do now get as far as the boot file-system product selection menu but the only option is UEFI Firmware Setting. After a while it clears to a simple console with this error message repeated twice:

grub-core/script/function:119:can't find comand fusetup

Supporting the idea that afer copying u-boot.bin from the working micro-sd then on the BRICKED USB installation the FUSE file-system images for boot don't mount and boot stops.

At the same time, the working micro-sd install has no directory called script or a directory called grub-core on bootfs or rootfs, though I didn't boot it to look, they are probably in one of he FUSE file-systems and they don't mount for my USB disk.

I took a look at the content of the /boot directory on both disks, it looks like the configuration now comes from symlinks. They all reference ../  IOW /boot/ Which presumably would lead to one of the FUSE file-systems because their current contents for all the symlinks are empty.

The installed kernel should have been 6.1.8 and t 6.1.7  rootfs:/usr/lib/as the previous and the initrd for both i present in /boot but rootfs:/usr/lib/(kernel, modules) are empty of anything except the dracut recovery material. I don't think I have the patience, tolerence or drive to try rebulding it from what's already present from the in the currently installed  kernel FUSE files. BRICKING this RPi 4b 8G has destroyed a mail spam filter server and I'll have to rebuild it by installing from a USB install image thumb drive. Hopefully it has an old enough u-boot/grub2/kernel to actually boot from the USB interface...

Final point, the nature of the problem can be seen on the RPi 4 (maybe earlier) system board. The yellow/green LED should flicker but stays ON all time with no OF/ON. This indicates either that the EEPROM image wasn't programmed by the boot or that there is no disk I/O. Other references say the former so it has more relevance than my "disk I/O" assumption.

After the tumbleweed update last week my pi 4 8GB also stops booting from USB. It worked again after adding

BOOT_ORDER=0xf14

with rpi-eeprom-config. (I also updated the EEPROM Bootloder there.) I'm not sure, if it helps in other cases too.

(In reply to mabuse from comment #4)
> After the tumbleweed update last week my pi 4 8GB also stops booting from
> USB. It worked again after adding
> 
> BOOT_ORDER=0xf14
> 
> with rpi-eeprom-config. (I also updated the EEPROM Bootloder there.) I'm not
> sure, if it helps in other cases too.

Forgive my ignorance:

Where do I access rpi-eeprom-config?

It's in the raspberrypi-eeprom package. (https://software.opensuse.org/package/raspberrypi-eeprom).

A blog article brought me to that funny try. https://raspberrystreet.com/learn/how-to-boot-raspberrypi-from-usb-ssd

(In reply to mabuse from comment #6)
> It's in the raspberrypi-eeprom package.
> (https://software.opensuse.org/package/raspberrypi-eeprom).
> 
> A blog article brought me to that funny try.
> https://raspberrystreet.com/learn/how-to-boot-raspberrypi-from-usb-ssd

Thanks, I'm 75% through a re-install on spare thumb drives to have a working environment that "may not" be Tumbleweed current plus I have the working up-to-date micro-sd if the install fails.

(In reply to mabuse from comment #4)
> After the tumbleweed update last week my pi 4 8GB also stops booting from
> USB. It worked again after adding
> 
> BOOT_ORDER=0xf14
> 
> with rpi-eeprom-config. (I also updated the EEPROM Bootloder there.) I'm not
> sure, if it helps in other cases too.

(In reply to mabuse from comment #4)
> After the tumbleweed update last week my pi 4 8GB also stops booting from
> USB. It worked again after adding
> 
> BOOT_ORDER=0xf14
> 
> with rpi-eeprom-config. (I also updated the EEPROM Bootloder there.) I'm not
> sure, if it helps in other cases too.

Thanks for the suggestion but rpi-eeprom-config won't work on SUSE linux versions running on a RPi because it has dependencies not provided by SUSE. The only way of getting hem I can see is something like installing RPi OS first on your Pi. Then gathering from the RPi OS installation then the full install of rpi-eeprom-config using RPi OS native tools and gathering the parts to put on the SUSE install., probably forcing the install That's going to have low reliability.

We still have the latest update of openSUSE Tumbleweed for RPi 4 bricking the RPi for me.

Although we publish rpi-eeprom-update. It was already installed in the problem system but the blog post won't help because we don't provide vcgencmd or rpi-eeprom.

Besides, it's worth pointing out I can boot from a USB drive, I just can't boot an OS. So I've probably got the EEPROM firmware loading successfuly due to copying bootfs:/bin/ from a workng system.

It's the OS booting that fails.  I can get grub2 up and running by using some combination of the u-boot.bin or the whole bootfs:/root/ directory from a working version but grub2 offers no OS boot options, UEFI manager asn option.

Judging by the content of rootfs:/boot/ we switched from using files to using symlinks to bootable components. OS boot works before before the February update because they are just files. However, there being nothing to boot after the February update probably comes about from:

* The grub files for OS's to boot was switched from physical files to symlink references to physical files
* The files referenced by the symlinks appear to be in empty directories under rootfs:/boot/
* These are probably supposed to be mounted FUSE file-system images that, if mounted, would have the physical files reference the symlinks in the grub configuration refers to
* BUT at least one, crucial symlink in rootfs:/boot/ is to a target that is not present, causing grub to treat all the bootable OS versions the set of symlinks refer to for that OS as "incomplete" (non-exitent target so empty file).
* Therefore there are no bootable installed OS versions as far as grub is concerned

I have some ideas to workaround it from my bootable micro-sd card but they will all take a lot of time and have a risk of not working anyway.

"EDITOR=vim rpi-eeprom-config -e" works fine for me with current tumbleweed, I just need to remount /boot/efi rw (I normally mount this ro after getting corruptions too often).

Having a raspbian install on a SD card is useful anyway, because it allows you to verify things there and for updating the firmware / resetting eeprom settings etc, only a SD card boot worked for me (even with raspbian on a USB stick, when booting from USB the eeprom update files were just ignored on the boot partition).

I'm right now building the last u-boot version before the update in my OBS home to check if it is only the U-Boot changes, as I am not 100% sure it is only U-boot.

My second RPi 4b 8GB board e.g. boots "fine" from USB using 2024.01. But it has garbled graphics in U-Boot (image doubled side-by-side).
Diffing the contents of /boot/efi to the non-working machine shows no obvious differences.
IF I dd the boot partition onto another USB medium, it boots the same.
If I copy over the identical files from the non-working machine, it fails.
If I just do
```
cd /boot/efi
mkdir .new
cp -a * .new
rm -r *
mv .new/* .
rmdir .new
```

It no longer boots, but fails the same as with a fresh installation.
So it seems to be dependent on the disk layout and maybe indicates problems with  the proprietary firmware (*.elf, *.dat) in the boot partiition wrt. vfat file format layout or such.

I cannot really explain this, this is why I did not mention it in the first place when reporting this bug ;-)

(In reply to Stefan Seyfried from comment #10)
> "EDITOR=vim rpi-eeprom-config -e" works fine for me with current tumbleweed,

Trying that now, thank you.

>...

Independently of what we an individually do to resolve it. This is a major problem since it can't be simply patched with a fixed u-boot, firmware, grub or more with something like zypper. Since the default behavior is that the machine will not boot from a USB installation with the board showing no firmware function then we have a situation where a default user has to have a way to have firmware/software/configuration updated on a brick. Most of us will have have to take a broken boot disk and fix it by hand on another system.

My own experience also suggests it depends on the disk boot layout made active by the February published update, i.e. the problem condition exists and prevents boot before something like zypper dup could be used.

(In reply to David Mair from comment #1)

> The zypper update in February broke u-boot RPi systems booting from USB
> disks.

Guillaume, Dominik I guess we can add USB boot to our rpi tests? https://openqa.opensuse.org/tests/3943797

(In reply to Santiago Zarate from comment #13)
> Guillaume, Dominik I guess we can add USB boot to our rpi tests?
> https://openqa.opensuse.org/tests/3943797

Only with additional hardware, that would do something like the SD multiplexer but for USB.

(In reply to Santiago Zarate from comment #2)
> Zaoliang, I think you also found/reported a similar issue right?

well, I have RPi 4 Model B which has been flashed to get booting from USB working.
I verified that latest Tumbleweed is not able to boot directly from USB.
Booting from MicroSD is not effected and it works as normal.

(In reply to Zaoliang Luo from comment #15)
> (In reply to Santiago Zarate from comment #2)
> > Zaoliang, I think you also found/reported a similar issue right?
> 
> well, I have RPi 4 Model B which has been flashed to get booting from USB
> working.
> I verified that latest Tumbleweed is not able to boot directly from USB.
> Booting from MicroSD is not effected and it works as normal.

...and a pre-installed microSD card installed with Tumbleweed in a SD to USB converter will see the Pi boot from "USB". However, no version of Tumbleweed I've installed on a pure USB disk and no other installed disk types will boot after the latest Tumbleweed when it would with previous updates.

(In reply to David Mair from comment #16)
> (In reply to Zaoliang Luo from comment #15)
> > (In reply to Santiago Zarate from comment #2)
> > > Zaoliang, I think you also found/reported a similar issue right?
> > 
> > well, I have RPi 4 Model B which has been flashed to get booting from USB
> > working.
> > I verified that latest Tumbleweed is not able to boot directly from USB.
> > Booting from MicroSD is not effected and it works as normal.
> 
> ...and a pre-installed microSD card installed with Tumbleweed in a SD to USB
> converter will see the Pi boot from "USB". However, no version of Tumbleweed
> I've installed on a pure USB disk and no other installed disk types will
> boot after the latest Tumbleweed when it would with previous updates.

... common sense suggests that's because the microSD disk in the USB adapter is still a microSD disk and the USB adapter is just a microSD controller in a USB device so the disk stays a microD disk even though connected via USB. Therefore, interesting...but my comment #16 is probably of no relevance to the bug.

(In reply to Stefan Seyfried from comment #10)
> "EDITOR=vim rpi-eeprom-config -e" works fine for me with current tumbleweed,
> I just need to remount /boot/efi rw (I normally mount this ro after getting
> corruptions too often).
> ...

RFI: I installed rootfs XFS by peronal choice, notbtrfs so the EFI file-system is not a "sub-volume" and I can't find the FUSE image it is mounted from. With the EDITOR variable I can use rpi-eeprom-cfg -e but I can't save it where it will be used for boot. If anyone know where the FUSE image will be on a XFS rootfs I'd be grateful for the input try Stefan's approach.

(In reply to David Mair from comment #17)
> ... common sense suggests that's because the microSD disk in the USB adapter
> is still a microSD disk and the USB adapter is just a microSD controller in
> a USB device so the disk stays a microD disk even though connected via USB.
> Therefore, interesting...but my comment #16 is probably of no relevance to
> the bug.

In the past I was able to use an USB SDcard adapter as an USB stick, use dd to flash the aarch64 install iso into that "USB stick" and boot into the installer via USB.

That only works on one RPI model (don't ask me which one) that can boot from USB, and there was an empty micro sd card (first 10MB overwritten with zeros) in the rpi sdcard slot, that I was installing to. Without an SD card inserted, the RPi might not boot at all.

(In reply to Dominik Heidler from comment #19)
> (In reply to David Mair from comment #17)
> > ... common sense suggests that's because the microSD disk in the USB adapter
> > is still a microSD disk and the USB adapter is just a microSD controller in
> > a USB device so the disk stays a microD disk even though connected via USB.
> > Therefore, interesting...but my comment #16 is probably of no relevance to
> > the bug.
> 
> In the past I was able to use an USB SDcard adapter as an USB stick, use dd
> to flash the aarch64 install iso into that "USB stick" and boot into the
> installer via USB.
> 
> That only works on one RPI model (don't ask me which one) that can boot from
> USB, and there was an empty micro sd card (first 10MB overwritten with
> zeros) in the rpi sdcard slot, that I was installing to. Without an SD card
> inserted, the RPi might not boot at all.

Useful information and thank you but not what I'm reporting. I can boot a USB thumb drive installer made following the instructions on opensuse.org and using an old iso do the the install to another thumb drive. THen bot it. With or without a microSD card installed in the RPi. But, if the installee thumb drive is patched up-to-date (either by network connection up during the install or brought up to date after the install via network and something like zypper dup used) with or without a micrSD card the Pi won't boot.

From the signs in comments it only needs the boot order changed in the Tumbleweed Pi firmware EFI variables but I currently can't find the FUSE file-system overlay for /boot/efi on a XFS file-system. Even if it's the correct explanation,it couldn't be fixed in Tumbleweed, o0nly from the outside before it it is booted.

You might be able to tell I want my RPis back! So, honestly, thanks for the info.

I'm working on the rpi-imager approach described in the HCL:Raspberry Pi4 Wiki page here: https://en.opensuse.org/HCL:Raspberry_Pi4#Boot_from_USB_is_not_enabled_by_default

I only have one spare sda disk, since it boots I'm making an image of it before starting.

(In reply to David Mair from comment #21)
> I'm working on the rpi-imager approach described in the HCL:Raspberry Pi4
> Wiki page here:
> https://en.opensuse.org/HCL:
> Raspberry_Pi4#Boot_from_USB_is_not_enabled_by_default
> 
> I only have one spare sda disk, since it boots I'm making an image of it
> before starting.

microSD not sda.

I don't expect it to be persistent because I'd need to modify the firmware image on the USB thumb drive for the fix to be present on the second boot but it will be a step forward and think I there's a chance I can make it persistent. The wiki suggestion is probably some part of comment #19 since it renders the sda unbootable (hence my imaging it first).

(In reply to David Mair from comment #21)
> I'm working on the rpi-imager approach described in the HCL:Raspberry Pi4
> Wiki page here:
> https://en.opensuse.org/HCL:
> Raspberry_Pi4#Boot_from_USB_is_not_enabled_by_default
> 
> I only have one spare sda disk, since it boots I'm making an image of it
> before starting.

That failed for me using the auto-mated method and I still have RPi 4bs that will not boot Tumbleweed from USB disks. I'll try the manual method...

I doubt this is the EEPROM configuration (e.g. BOOT_ORDER), my boot order is 0xf14. Then with an up-to-date Tumbleweeed on a USB disk (ssd or thumb), I get boot stopping before starting grub. Stops in u-boot input console.

Following the bug Description I can replace bootfs:uboot.bin from LEAP15.5 and get Tumbleweed to boot as far as what looks like grub2 but there are no OS versions to boot.

CORRECTING ERRORS I MADE IN  Comment #25:

(In reply to David Mair from comment #25)

Using u-boot from LEAP15.5 grub loads but it ONLY shows a menu option "UEFI Firmware Settings".

* IOW, u-boot.bin in the February update fails to load grub, a previous version does load grub (although grub doesn't work properly)


By adding debug echos to grub.cfg and sleep 40 at places of convenience gives a few clues


* Grub discovers the system is EFI
* Grub reports "There is no EFI file-system partition"
* Grub reports multiple cases of "Failed to persist EFI variables"
* Grub discovers all OS I "have" installed on the disk when walking those available, only ONE is actually installed and it's name is discovered: "openSUSUSE Tumbleweed"
* Grub reaches the png view with NO OS available to boot and the ONLY menu option is UEFI firmware settings

WE ARE IN GRUB AT THIS POINT, NOT u-boot/device firmware!

Without an EFI file-system to use it fails to show any OS to boot.

My rootfs is XFS so there will be NO EFI sub-volume but there should be a FUSE overlay that is the EFI file-system and it is NOT mounted when grub is running.


IOW the appearance is that the February update of Tumbleweed:

* Broke u-boot.bin such that it only boots to it's own console
* Broke grub (at least on non btrfs file-systems) by NOT mounting the EFI overlay  (at least from XFS file-systems). Leaving nothing for grub to boot.

It looks like the reporter first brought this up on our environment at the beginning of 2023, here:

https://lists.opensuse.org/archives/list/arm@lists.opensuse.org/thread/KUKZTXZOW3AL33A64ZCRXFDYMKSVTWBF/

His analysis there is pretty similar to my comment #26: EFI file-system doesn't get mounted (by u-boot), leaving grub DoA. The last u-boot version he reports working in that report was u-boot-rpiarm64-2022.10-2.1.aarch64 So I'm currently installing a 2022 Tumbleweeed DVD in the hope of getting an installation on a RPi that will boot! If I can I'll lock u-boot to prevent it being updated before plugging into the network and updating.

IMHO this bug was about U-Boot not working on 8GB Raspi4 (it works for me on 2GB RAM boards)... with the error message 

scanning bus xhci_pci for devices... abort_td: Expected a TRB_TRANSFER TRB first
XHCI timeout on event type 33...
unable to get device descriptor (error=-110)
XHCI timeout on event type 33...

GRUB works perfectly fine for me with the default raspberry pi image being partition1 as (V?)FAT /boot/efi and partition2 being ext4.

I could never get any installer to launch so cannot say how you got to an XFS or BTRFS image, but it seems to be orthogonal to this bug :-)

(In reply to Stefan Seyfried from comment #28)
> IMHO this bug was about U-Boot not working on 8GB Raspi4 (it works for me on
> 2GB RAM boards)... with the error message 
> 
> scanning bus xhci_pci for devices... abort_td: Expected a TRB_TRANSFER TRB
> first
> XHCI timeout on event type 33...
> unable to get device descriptor (error=-110)
> XHCI timeout on event type 33...
> 
> GRUB works perfectly fine for me with the default raspberry pi image being
> partition1 as (V?)FAT /boot/efi and partition2 being ext4.
> 
> I could never get any installer to launch so cannot say how you got to an
> XFS or BTRFS image, but it seems to be orthogonal to this bug :-)

Thanks Stefan. My current activity is to try to combine a working SLES15-SP3 RPi installed on a USB thumb drive into a a Tumbleweed one from the disk images. I'm pretty sure the difference between your observations and mine depend on the date of the Tumbleweed and, therefore, the date of the u-boot.bin (Tumbleweed images are released often enough for all the SUSE download site to have 10 or more dated images but ALL in 2024). I happen to have some old Tumbleweed aarch64 ISO images from 2021/2022.

I went through my old Tumbleweed images and although the screen organization of install on 2021 versions is bad with my screen I'm re-installing on the disk that bricked my Pi, I have two image files of the original disk and checksums.

Tumbleweed aarch64 2021-12-22 (yes, 2021) installer booted from USB or XHCI and is installing to a sdd while the Pi has no network connection (no repo versions of packages that are up-to-date (e.g. firmware). If it's a named package I'll lock the firmware before doing an update over ethernet. Then I'll re-build the servers the Pi was being used for using the images of the re-partitioned disk. Used btrfs instead of XFS for rootfs this time just in case there's some magic about a sub-volume for the EFI or EFI vars working via btrfs but not XFS that is the reason for the February update bricking my RPi 4bs. I'll post my results when it's all finished.

Just tried latest JeOS-raspberrypi image from Tumbleweed [0] on a RPi 4B (4GB of RAM) on USB and it works just fine.

'rpi-eeprom-update' shows:
**********
BOOTLOADER: up to date
   CURRENT: Wed Jan 11 17:40:52 UTC 2023 (1673458852)
    LATEST: Wed Jan 11 17:40:52 UTC 2023 (1673458852)
   RELEASE: default (/lib/firmware/raspberrypi/bootloader-2711/default)
            Use raspi-config to change the release.

  VL805_FW: Dedicated VL805 EEPROM
     VL805: up to date
   CURRENT: 000138c0
    LATEST: 000138c0
**********

@Matthias, @Ivan, any idea why only the 8GB flavors would fail on u-boot?

[0]: http://download.opensuse.org/ports/aarch64/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.aarch64-2024.01.16-Snapshot20240225.raw.xz

In my own research plus some pot in this bug I've read of the installer  behaving differently on 2GB, 4G and 8GB Rp4's. One of the solutions given was to have the Pi 4 8G plugged into  a HDMI monitor while installing.

I see different results with different aarch4 "current" (i.e. dated): images, I have yet to to try the latest current, but I get different results with different images (sha256 verified images).

20210108 will install (*)
20210208 prepared for install exactly the same way will end booting in the grub non-png console at the grub> prompt
20220115 will end at the Das u-boot console: u-boot>  It can be coerced into png grub but the only menu option is UEFI Firmware settings and haven't been able to get beyond that


* Although I can install 20210108
 - If I plug it into the network it will start a zypper dup  but will fail on modules that depend on glibc 2.3.8
 - The installed glibc is 2.3.4 and breaking the being installed package by ignoring some of it's dependencies so much is tiring and doesn't work anyway
 - A reboot leaves it it at a X login window but login reboots or locks up:
 - I haven't found a grub 2.3.8 aarch64 rom yet (only Facory 2.3.9_
 - Forcing a factory glibc 2.3.9 in gets me to zypper with about 12.5% of he original 2000 packages to install to come up from to 20210108 to current but zypper dup reports a few packages requiring glibc 2.3.4 and eventually reboots with no networking.

The point of the post is comment #31. Nearly all the attempted installs I have tried should have the same EEPROM as shown by epi-eeprom-update in comment #31.

I have split off bug#1220595 for my u-boot issue as I have no hope anyone ever soon digging through this intermingled web of possibly non-related boot failures anymore :-)

(In reply to David Mair from comment #16)

> ...and a pre-installed microSD card installed with Tumbleweed in a SD to USB
> converter will see the Pi boot from "USB". However, no version of Tumbleweed
> I've installed on a pure USB disk and no other installed disk types will
> boot after the latest Tumbleweed when it would with previous updates.

You are saying that if you put uSD card, with TW on it, in USB enclosure
RPi is happily booting from this USB?

Created attachment 873111 [details]
U-Boot errors when booting from USB

(In reply to Guillaume GARDET from comment #31)
> Just tried latest JeOS-raspberrypi image from Tumbleweed [0] on a RPi 4B
> (4GB of RAM) on USB and it works just fine.

I would not say 'just fine' :-) see attachment#873111 [details]. I will 
try to look at this when time permits.

(In reply to Ivan Ivanov from comment #36)
> (In reply to Guillaume GARDET from comment #31)
> > Just tried latest JeOS-raspberrypi image from Tumbleweed [0] on a RPi 4B
> > (4GB of RAM) on USB and it works just fine.
> 
> I would not say 'just fine' :-) see attachment#873111 [details]. I will 
> try to look at this when time permits.

Those log/error messages are expected when no uSD are inserted.

On the 8GB boards I see this

scanning bus xhci_pci for devices... abort_td: Expected a TRB_TRANSFER TRB first
XHCI timeout on event type 33...
unable to get device descriptor (error=-110)
XHCI timeout on event type 33...
Cannot allocate device context to get SLOT_ID

when trying to boot from USB and then "0 Storage devices found".
I think this is the culprit here.

(In reply to Ivan Ivanov from comment #34)
> (In reply to David Mair from comment #16)
> 
> > ...and a pre-installed microSD card installed with Tumbleweed in a SD to USB
> > converter will see the Pi boot from "USB". However, no version of Tumbleweed
> > I've installed on a pure USB disk and no other installed disk types will
> > boot after the latest Tumbleweed when it would with previous updates.
> 
> You are saying that if you put uSD card, with TW on it, in USB enclosure
> RPi is happily booting from this USB?

Yes, but that doesn't mean the USB enclosure is a USB to MicroSD converter, it can be a USB card containing a microSD controller. Also, it can't help the 2TB bricked case since I only have a 64GB sdcard.

(In reply to David Mair from comment #39)
> (In reply to Ivan Ivanov from comment #34)
> > (In reply to David Mair from comment #16)
> > 
> > > ...and a pre-installed microSD card installed with Tumbleweed in a SD to USB
> > > converter will see the Pi boot from "USB". However, no version of Tumbleweed
> > > I've installed on a pure USB disk and no other installed disk types will
> > > boot after the latest Tumbleweed when it would with previous updates.
> > 
> > You are saying that if you put uSD card, with TW on it, in USB enclosure
> > RPi is happily booting from this USB?
> 
> Yes, but that doesn't mean the USB enclosure is a USB to MicroSD converter,
> it can be a USB card containing a microSD controller. 

For Vendor bootloader and U-Boot it will look like USB device connected to
USB host controller and phy.

(In reply to Stefan Seyfried from comment #38)
> On the 8GB boards I see this
> 
> scanning bus xhci_pci for devices... abort_td: Expected a TRB_TRANSFER TRB
> first
> XHCI timeout on event type 33...
> unable to get device descriptor (error=-110)
> XHCI timeout on event type 33...
> Cannot allocate device context to get SLOT_ID
> 
> when trying to boot from USB and then "0 Storage devices found".
> I think this is the culprit here.

Perhaps. We already have U-Boot reported issues, bsc#1219033. 
I am hesitated to close this bug as duplicate of bsc#1219033.

(In reply to Ivan Ivanov from comment #40)
> (In reply to David Mair from comment #39)
> > (In reply to Ivan Ivanov from comment #34)
> > > (In reply to David Mair from comment #16)
> > > 
> > > > ...and a pre-installed microSD card installed with Tumbleweed in a SD to USB
> > > > converter will see the Pi boot from "USB". However, no version of Tumbleweed
> > > > I've installed on a pure USB disk and no other installed disk types will
> > > > boot after the latest Tumbleweed when it would with previous updates.
> > > 
> > > You are saying that if you put uSD card, with TW on it, in USB enclosure
> > > RPi is happily booting from this USB?
> > 
> > Yes, but that doesn't mean the USB enclosure is a USB to MicroSD converter,
> > it can be a USB card containing a microSD controller. 
> 
> For Vendor bootloader and U-Boot it will look like USB device connected to
> USB host controller and phy.

If there is a reason the sda in the USB adapter works it's most likely the case that the sda Tumbleweedinstall is not up-to-date (of the original report) and we are really just talking about a difference between the latest update and an older one.

For the record, I have a working RPi4 8G with the February update that I will have the re-install the server intended to run on it. Installed/upgraded as follows:

* Installed from openSUSE-Tumbleweed-DVD-aarch64-Snapshot20211222-Media.iso with NO network connection
* Locked the raspberrry* u-boot firmware packages
* Setup networking
* Installed current glibc 2.9.3 (and sub-elements). Without doing that many zypper dup packages will fail to install due to the the glibc 2.3.4 from the USB install
* zypper dup on-line (a couple of thousand packages)
* The Pi boots as expected (though the IP changes because Network Manager sets up a "Wired connection 2" that over-rides the static IP "Wired connection 1" I was using before the zypper dup).

David, your description is far too complex for me to understand.

From the initial bug description U-Boot is failing to find
bootable device. So all components in the boot chain after
it are irrelevant.

(In reply to Ivan Ivanov from comment #43)
> David, your description is far too complex for me to understand.
> 
> From the initial bug description U-Boot is failing to find
> bootable device. So all components in the boot chain after
> it are irrelevant.

...but by poking u-boot bit it's possible to reach grub but it has no OS to boot. In my first case of achieving that I only replaced the whole files content of the boots from a working sda card to the bootfs of a USB disk that had previously only booted to the u-boot console. It used to on;y reach the u-boot console, now it reaches grub.

Are there any other comment numbers I could simplify.

When copying that sda bootfs to a USB disk after complete I did edit as many copies of the rootfs UUIS that I could find in text files to the be the UUIS of the USB rootfs.

I think this fixed already?!

I can confirm that all scenarios I arose, including backing the original report based on my own experience are resolved for me by update to the current openSUSE packages at time of writing, including unlocking and updating all the boot elements. Thank you.

Closing.