-
-
Save kimono-koans/7641ee7bc7ce91f520b324bb08d699c8 to your computer and use it in GitHub Desktop.
You're going to need to snap your root according to zsys convention (just using a date won't work), like this: | |
#!/bin/bash | |
DATE_HASH="$( date | cksum | cut -f1 -d' ' | tr -d '\n' | xargs -0 printf '%x\n' )" | |
zfs snapshot -r bpool@snap_"$DATE_HASH"_prepApt | |
zfs snapshot rpool@snap_"$DATE_HASH"_prepApt | |
zfs snapshot -r rpool/ROOT@snap_"$DATE_HASH"_prepApt | |
zfs snapshot -r rpool/USERDATA@snap_"$DATE_HASH"_prepApt | |
And you'll need to execute such a script before 'apt upgrade' from /etc/apt/apt.conf.d: | |
// Takes a snapshot of the system before package changes. | |
DPkg::Pre-Invoke {"[ -x /usr/local/sbin/snapPrepApt ] && /usr/local/sbin/snapPrepApt || true";}; | |
And when you update your kernel from /etc/kernel/preinst.d like so: | |
#!/bin/sh | |
[ -x /usr/local/sbin/snapPrepApt ] && /usr/local/sbin/snapPrepApt || true | |
This seems to work with the initramfs/GRUB hooks which remain after you purge zsys. |
@46cv8 I did what was in my post and it worked, but I ended up installing 24.04 from scratch due to another issue unrelated. I followed the guide from https://github.com/Sithuk/ubuntu-server-zfsbootmenu
Thanks for the reply I think I understand after re-reading your comment afew times. I may attempt this after I do a full image backup. I should probably also try updating my kernel just to confirm that part of the snapshot process also works properly if I attempt it. Thanks again.
@46cv8 I did what was in my post and it worked, but I ended up installing 24.04 from scratch due to another issue unrelated. I followed the guide from https://github.com/Sithuk/ubuntu-server-zfsbootmenu
Thanks for the reply I think I understand after re-reading your comment afew times. I may attempt this after I do a full image backup. I should probably also try updating my kernel just to confirm that part of the snapshot process also works properly if I attempt it. Thanks again.
Great idea. Test failure scenarios, while having a full image backup. Hopefully that's good ha.
I managed to fix my issues with zsys so I'm keeping it for the time being. I posted an answer on a stackexchange thread that helped me resolve the issue. https://askubuntu.com/questions/1388997/zsys-commit-service-fails-with-couldnt-promote-dataset-not-a-cloned-filesy/1528760#1528760
Hey @fpga-guy , Sorry the wording I used was unnecessary. I removed it, then refreshed just now only to see your comment referencing my wording :) Awkwardling coincidental. I've been using ZoL with zsys since 20.04 first released, and generally it's ok. However of the two times I tried to rollback, I always ended up with mismatched root and user data sets, and ended up i other strange situations that required recovering from a hard disk image backups. My use of the wording defunct, was not appropriate, but was mainly to reflect the multitude of users who have experienced issues and the lack of continued development beyond upgrades for continued compatibility (of which I am grateful).
Unrelated to this GIST, but perhaps you might have had a similar issue and can share some wisdom.
After upgrading to 22.04 from 20.04 this January I ended up with duplicate userdata datasets, The old ones appear to be not mounted, but they are the ones that generating snapshots, meanwhile the new ones, are not generating snapshots but they are mounted.
I've lost almost all the benefit of running zsys for backups as I'm afraid to even attempt to do a rollback as I have no idea which of my userdata datasets would get used, and it might result in my losing a bunch of data like ubuntu/zsys#218
I am not sure how to tell zsys which of the two datasets it should use for backups, it seems to be mounting a different one than the one it seems to want to take snapshots of.
Here's what it shows as