The SD card is scanned for matching PARTUUID's before USB devices, so the SD card always wins.
Fair enough. I wasn't aware of that. I'd guess that would have left the boot partition unchanged though?RonR wrote: ↑Mon Nov 25, 2019 9:33 amthagrol wrote: ↑Mon Nov 25, 2019 9:22 amIt's been going on longer than that. Since shortly after the 3B launched.
Edit: Or rather it's always been that way since raspbian has been distributed by .img file. It's mostly been a noticable issue since the 4B launch.
Prior to Buster, the act of auto-expanding on the first boot was what changed the PTUUID. Starting with Buster, this no longer occurs. I confirmed this prior to reporting the problem to the engineers who acknowledged the change in Buster.
thagrol wrote: ↑Mon Nov 25, 2019 10:05 amFair enough. I wasn't aware of that. I'd guess that would have left the boot partition unchanged though?
thagrol wrote: ↑Mon Nov 25, 2019 10:06 am
The way it works on previous Pis is that SD card boot does have priority, and is available for storage whether the Pi has booted from it or not. USB mass storage devices are enumerated and the Pi tries each one until it finds the boot files. It is not possible to specify which USB device to boot from. If the Pi cannot find a bootable mass storage device it will then attempt net boot.RossDv8 wrote: ↑Tue Nov 26, 2019 1:39 amSo far, the only real advantage (for me) I can see to USB boot, 'might' be if that freed up the microSD for writing data.
At the moment, using /boot on microSD and running off the SSD, start up from power on, to being able to open a program happens before I get back to my chair.
I hope whatever is done to make USB boot keeps the SD card priority, but allows it to be used as a storage medium when it does not contain a bootable partition. And in the absence of that, moves USB boot priority to any USB device with a bootable partition, while allowing later USB devices with a bootable partition that are plugged in to be accessed for data.
But I wonder what would happen if say 3 bootable USB devices were plugged in and someone ran REBOOT ?
I'm pretty sure that has its own built-in assumptions which can be broken. For example if someone is trying to use the UEFI as a second-stage, then chaining to GRUB (there are things which can easily be done with GRUB which I rather doubt the Pi bootloader will ever be capable of).
Really? Because in the official documentation is says, Program USB host boot mode (Raspberry Pi 3A+ and 3B only).
Which is wrong (as in, incomplete) because the Pi2Bv1.2 uses the same SoC as the Pi3A+ and Pi3B and--therefore--can have the bit set as well.HawaiianPi wrote: ↑Sun Dec 22, 2019 8:14 pmReally? Because in the official documentation is says, Program USB host boot mode (Raspberry Pi 3A+ and 3B only).
https://www.raspberrypi.org/documentati ... des/msd.md
I'm struggling to see the purpose of your post...
You might MEAN no disrespect....so...me neither, but...phillytim wrote: ↑Tue Jan 07, 2020 7:57 pmI mean, I'm just so surprised that the RP4 can't inherently boot from USB as an organic/standard available method - especially after all the finangling and maturity that we eventually experienced with the RP3B.
I mean no disrespect, but it really is 2020 and it is known how so many wish/expect to boot from USB and get away from SD cards (which a couple of mine have died in the jaw of my previous Raspberry Pis).