That tracks. I suspect everyone who’s gonna be hit by this has been already
anyway, and yeah it’s clearly upstream’s intent, so ¯\_(ツ)_/¯
Feel free to close I guess
Wxcafé
wxc...@wxcafe.net
> On Jul 3, 2020, at 12:06 PM, Antonio Russo wrote:
>
> Control: severity -1 wishlist
> Control: tag
Control: severity -1 wishlist
Control: tag -1 -moreinfo
On 2020-07-03 09:49, Wxcafé wrote:
> My problem is that canmount=noauto datasets should not be mounted
> automatically (I mean it’s in the name, isn’t it?) and right now they are
> being mounted automatically (through systemd)
systemd moun
I masked the systemd zfs-mount-generator, I’d imagine setting systemd:ignore=on
would work too yeah.
My problem is that canmount=noauto datasets should not be mounted automatically
(I mean it’s in the name, isn’t it?) and right now they are being mounted
automatically (through systemd)
Similar
Can you confirm that
zfs set org.openzfs.systemd:ignore=on rpool/backups
resolves your issue? Right now, you've got backup datasets that are
canmount=noauto, but presumably
should never be mounted at those mountpoints. Other options are
- change your mountpoint on your backup root, and have e
Sorry, it's been three weeks and lots of stuff happened since there, I
don't know if I edited that file or not now, but I guess probably yeah.
Here's something pulled from my server right now.
Cheers
On Tue, 2020-06-30 at 06:24 -0600, Antonio Russo wrote:
> Control: tags -1 +moreinfo
>
> Hello!
Control: tags -1 +moreinfo
Hello!
Is that attached file literally what is in /etc/zfs/zfs-list.cache ? How was
it generated, and how did it get there?
Because it's wrong---it's space separated, and must be tab separated. Use -H,
per man zfs-mount-generator, if it must be done by hand.
Best,
Ah, gotchu. Here it is attached.
On Tue, 2020-06-09 at 22:29 -0500, Richard Laager wrote:
> On 6/9/20 7:02 PM, Wxcafé wrote:
> > I don't use zfs-import-cache since it's a single pool that contains
> > the
> > root so it's in the kernel cmdline and imported at that point.
>
> I wasn't asking about
On 6/9/20 7:02 PM, Wxcafé wrote:
> I don't use zfs-import-cache since it's a single pool that contains the
> root so it's in the kernel cmdline and imported at that point.
I wasn't asking about the pool cache, but the filesystem cache file used
by zfs-mount-generator. That would show all the datas
Only one pool containing both the actual datasets and the ones with
canmount=noauto (backups) that have the same mountpoint (there's a
separate boot pool but it doesn't matter in this circumstance)
I don't use zfs-import-cache since it's a single pool that contains the
root so it's in the kernel c
On 6/7/20 3:12 PM, wxcafe wrote:
> The systemd zfs-mount-generator script
> (/lib/systemd/system-generators/zfs-mount-generator) can break system
> boot if there are multiple datasets with the same mountpoint, because it
> ignores the zfs property canmount=noauto.
It certainly does not "ignore" ca
Btw the workaround seems to be to mask zfs-mount-generator (`mkdir
/etc/systemd/system-generators/; ln -s /dev/null
/etc/systemd/system-generators/zfs-mount-generator`)
Cheers
--
Clément 'wxcafé' Hertling
Package: zfsutils-linux
Version: 0.8.4-1~bpo10+1
Severity: grave
Tags: upstream
Justification: renders package unusable
Hey
The systemd zfs-mount-generator script
(/lib/systemd/system-generators/zfs-mount-generator) can break system
boot if there are multiple datasets with the same mountpoint, be
12 matches
Mail list logo
