Here's a pair of working scenarios. At least you know these work.
The first is an rpi4 running bullseye:This is my new rpi5 running bookworm:The rpi4 is set up better than the rpi5(*) but is good enough for our purposes. It doesn't have to be GPT, we can ignore the LVM stuff and the traditional swap.
(*) I'm testing it is reliable while it's dangling off the back of a tv. It'll actually be elsewhere and headless once I'm satisfied.
I used a convoluted procedure to configure the rpi4 (making use of PARTLABEL). I have another rpi4 which prefers booting off usb over sdcard..I don't know yet if BOOT_ORDER works for rpi5. It doesn't matter as you'll see. It became useful on pi20 to use PARTLABEL because inserting a thumb drive would override the sdcard thus saving me having to keep removing the sdcard. In the process I noticed many/most online guides on how to rsync your linux are outdated, wrong and don't apply to the rpi (/boot/ being fat) so I figured out the options myself. At some point I was confident enough my rsync could backup/restore. The rpi4 (pi23) was originally an msdos disk. I rsync'd pi23 to my NAS, booted it off a thumb drive, replugged the ssd, changed it to gpt, (g)parted it and rsync'd it back. No need to mess with UUID. Long term with the rpi5 I intend to have the OS on LVM also. I did originally have this but an OS update could break it (hunt the new kernel manually and manually generate a new "initrd"). However, with bookworm that appears to be solved (I need to test that). If ever you've encountered LVM you'll be aware it's possible to 'pvmove' a physical disk while the OS is running (and perform snapshots). I have been using timeshift as a stop gap but restores are problematic (reasons).
Lots of waffle! In essence, you could attempt to install to a thumb drive(**) (yea! no adapter). Change it to use PARTLABEL (or simply the "risky" /dev/sda1 and /dev/sda2 temporarily). Others here (?@RonR?) have tools to do copies so you should be able to get that thumb drive image onto an ssd. If you're okay with rsync then you'll need these options....and these excludes....with the caveat I've not tried it for an rpi5 yet.
(**) an sdcard in one of those usb adapters will likely suffice with one more caveat - mine get real hot just writing an image. If your does I wouldn't run the OS for long off it. Heat killed a kingston thumb drive (plastic) after just a few weeks. The metal sandisk ones last longer (I was using them for heavy paging).
The first is an rpi4 running bullseye:
Code:
foo@pi23:~/usr/src/gcc $ sudo parted /dev/sda p freeModel: asmedia ASMT1153e (scsi)Disk /dev/sda: 1000GBSector size (logical/physical): 512B/4096BPartition Table: gptDisk Flags: Number Start End Size File system Name Flags 17.4kB 1049kB 1031kB Free Space 1 1049kB 269MB 268MB fat32 bootfs msftdata 2 269MB 138GB 137GB ext4 rootfs 3 138GB 1000GB 862GB lvm 1000GB 1000GB 729kB Free Spacefoo@pi23:~/usr/src/gcc $ mount | grep sda/dev/sda2 on / type ext4 (rw,noatime)/dev/sda1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)foo@pi23:~/usr/src/gcc $ cat /etc/fstab | egrep -v "^(#|$)"proc/procprocdefaults00PARTLABEL=bootfs/bootvfatdefaults0 2PARTLABEL=rootfs/ext4defaults,noatime0 1/dev/mapper/pi23_data-sw00noneswapsw0 0/dev/mapper/pi23_data-gcc/usr/local/GCCext4defaults,noatime0 3/dev/mapper/pi23_data-llvm/usr/local/LLVMext4defaults,noatime0 3/dev/mapper/pi23_data-hus/home/foo/usr/srcext4defaults,noatime0 3/dev/mapper/pi23_data-QT_6500r/usr/local/QT/6500rext4defaults,noatime0 3/dev/mapper/pi23_data-QT_6t/usr/local/QT/6text4defaults,noatime0 3/dev/mapper/pi23_data-QT/usr/local/qtext4defaults,noatime0 3tmpfs/tmptmpfsdefaults,mode=01777,size=2G0 0foo@pi23:~/usr/src/gcc $ cat /boot/cmdline.txtconsole=serial0,115200 console=tty1 root=PARTLABEL=rootfs rootfstype=ext4 fsck.repair=yes rootwaitCode:
foo@pi24:/usr/local $ sudo parted /dev/sda p freeModel: asmedia ASMT1153e (scsi)Disk /dev/sda: 1000GBSector size (logical/physical): 512B/4096BPartition Table: gptDisk Flags: Number Start End Size File system Name Flags 17.4kB 4194kB 4177kB Free Space 1 4194kB 541MB 537MB fat32 msftdata 2 541MB 69.3GB 68.7GB ext4 3 69.3GB 207GB 137GB lvm 4 207GB 344GB 137GB lvm 344GB 1000GB 656GB Free Space foo@pi24:/usr/local $ mount | grep sda/dev/sda2 on / type ext4 (rw,noatime)/dev/sda1 on /boot/firmware type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)foo@pi24:/usr/local $ cat /etc/fstab | egrep -v "^(#|$)"proc /proc proc defaults 0 0PARTUUID=3c4c6267-bbff-4a42-8379-dfd5f718b747 /boot/firmware vfat defaults 0 2PARTUUID=783d48b1-e933-404d-8f6a-7765636c269e / ext4 defaults,noatime 0 1/dev/mapper/pi24_data-sw00noneswapsw0 0tmpfs/tmptmpfsdefaults,mode=01777,size=2G0 0/dev/mapper/pi24_data-gcc/usr/local/GCCext4defaults,noatime0 3/dev/mapper/pi24_data-llvm/usr/local/LLVMext4defaults,noatime0 3/dev/mapper/pi24_data-hus/home/foo/usr/srcext4defaults,noatime0 3/dev/mapper/pi24_data-QT_6500r/usr/local/QT/6500rext4defaults,noatime0 3foo@pi24:/usr/local $ cat /boot/cmdline.txt console=serial0,115200 console=tty1 root=PARTUUID=783d48b1-e933-404d-8f6a-7765636c269e rootfstype=ext4 fsck.repair=yes rootwaitfoo@pi24:/usr/local $ find /boot -maxdepth 1 -type l -exec ls -l '{}' ';'lrwxrwxrwx 1 root root 19 Oct 10 04:39 /boot/config.txt -> firmware/config.txtlrwxrwxrwx 1 root root 17 Oct 10 04:38 /boot/overlays -> firmware/overlayslrwxrwxrwx 1 root root 20 Oct 10 04:39 /boot/cmdline.txt -> firmware/cmdline.txt(*) I'm testing it is reliable while it's dangling off the back of a tv. It'll actually be elsewhere and headless once I'm satisfied.
I used a convoluted procedure to configure the rpi4 (making use of PARTLABEL). I have another rpi4 which prefers booting off usb over sdcard..
Code:
foo@pi20:~ $ sudo rpi-eeprom-config | egrep -v "^ "BOOT_UART=0WAKE_ON_GPIO=1POWER_OFF_ON_HALT=0[all]BOOT_ORDER=0xf142Lots of waffle! In essence, you could attempt to install to a thumb drive(**) (yea! no adapter). Change it to use PARTLABEL (or simply the "risky" /dev/sda1 and /dev/sda2 temporarily). Others here (?@RonR?) have tools to do copies so you should be able to get that thumb drive image onto an ssd. If you're okay with rsync then you'll need these options..
Code:
-axAXUHP --numeric-ids"Code:
/lost+found//dev/*/proc/*/sys/*/run/*/mnt/*/media/*/tmp/*(**) an sdcard in one of those usb adapters will likely suffice with one more caveat - mine get real hot just writing an image. If your does I wouldn't run the OS for long off it. Heat killed a kingston thumb drive (plastic) after just a few weeks. The metal sandisk ones last longer (I was using them for heavy paging).
Statistics: Posted by swampdog — Tue Dec 26, 2023 9:49 pm