Well. . . . Almost. . . .
I was doing wonderfully - got the real time clock installed, installed a custom desktop background image, (so that I know what booted!), made the usual configuration changes, etc., and was as happy as a clam.
That is, until I ran an update.
Part of the update was a kernel update that failed gloriously - leaving fragments of it’s desecrated self scattered all over, returning a bunch of errors about dependencies not being met and things not being installed. A high-speed train wreck if I ever saw one!
It turns out that Bookworm throws us a screw-ball during the boot process: For whatever reason, (they say it’s to “support the Pi-5”, but I’m wondering), they changed the boot path from /boot to /boot/firmware - and the fstab file is expected to mount the boot partition under /boot/firmware - which I didn’t - as I used a “boilerplate” fstab file where all I changed was the UUID’s of the boot and root partitions.
So! I changed the fstab file, created a /boot/firmware directory, and rebooted.
I tried fixing up the update using every dpkg trick I could find - and nothing worked.
The ultimate solution was:
-
Save aside all the modifications I made in a separate directory not directly in the root path. (My “Projects” directory/partition)
-
Re-format the two SSD Bookworm partitions as FAT32 and ext4, and re-label them.
-
Re-rsync the contents of the two original partitions off of the Bookworm bootable flash drive to the newly formatted Bookworm boot and root partitions on the SSD, preserving symlinks, hard links, attributes, ownership, (and everything else possible), while doing so.
Note that this is extremely important as preserving symlinks, hard-links, attributes, permissions, devices, special files, (etc.), is essential toward having a working system when you are finished - because a “default” rsync replaces symlinks with the target file and copies hard-linked files as individual files instead of one file and a bunch of hard-links. It also replaces permissions, ownership, attributes, and such like with generic versions such that any file is world-writable by everybody. This is by design, as a “normal” rsync backup is supposed to be like a mirror that’s readable by everyone; so you have to change that with the appropriate flags when copying. -
Change the PARTUUID in the commandline.txt and fstab to correspond with the correct PARTUUIDs on the SSD. (I was able to re-use the original fstab since I had already modified the boot partition mount to /boot/firmware.)
-
Reboot to the newly rsync’d O/S.
After the reboot, (and a few minor fixups like the background image and a subsequent reboot to make things stick), and I was ready to try the update again.
So I tried the update/full-upgrade again. . . . And it worked! The kernel upgrades slid in like a greased pig and settled down as happy as a baby with a full tummy.
(Whew!)