Thanks for the feedback! Yeah, pointing to the wrong grub configuration seems to be the most obvious issue in your case, good catch!
Hello,
I am seeing all my personal non-zsysctl zfs mountpoints appear as devices in my file-manager. Which is definitely a nuisance and a hazard. There seems to be very little information on this apart from a gnome bug of 3 years ago fstab binds appear as mounts. My zfs mounts are not in FSTAB.
I tried export and import of one of my pools - same-difference.
My zfs mounts do not appear in the generated list for the ZFS Mount Generator.
This did not happen in Ubuntu 18.04 LTS. Any likelihood this is a side-effect of the zsysctl sub-system?
Thanks,
–PG
I don’t think this is related to ZSys, as we don’t do anything and let upstream ZFS code and GNOME dealing with those. (we let ZFS mounting them as needed).
OK Thanks. Am getting some help on where to report a bug correctly.
I am enjoying learning to work with zsysctrl. Its great work - thankyou!
1 Like
Hi
Last night I tried to restore my system using zsys snapshots at boot time. On the boot menu I selected history and then restore system only.
During boot the system hangs. I had to force reboot after 1o minutes.
Does the system supposed to hang for a long time.
also I would like to upgrade to 20.10 Can I restore 20.04 at boot in the same way, if I have an issue.
I saw a bug about it recently, this is probably something for upstream GNOME or ZFS project itself.
I’m unsure to fully understand you. Something to know is that ZFS will refuse mounting a dataset if the folder isn’t empty by default (you have options to set on the pool to force that), contrary to a classic mount. But any new datasets will inherit from parent property and derive its mountpoint to the its hierachy compared to parent dataset. Hope that helps 
Interesting, it should take a little bit more time (like few seconds), certainly not a minute. Mind opening a bug with “ubuntu-bug zsys” and explain exactly to what state your tried to recover? We can iterate from there and maybe as you for more details.
Yes (given the restore works for you), there is no difference between 2 snapshots and a distribution upgrade for ZSys/ZFS.
Hi
I upgraded to 20.10, When I tried to go back to 20.04 at boot time, it did not work.
I restored (from a backup created by syncoid) 20.04 on a separate disk/zpool call spool.
Can I modify grub, so that I can choose at boot time which OS to boot to rpool or spool
I run update-grub it did not detect spool.
Also I looked at /etc/grub.d/10_linux_zfs it should find my new pool.
Any Ideas how to fix. Thanks
Hello. I recently upgraded from Ubuntu 18.10 to 20.4. I had a ZFS pool of four drives set up under Bionic, which contains a bunch of photos and other data I don’t want to lose. In 20.4, “zpool status” shows the pool is still there, but if I look in the folder (“bucket”) for the pool, there’s nothing there. If I boot back to Bionic (I had also recently moved Bionic from HDD to an SSD, and still had the old copy on the HDD, fortunately) via Grub, I can see the contents of the pool as before, and all the files I’ve checked seem to be fine. But back in Focal, the folder is empty. I can create folders there in Focal, but I can’t see the old ones. Back in Bionic, the old ones are still there. I know just enough about this to be dangerous; I thought it might be a rights issue, so I did a chmod 777 on the “bucket” folder, but no change. I’m hoping someone can tell me what to try. I’m also wondering if there’s an issue with the UUID (I believe that’s the number associated with the user accounts?) not matching from Bionic to Focal, although my root account was migrated automatically during the upgrade, and I can still log in with the same password, so… Help?
There seems to be no action on either of the following:
- https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1675705
- https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1530231
Therefore, it would seem to me that udisks2 should hide “zfs_member” filesystem types by default. /usr/lib/udev/rules.d/80-udisks2.rules has only one entry for “zfs_member” and it’s for GPT partition type 48.
ENV{ID_PART_ENTRY_SCHEME}=="gpt", \
ENV{ID_FS_TYPE}=="zfs_member", ENV{ID_PART_ENTRY_TYPE}=="6a898cc3-1dd2-11b2-99a6-080020736631", \
ENV{UDISKS_IGNORE}="1"
Ubuntu makes use of GPT partition types 46 & 47 for the work being done with ZFS and zsysd. Can those be added to the default /usr/lib/udev/rules.d/80-udisks2.rules? I have done the following on my system via /etc/udev/rules.d/80-udisks2.rules using these contents:
ENV{ID_PART_ENTRY_SCHEME}=="gpt", \
ENV{ID_FS_TYPE}=="zfs_member", ENV{ID_PART_ENTRY_TYPE}=="6a85cf4d-1dd2-11b2-99a6-080020736631", \
ENV{UDISKS_IGNORE}="1"
ENV{ID_PART_ENTRY_SCHEME}=="gpt", \
ENV{ID_FS_TYPE}=="zfs_member", ENV{ID_PART_ENTRY_TYPE}=="6a82cb45-1dd2-11b2-99a6-080020736631", \
ENV{UDISKS_IGNORE}="1"
It is of my opinion that the above two entries for GPT partition types 46 & 47 should be added to the system in either /usr/lib/udev/rules.d/80-udisks2.rules or when ZFS is installed in /etc/udev/rules.d/80-udisks2.rules at a minimum. A case could also be made for more GPT partition types (51, 52, etc.) to be added to the ignore list should they get implemented by zsysd in the future. Alternatively, the ZFS and zsysd projects could switch all used partition types to just GPT partition type 48 so udisks2 continues to hide them.
Thank you for your consideration.
1 Like
Hi,
I cannot revert to previous state because the History for Ubuntu 20.04 LTS entry has disappeared from the grub menu.
I haven’t done anything active with grub other than apply system updates as they arrive. In-fact, i have done a clean reinstall of the system about 2 weeks ago.
- does anyone know how to fix this? Renders the whole zsysctl thing useless. There doesn’t seem to be any alternate way of reverting to saved states.
- I assume this is a bug - where do you suggest I report this?
The gnome group is too exclusive - cant get a login - or even say ‘this affects me’
I did a fresh re-installation a few weeks ago. So I checked my boot-loader location.
That is now correct, but History for Ubuntu 20.04 LTS entry is still absent from the grub menu.
Any suggestions of how to check my system configuration?
Where does the History for Ubuntu 20.04 LTS grub menu get created?
what would be a good backup strategy for /USERDATA/?
The bog post on ZSys general presentation only mentions that integration with backup tools may be forthcoming but I did not see any follow-up to this comment.
My setup consists of bpool and rpool (following Ubuntu 20.04 on root. However, USERDATA lives on a separate, larger zpool.
I run a simple script that takes snapshots and zfs send | receives to two pools (one of them on the same physical machine, separate disks).
My issue is that Zsys picks up the backup of the USERDATA dataset and tries to manage these. Which interferes with my backup strategy (zfs recv fails since the snapshots are modified by zsys).
I already have detached the USERDATA datasets on the backup pool by setting com.ubuntu.zsys:bootfs-datasets to none and calling zsysctl state remove. This is so far to no avail since the backup datasets show up in zsysctl show after the next autosnapshot and my subsequent backup cron-job fails.
Any hints on how to keep Zsys from picking up my backup datasets would be appreciated. I would like to keep Zsys management of the USERDATA datsets on the original pool but currently, this does not seem to play ball with a straightforward backup solution to a secondary pool on the same machine.
Thanks for all the hard work making ZFS and zsys available on ubuntu. I have not found an answer on one question after reading through all the documentation:
How can I rollback a snapshot with zsys from the commandline (terminal) instead of using grub. I would like to use this setup on a ubuntu server environment.
1 Like
Is there a safe way to do this at all?
I suppose the system would need to be in single-user mode not to be logging into /var/log?
So no, ‘recovery mode’ is still using the dataset.
Then I guess booting a live cd and importing rpool for changes might be the way.