Background: I started with supervised hassio on a raspi3 to test it out. As it looks like I’m going really try using it as my home-automation solution (but not liking the latency of it on the raspi3), I got a raspi4 and a USB SSD (for faster storage I/O and to avoid the premature write-exhaustion that we see with SD cards).
Last night, I tried migrating by just doing a full backup of the raspi3 and restoring it to the raspi4, and things… didn’t go smoothly. I got a bunch of errors on the console about /dev/sda being unavailable and/or volumes being missing or read-only (I know… I really should have taken a photo of the console).
My first suspicion is that the backup/restore module doesn’t try to be so clever as to divine the boot volume, and it just tries to restore to the device the backup came from (so, in this case, it would be trying to restore to /dev/mmcblk0 instead of /dev/sda). However, I browsed through the backup tarball and didn’t see anything in the json or yaml files that mentioned a device file, so I’m not sure the restore module would know what device(s) the backups were made from (if so, it would just restore to whatever the boot volume is on the host it’s restoring to).
Eventually, I just had to power-cycle the raspi4 and it seems to have come up with all of the devices and history of the raspi3, but I’m worried that there’s some filesystem/configuration corruption somewhere that’s going to become a problem down the road (after I’ve sunk countless hours into setting this up).
So, the questions are:
- Is this (the kernel errors about the filesystem) a known issue when migrating between different pis? Or between microSD and USB-SSD? If so, are these benign warnings?
- Are there any special tips for avoiding this issue when migrating? The only thing I can think of is to use udev rules to make /dev/mmcblk0 an alias for /dev/sda.
- Is there a technical description, somewhere, of how the restore process works? The backup tarball has a lot of different pieces that get restored in different ways (the Docker containers vs the main OS which needs to alter the boot volume, for example), and I’m a little curious how the restore system manages each of those.