Restoring a backup snapshot in ZBM Recovery

[neilpanchal]

Hey, just a follow up on this issue (it's locked): #635

I was not able to get the the system booting from a restored snapshot of a different system.

Here is what I did:

1. ZBM + Debian system (Call this system1)
2. system1 snapshot taken of zroot/ROOT/system1@snapshot1 and sent to a remote (call it remote_server) backup facility using zfs send zroot/ROOT/system1@snapshot1 | ssh remote_server zfs receive -vFu zbk/vms/system1.
3. Nuke system1 and delete everything simulating a catastrophic loss of HDD.
4. Create a new system2, follow debian instructions and set a brand new system up with ZBM.
5. Using ZBM recovery shell, run dhclient to get an IP address and connect to the network.
6. Execute snapshot restore process by running ssh remote_server zfs send zbk/vms/system1@snapshot1 | zfs receive -vFu zroot/ROOT/system2. Snapshot was restored successfully.
7. Try to boot into zroot/ROOT/system2.

But I get stuck at SMBus base address uninitialized - upgr, the rest of the message is not visible. I looked this error up and found this link: https://askubuntu.com/questions/298290/smbus-bios-error-while-booting-ubuntu-in-virtualbox

Any ideas on how I can get the system back? It seems that I need to run update-initramfs -u -k all on the target system2. Not sure how though.

[ahesford]

The other discussion was locked because it was hijacked by another user with irrelevant debates about the use of recovery images.

You can chroot into the filesystem that you've received by highlighting it in the main menu and pressing CTRL+J.

[neilpanchal]

Thanks @ahesford , I was able to successfully fix the issue. It turned out to be a disk UUID issue. When I restored system1 in vm, the disk UUID had changed in /dev/disk/by-uuid.

New disk shows as:

# ls /dev/disk/by-uuid
2024-02-10-11-07-25-00	8830895757002886050  BA42-2080

I just updated the 92FA-129A (previous UUID) to BA42-2080 in /etc/fstab and it booted up just fine.

I required chroot into the restored system.

[no-usernames-left]

I just updated the 92FA-129A (previous UUID) to BA42-2080 in /etc/fstab and it booted up just fine.

That's interesting, because my Arch root-on-ZFS setup does not have anything in /etc/fstab except the ESP (which is also flagged noauto).

Would such a setup avoid the restore issue you experienced?