But this is still baffling. Why would this occur only for certain accounts? The other two are working fine now. No inability to form a secure connection. Do they really host different accounts on different servers?

In any case, a mistake like that on major provider is really concerning.

Nor did I, when Debian 13.3.0 and Devuan 6.1.1 behaved the same way.
But I couldn't get Debian 11.2.0 to work, it came up with the squashfs image, persistence was ignored running kvm.
This might, though, be an effect of the five remasterings done. So I started out with the squashfs from the ISO and a new persistence store.
Still didn't use the persistence volume, so here I have a  clear contrast between new 11.2.0 and 13.3.0 installs. Might still be unrelated to systemd, but scope creep always makes me suspicious when unexplainable errors occur.
For the purpose of running older versions in a vm, the obvious remedy is to squash the overlay file system into a new image.  Then it is enough to keep that, a few GBs disk space is saved, too.

BTW, here is the booting stanza for the Devuan instance I am running now:

title Devuan 6.1.1 64 bits Xfce live /dev/nvme0n1p6  v0  persistence/dev/nvme0n1p7  
      root(hd0,0) 
      kernel  (hd0,1)/boot/dev611/vmlinuz boot=live config quiet splash initrd=(hd0,1)/boot/dev611/initrd.img  bootfrom=/dev/nvme0n1p6  live-media-path=dev611/live0 persistence persistence-path=dev611nvme7/pers0 keyboard-layouts=no noautologin 
      initrd (hd0,1)/boot/dev611/initrd.img

Re bootloaders: Legacy grub was installed on the SATA disk by an OS version long gone. No need for any updating, I just add new directories with kernel&initrd images, and edit menu.lst. As long as I can run a version with legacy grub installed, I can repeat the procedure with new disks, and I do - it works with types of USB media and nvme-disks it had no idea about when first developed.
That's how a GRand Unified Bootloader should behave, in my head. So I wish for a GRUB-reinc (reincarnated legacy GRUB) with knowledge of GPT and loadable modules for UEFI navigations etc when absolutely necessary, kernel-style :-)

Purpose: Modify 'mullvad-vpn_2025.14_amd64.deb' to include sysv-init scripts.
Output: 'mullvad-vpn_2025.14~1sysv_amd64.deb'

'DEBIAN/postinst':
  mullvad service is NOT enabled at boot time (intentionally)
  systemctl lines are commented out: --> no need for systemctl on devuan; then on systemd also NOT enabled at boot time
  alternatively: systemctl lines can stay --> updated "docker-systemctl-replacement" needed
Enable service: see post above "forte  #9"

The following is a script to create the modified debian package. Adjust to your flavour.

$ cat modify_mullvad_deb.sh

#!/bin/bash
### recreate mullvad-deb-package for devuan
# https://unix.stackexchange.com/questions/138188/easily-unpack-deb-edit-postinst-and-repack-deb
# e.g.: (do as root!)
mkdir tmp
dpkg-deb -R mullvad-vpn_2025.14_amd64.deb tmp
## edit / patch  DEBIAN/postinst
# comment-out lines starting with 'systemctl' ?
sed -i 's/^systemctl/# systemctl/g' tmp/DEBIAN/postinst
# patch for systemctl (docker-systemctl-replacement)
sed -i -e 's/"\/usr\/lib\/systemd\/system\/mullvad-daemon.service"/mullvad-daemon.service/' \
       -e 's/"\/usr\/lib\/systemd\/system\/mullvad-early-boot-blocking.service"/mullvad-early-boot-blocking.service/' \
    tmp/DEBIAN/postinst
# create sysv-init scripts
mkdir -p tmp/etc/init.d
sysd2v.sh tmp/usr/lib/systemd/system/mullvad-early-boot-blocking.service > tmp/etc/init.d/mullvad-early-boot-blocking
sysd2v.sh tmp/usr/lib/systemd/system/mullvad-daemon.service > tmp/etc/init.d/mullvad-daemon
sed -i 's/"MULLVAD_RESOURCE_DIR=/MULLVAD_RESOURCE_DIR="/' tmp/etc/init.d/mullvad-daemon     # correct entry
chmod +x tmp/etc/init.d/mullvad-daemon tmp/etc/init.d/mullvad-early-boot-blocking
chmod g-w tmp/etc/init.d/mullvad-daemon tmp/etc/init.d/mullvad-early-boot-blocking
# re-pack
dpkg-deb -b tmp mullvad-vpn_2025.14~1sysv_amd64.deb

## installation
# cp mullvad-vpn_2025.14~1sysv_amd64.deb /tmp     # user "_apt" can not access files in /root/*
# apt install /tmp/mullvad-vpn_2025.14~1sysv_amd64.deb

