Archlinux update fail

equbes · December 24, 2025, 4:07am

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

github.com/QubesOS/qubes-issues

Improve support for booting qubes with custom kernel command line parameters (useful for Kicksecure and Whonix user-sysmaint-split)

opened 11:19PM - 31 Jan 25 UTC

closed 11:12PM - 26 Mar 25 UTC

ArrayBolt3

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_