Forking the discussion at: Wanted: A good SPI mutex:
Including: How to jumper-select configuration/boot options for the Raspberry Pi
And: Charlie has an Identity Crisis! Vellman 3” display befuddles my GoPiGo
While working on the issue of finding a usable and useful onboard status display for my GoPiGo-3 robots, (and figuring out how to use a mutex), I appear to have run into at least one situation where it works within one GoPiGo3-O/S SD card installation, but fails when run in a similarly configured, (but different), GoPiGo3-O/S installation on a different SD card.
Different behavior between what “should be” identical installations provides a tremendous opportunity to do one of those horrifically difficult “Where’s Waldo” puzzles to discover what particular thing causes the problem to occur and why.
To facilitate that, I decided to re-dedicate a 500 gig external USB SSD, removing all the old GoPiGo3-O/S early version test installations and replace them with a series of currently available installations - some pre-configured, others brand new - to examine the display issue in specifically painful detail.
Note that when the logic within the autoboot.txt file reaches a boot_partition= statement, it immediately jumps to the requested partition, resets the boot process, and boots, (starting from scratch as if nothing had ever happened), assuming that the target boot partition is the first partition on the device.
I ran into a number of problems that centered around two major categories:
-
Getting the correct PARTUUID for each of the partitions on the drive.
-
Getting Bokworm to actually boot from an external USB device of whatever type.
According to the various Fountains Of Wisdom on the net, getting Bookworm to boot from an external USB device is a non-trivial exercise, regardless of device. This is particularly complicated when using the Pi-5, as the Pi-5’s boot process tries to do a whole host of unique and terribly unfriendly things to muddle the boot process-flow even more than it already is.
Getting the PARTUUID for a particular partition was relatively easy - once I found out the particular “magic word” to use. In this case the magic word was “blkid”.
pi@Charline-Buster:~ $ blkid /dev/sda5
/dev/sda5: LABEL_FATBOOT="BUSTER_BOOT" LABEL="BUSTER_BOOT" UUID="99F7-B859" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="5651003a-05"
pi@Charline-Buster:~ $
Once you get the PARTUUID for one partition, you’ve got them all, since they were created in ascending order.
Getting Bookworm 64-bit to actually boot from a USB device was a horse of an entirely different hue as the various Fountains Of Wisdom had a bunch of advice that was either entirely wrong, bordering on fantasy, or claimed that it just couldn’t be done, we’re all stuck with SD cards, and it just stinks being us.
Again, once you know the correct magic words, it becomes simple. In this case, the correct magic word is “Raspberry Pi Imager”, as it has the built-in feature of configuring the install to run on a particular media type - including a USB device.
For every other operating system, all I needed to do was to copy the boot partition on the SD card to the target boot partition on the SSD, and rsync the root partition to its associated target partition as well. (And then updating the PARTUUIDs within the cmdline.txt and fstab files with the correct values!)
With Bookworm it was different. There was no way that I could accomplish any kind of copy from a SD card, (proven working), to a set of partitions on a SSD, and get a working system from it.
What I ultimately ended up doing was to use the Raspberry Pi Imager on Windows to create a bootable USB flash drive containing Bookworm 64-bit, allowing it to boot on the robot via a USB port, doing the basic setup and config, and then several shutdown, power down, and reboot cycles to verify that it worked consistently.
Then I rsync’d both the bootfs and rootfs partitions on the flash device to the target partitions on the SSD - and after fixing up the PARTUUIDs, it worked like a thing of beauty!