This should no longer be the case? Everything in /etc/zfs/zfs-
list.cache/* should be dynamically handled by systemd, does it contain
entries for your pool?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I use Ubuntu 20.04 w/ ZFS for the whole system, and for me this still
broke despite using zfsutils 0.8. I only have a ZFS dataset for /var,
not for /var/lib/snapd—not sure if this contributes to the problem.
The .mount unit from #11 fixed it for me though, after I adjusted it to
cover /var
Closing remark: the new systemd generators from upstream zfsonlinux fix
this. Version 0.8.x has it (Ubuntu kernel 5.2.0 needed or compile zfs
separately).
** Changed in: snapd (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
The workaround keeps on breaking in a VM. I'm on the point I can't
assist further without guidance.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1750059
Title:
snaps appear broken when
Small update: I can't get the workaround to reproduce consistently in a
VM. While the directories are all mounted as they should and snapd is
started and running, snaps still appear "broken". I'm investigating
further.
With everything I tried so far I'm not sure this makes a lot of sense
though.
Yep, I will test that. /var can be tricky because of /var/run, so I'll
use a VM for it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1750059
Title:
snaps appear broken when /var/lib/snapd is a zfs
I expect that if /var or /var/lib are zfs datasets, and you created the
homologous .mount units, it would still work.
Is _that_ something you can test?
Either way, it would be good to have this documented over in the forum.
I'll see if I can't write something up this evening.
Thank you for all
Hi, I tried this over noon and I have some good news. The workaround
seems successful (I did a few reboots, and snaps did not break again).
However, I can imagine this to be a difficult call to make: not
everybody has zfs installed, let alone be /var/lib/snapd be a zfs
dataset (although that
ah! if that'd work, perfect.
If not, my question about the oneshot service was that, if that worked,
we could make all snap units have an After: on some agreed-upon name,
which would make this future-proof.
It might be a good idea independently; I'll discuss it with the team.
But please let me
The problem is this becomes quite breakable when snaps get updated and
all. The mount units are specific to a snap version.
I was thinking of the following workaround (to test the basic
principle). I could create a mount unit for /var/lib/snapd. That should
tick all boxes: it should be taken into
How about: create a OneShot service that just polls to see if the zfs
mount is done, and have it be RequiredBy and Before the snap mount
units.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1750059
I just pinned it down.
ZFS does not use systemd mount units. Both zfs(.target) and
snapd(.service) are wanted by multi-user.target.
Snaps are mounted before the zfs dataset is mounted by zfs-
mount.service, resulting in non-mounted snaps and therefore broken
snaps.
I have not yet found a
12 matches
Mail list logo
