Arch Linux User Repository

This package will verify the signature of the source package. The Mullvad code signing key is available here and instructions are here.

@yochananmarqos, sorry, I was not aware. The GitHub issue link you shared has a work around and it has worked for me.

cc @rf2020.

@rf2020: Apparently it also happens on Ubuntu, see the related upstream issue.

Folks, remember, this package is the official Debian / Ubuntu package unpacked. This is not the place to report issues with the program itself.

I can confirm that the 2024.2-1 mullvad-vpn-bin (and mullvad-vpn, too) package creates a mullvad-daemon service that fails to start, after 5 automatic retries.

systemctl status mullvad-daemon.service
× mullvad-daemon.service - Mullvad VPN daemon
     Loaded: loaded (/usr/lib/systemd/system/mullvad-daemon.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Sat 2024-05-04 11:05:51 CEST; 14s ago
   Duration: 57ms
    Process: 3647 ExecStart=/usr/bin/mullvad-daemon -v --disable-stdout-timestamps (code=exited, status=1/FAILURE)
   Main PID: 3647 (code=exited, status=1/FAILURE)
        CPU: 32ms

May 04 11:05:51 teleo systemd[1]: mullvad-daemon.service: Scheduled restart job, restart counter is at 5.
May 04 11:05:51 teleo systemd[1]: mullvad-daemon.service: Start request repeated too quickly.
May 04 11:05:51 teleo systemd[1]: mullvad-daemon.service: Failed with result 'exit-code'.
May 04 11:05:51 teleo systemd[1]: Failed to start Mullvad VPN daemon.

This was after installing and then rebooting. I can't start the service manually either. I haven't tried the early boot blocker status, but internet access is blocked until the package is uninstalled. Yes, I've tried uninstalling, rebooting and reinstalling, doesn't help. Not sure how to trace things from here.

@carport: Well, if you can figure out what happened by checking logs, let me know if there's anything that needs to be done.

If you contact Mullvad support and they say they don't support the AUR package, let them know the source is their own signed .deb using the same pre/post install scripts.

@yochananmarqos, thanks.Yes, I think removing the services it creates might have fixed the issue. But since it happened in two computers, IHMO it's highly likely it's an issue with the package (or package + something else that came from Arch repo). It's easily reproducible on my end. If I install, the issue comes back :)

@carport: No idea what might have happened, however, it seems the contents of the install file took care of it during removal and installation.

@tfl5034: See why the install file is the way it is? It just solved this person's issue without user intervention.

After I upgraded today and restarted, I was unable to use network properly. Any ping attempt outside my LAN would output: ping: sendmsg: Operation not permitted.

Had to uninstall this package to fix it. This happened in both computers running Arch with this package.

Any ideas?

@cb474 I found out a solution, not really sure what causes it but basically, if you open the mullvad gui, and let it sit in the background for a couple mins, then open it, go to settings and then go back to the map, it refreshes the map and it starts working.

The quantum-resistant setting also refreshed the map which was the cause of my confusion.

@tfl5034: There's more to it than just enabling / starting the service. I've personally worked with the Mullvad team to create the Mullvad packages. I keep it as close to upstream as possible to minimize support requests for them.

I am wondering if the install script can be changed for this package to remove the commands which enable/start the systemd mullvad services. Whenever I install a package for Arch, I expect that the services come disabled by default and that I need to explicitly enable them.