Hey,
Updating archlinux
Progress reporting not supported.
Refreshing package info
:: Synchronizing package databases...
error: restricting filesystem access failed because Landlock is not supported by the kernel!
error: switching to sandbox user 'alpm' failed!
error: failed to synchronize all databases (failed to retrieve some files)
Installed packages:
None
Updated packages:
None
Removed packages:
None
By root terminal and next command:
pacman -Syu --disable-sandbox
updates run smoothly, but qubes-updater can’t perform updates check with same error.
Someone have an idea how to solve this issue for arch-linux templates update process via Qubes updater?
qub411
December 16, 2025, 9:39pm
2
There is a DisableSandbox setting (something like that anyway, I’m not at the computer at the moment) in the /etc/pacman.conf file. Just set that appropriately.
ludovic
December 17, 2025, 12:26am
3
The December 12 pacman package update puts a new /etc/pacman.conf.
@WhiteShadow you should disable the filesystem sandbox, I use this setting :
[root@tpl-archlinux ~]# grep -i sandbox /etc/pacman.conf
DisableSandboxFilesystem
#DisableSandboxSyscalls
equbes
December 24, 2025, 4:07am
4
Actually, better than disabling sandbox, one should use the qubes feature for this:
# run in dom0
qvm-features archlinux boot-mode.kernelopts.landlock 'lsm=landlock'
qvm-features archlinux boot-mode.active landlock
qvm-features archlinux boot-mode.appvm-default landlock
That way, sandbox is enabled on template and derived appvms.
Related links:https://docs.kernel.org/userspace-api/landlock.html#boot-time-configuration
opened 11:19PM - 31 Jan 25 UTC
closed 11:12PM - 26 Mar 25 UTC
C: other
release notes
P: default
targets-4.3
### The problem you're addressing (if any)
(This is somewhat of a followup to a… conversation I had with Demi and Marek in the Qubes OS Matrix room.)
Currently, Qubes OS allows booting a Qube with special kernel command line parameters by using a special cli-only feature (sadly I can't remember the name of the tool used for this). If you don't do this, each qube is simply booted with some default command-line parameters, which are sufficient to allow the VM to boot and be usable. Thus far, this has been good enough, since each OS booted in Qubes generally doesn't have multiple boot modes that need to be supported.
With the introduction of the [user-sysmaint-split](https://github.com/kicksecure/user-sysmaint-split) feature into Kicksecure and Whonix, things have changed somewhat. As a form of defense-in-depth on top of the security Qubes and Kicksecure already provide, Kicksecure will soon offer a package (really a set of packages) that will allow separating user and root responsibilities much more strongly than usually done. The current implementation uses file permissions on the `sudo` and `pkexec` executables that makes them only able to be run by a special `sysmaint` user, which is locked by default and cannot be signed into normally. This makes `sudo` and `pkexec` completely unable to be run during a normal user session, greatly reducing the risk of a root compromise. To gain access to the `sysmaint` account, the user must physically reboot the machine and select "PERSISTENT mode SYSMAINT" from the list of boot options - doing so triggers a systemd unit that unlocks and automatically logs into the sysmaint account. For added security, most if not all non-essential services are suppressed while booted into sysmaint mode, and a very minimal desktop named [sysmaint-panel](https://github.com/kicksecure/sysmaint-panel) is provided to discourage the user from launching potentially dangerous applications like Firefox while in this mode. Users can run privileged commands even when not booted into sysmaint mode through an SUID-less privilege escalation framework called [privleap](https://github.com/Kicksecure/privleap).
This is all well and good, but right now this only works on physical hardware and traditional virtual machines (virt-manager, VirtualBox), because it requires the user to be able to boot into "sysmaint mode", which requires access to a GRUB console. Qubes VMs don't usually even use GRUB (since they share the dom0 kernel which is directly booted by Xen), and even when they do for some reason, you don't get access to the console during bootup unless you're using an HVM. This puts Qubes OS users in a bit of a sticky spot if they want to take advantage of the features offered by user-sysmaint-split. In UX terms, basically the end result is that `sudo` and `pkexec` become permanently unusable, and to get root access the user has to open up a root console either via `qvm-run` (which is dangerous because of X11) or via the "Open console in qube" feature of Qube Manager (which is secure and neat but also slow and somewhat difficult to use). Most of the "nice bits" of user-sysmaint-split are not accessible. In addition, Kicksecure templates will *also* be basically "locked down" by this, making it tricky to make changes or install software in the templates without resorting to one of the above solutions. Only AppVMs really need `sudo` and `pkexec` locked down, ideally a Kicksecure template should have full root access out of the box.
Last but not least, Qubes OS only supports specifying custom kernel parameters for a qube if that qube shares dom0's kernel. If you use a VM-internal kernel, you can't set the kernel parameters because those are hardcoded into a GRUB config file within the qube. This is a problem since Kicksecure has some interest in using qube-internal kernels by default, and obviously users may want to use custom kernels or the like without losing the ability to control (or even use) user-sysmaint-split.
### The solution you'd like
The solution I have in mind here isn't really one solution, but rather a set of them that fixes all of the paper cuts here:
* Templates should be able to specify auxiliary kernel parameters that Qubes OS should use when booting them and AppVMs based on them. Each template should be able to specify more than one set of kernel parameters, one per boot mode it supports.
* These boot modes should somehow be exposed to the end user. How exactly this should look I'm unclear on - an easy solution would be to provide a drop-down in Qube Manager's settings window that would allow selecting the boot mode the VM should use on next bootup. A potentially more usable solution would be to integrate the boot modes into the application menu somehow, but this could overcomplicate the user interface and might also be a massive pain to implement.
* Templates should be able to specify the default boot mode for themselves and the default boot mode for derived AppVMs separately. This way the Kicksecure template could be set up so that it would boot in sysmaint mode by default, while AppVMs would be booted in user mode by default. This would allow the Kicksecure template to be used in an intuitive fashion similar to most existing templates.
* There should be some way to boot a VM with dom0-specified kernel parameters *even if* you're booting using a qube-internal kernel. Demi, Marek, and I had a pretty long discussion about how this could be done, ultimately it seems that pvgrub is the best tool to use for this, but will need some extra features for it to work.
* In a perfect world, the user should be able to define their own boot modes. That would make this rather complex suite of features be useful for much more than just Kicksecure and Whonix.
None of this is set in stone, I'm definitely open to alternate ways of implementing things that would be easier. This is obviously a very large list of features, which I intend to contribute or at least help contribute.
### The value to a user and who that user might be
user-sysmaint-split will work really, really nicely in Qubes OS. Additionally, with the ability to specify auxiliary kernel parameters in templates, Kicksecure and Whonix could use the extensive hardening parameters they use on the desktop within Qubes as well. Users who need or want to tweak their kernels and kernel config will also have much more freedom to do so, which could benefit Qubes OS devs as well as highly advanced users.
### Completion criteria checklist
_No response_
3 Likes
Your advice also improve archlinux template performances