error while installing proton-pass and proton-mail

[Plarpoon]

hello, I am having this error when trying to install proton-pass and proton-mail, I have a feeling it might have to do with the fact that these two snaps are using strict confinement.

Is my reasoning correct? In that case, is it a general compatibility issue or is a specific one for just these two snaps?

Here is the gist of it

[io12]

I think this line is the relevant part

cannot preserve mount namespace of process 9264 as proton-pass.mnt: Invalid argument

And this part of the code throws that error, where it tries to make a new mount namespace

https://github.com/canonical/snapd/blob/475d7aeeed30bc2be6bd2efec705b723a1331ce5/cmd/snap-confine/ns-support.c#L791-L793

    if (mount(src, dst, NULL, MS_BIND, NULL) < 0) {
        die("cannot preserve mount namespace of process %d as %s", (int)parent, dst);
    }

I haven't looked into how snap uses mount namespaces, so I'm not really sure what the issue is. Sometimes more detailed mount errors show up in the kernel logs, so you could try seeing if there is anything relevant in dmesg at the time the error happens.

[Plarpoon]

I didn't have anything bad on dmesg but I also rebooted my system and temporarily removed all snaps and nix-snapd.

But I did notice quite the few errors on my system, including the crashing of the entire snap systemd-unit which were caused by a dependency of proton-mail, being a mesa snap.

Ironically the only way to re-enable the snap unit was to fully remove the mesa snap, but that made proton-mail not boot.

Here is the gist of journalctl from a few hours ago when it was still installed, please do ignore the bluetooth and flake.lock updater errors, those are not real errors.

[io12]

Thanks, I think I figured out the issue. The main reason snap is hard to package for NixOS is it expects /etc/systemd/system to be writable and tries to write unit files for snaps there, but it's a symlink into /nix/store, which is immutable, so that doesn't work. The workaround that's currently used is to patch snapd to write to /var/lib/snapd/nix-systemd-system instead, and put symlinks to the unit files in /run/systemd/system, which is writable but cleared on each boot. On reboots, when snapd starts, a wrapper runs all the units in /var/lib/snapd/nix-systemd-system. What I didn't realize at the time is some snaps, like mesa in this case, install unit files that it only enables in certain situations and don't work otherwise, so the wrapper fails before actually starting snapd. I think you can fix this by deleting /var/lib/snapd/nix-systemd-system/snap.mesa-2404.component-monitor.service, and other files if that's not the only one causing issues. I'm not really sure what the best way to solve this in general is though. Maybe a /var/lib/snapd/nix-systemd-system/enabled directory for tracking which units get enabled?

[Plarpoon]

Thanks for the comment, I am going to preface by saying that unfortunately I won't be at home where my desktop Linux machine sits until the 8th of January so I will have to postpone all attempts until then.

Having said that your logic makes sense to me, indeed deleting the MESA files did allow the systems-unit of nix-snapd to start, but at the cost of the protonmail snap package not to start.

I do agree that a spot on the system to keep everything tracked is probably the best solution. But I will need to test that in the future.

Thanks again for your invaluable feedback!