#-----------------------------------------------------------------------------#
# Supplemental:
#
## sysd2v.sh   (to create sysv-init scripts)
# https://web.archive.org/web/20210412005920/http://www.trek.eu.org/devel/sysd2v/
# wget https://cgit.git.savannah.nongnu.org/cgit/sysvinit.git/tree/contrib/sysd2v.sh
# chmod +x sysd2v.sh; cp sysd2v.sh /usr/local/bin
#
# systemctl    (updated script - if installed package throws errors)
# git clone https://github.com/gdraheim/docker-systemctl-replacement
# cp docker-systemctl-replacemen/files/docker/systemctl3.py /usr/local/bin/systemctl

$ firejail -seccomp falkon

with all related (profiles) to firejail installed?
Does it fail?

1. An ext2 partition for booting
2. An ext4 partition for compressed live images
3. An ext4 partition for persistent storage
All these partitions can hold several OS versions, and one version (I have used Debian 11.2.0 as the basis for the last 4 years) may go through several iterations (typically 3-6) of compressed live images during a lifetime of 2-5 years.

This can be done on a 32+ GB USB 3.X stick with 30+ MB/s writing times. Using a slower stick is hardly worthwhile. A SATA disk or an m2-disk in an external case is simpler in daily use, but hardly necessary. 64GB is a practical mimimum, 256 GB kind of sweet spot. If you think you need more, you haven't really tried to be space efficient. If you are sure you need less, you have probably not lived through the full OS version upgrade blues.

Using live versions with persistent storage are, traditionally, called Poor Man's Installs (PMI). There is a tradition going back (at least) to Klaus Knopper and KNOPPIX. He made a 32-bit version-hybrid Debian derivative, therefore very hard to upgrade, but very, very useful for a couple of years.

In the Debian context, a Poor Man's Install is based on 4 files:

1. vmlinuz - the kernel. Which does not have to be changed during the lifetime of an OS version, but of course, YMMV.
2. initrd.gz - often Busybox-based init code. Hackable, I once made a pure 64-bits Knoppix version starting with a modified initrd.
3. filesystem.squashfs - the compressed live image. Which you may recreate as needed. I just expanded the original Debian 3.2 GB Lxqt image to 8.8 GB, including ca 250 R-cran packages plus GIMP, VLC, WXMaxima etc. If you think you have to grow the image way above 10 GB, consider Docker for some of the large components.
4. persistence. A loop-mounted overlay file system, typically 2-20 GB. No, you don't have to restrict yourself to small programs when you work based on a live system. Oracle XE, Postgresql and even Axiom (math theorem proving etc) work just fine.

In the booting partition, booting files are organized in directories by OS releases. For example. I have  deb910 (LXDE) , deb1120 (LXDE), deb1330Qt (LXQt) to mention a few. Upgrading kernel/initrd is of course possible here, and may be best practice. But I have never experienced an urgent need for that, and I think it is safer to start a new OS version install than upgrading the kernel. This partition is mostly read-only.

The live image partition is read-only in everyday use. But it may be updated several times.

The persistence partition holds 1-2 persistence files for each OS version, union mounted with the compressed image: The one in current use and eventually the previous. When it starts to get full, it is time for 'remastering', simply copying the whole union file system into a directory, squashfs-compressing it into a new live image and setting up a new persistence file.

Surprisingly, old legacy grub is just fine for booting in this context, and it even works on a USB stick set up with three (or more) Linux partitions. Here is the booting stanza for Lxqt Debian 13.3.0 with one 'remastering'. This is on an internal disk, using a stick would be similar.

title Debian 13.30 64 bits lxqt live sda3 v1 persistence sda6 
      root(hd0,0) 
      kernel  (hd0,1)/boot/deb1330Qt/vmlinuz boot=live config quiet splash initrd=(hd0,1)/boot/deb1330Qt/initrd.img  bootfrom=/dev/sda3 live-media-path=deb1330/live1 persistence persistence-path=deb1330Qts/pers1  keyboard-layouts=no
      initrd (hd0,1)/boot/deb1330Qt/initrd.img

Menu - Default Applications - Others

https://www.asciiart.eu/mythology/dragons

This seems like a case of user-error.

there would be any other day a reminder "updates available" and then however, the update would seldomly go through;

what is more, however, is that the discover and apt-get would pull different updates, sometimes not easily explainable.

the other register that seem function is the "settings" or also "plasma addons", or "about" , besides, getting also for most of Application registers (education, games, graphics, internet etc.)

https://ibb.co/JR937QXz
https://ibb.co/bjbjDWPy

sudo date -s "2026-12-25 14:30:00"
This will change your date and time to 25th December 2026 2:30 pm.  Adjust accordingly to your needs.

Of course it is a good idea to make sure your bios time (F2 key or similar at boot) and date are correct first.