Looking at the backup methods on https://retropie.org.uk/docs/Updating-RetroPie/ I think the best one for me in this situation is to backup the bios, configs, and roms directories via the samba shares. However, assuming the update works perfectly, which of these directories should I copy back over to preserve my roms, save states/files, and configurations (like controller configs and core-level configs). I'm assuming just the roms and configs directory and that I should not copy bios back over to the new image, but I wanted to check and be sure.
Looks like a good use case for git on LAN? You can tag or branch your config sets rolled out for other machines than yours. Later merge all your latest and greatest changes from your machine into the friends' branches from time to time. If something breaks you can easily go back in time.
You could use something like FSArchiver to backup the individual /boot and / partitions (excluding ROMS). dd could be used for individual partitions, from a separate Linux system (/ shouldn't be active when dd is run). FSArchiver is included in the live boot System Rescue image, you can use it to restore/backup from a separate PC, without installing Linux on your PC.
/home/pi/RetroPie (ROMs, BIOS files, splash screens)
/opt/retropie/configs (configs for RetroArch, EmulationStation, also your scraped game library)
/etc/emulationstation(custom themes as well as the systems ES has access to)
The RetroPie documentation has info on how to copy files. WinSCP or Filezilla are probably the easiest programs to use.
Copy those over from the 3B to the 4, and you should be fine. Note: after you flash the image onto your RPi4, you'll need to boot up with it for RetroPie to finish installing, then you can turn it off and start copying.
@LiquidDivide I am glad that I could help. Thanks for pointing out the differences, especially the point with the non-retropie devices and that nothing has been done on the other script for 2 years. This should make your script much more interesting. Do you plan to include a save state selector as well?
Yes and no. If something works well, there's not really a need to keep changing and updating it. The other script does still work well and I had minimal issues with getting it working again, though I added a few changes from one of the other forks as well. I'm happy with it for now, but if this script gets more features, more robust, I'll happily switch.
@machine_74 this is normal behavior. The only partion that a windows computer can access directly is the boot partition. The other Linux partion, windows doesn't understand what it is and assumes it needs to be formatted. Nothing is wrong with your card, just ignore/close out the format prompts.