So I copied an old template and tried a few times to reproduce the fix, and the secret sauce seems to be setting selinux to permissive, then letting the at-boot relabelling run for at least like 15 min, then killing the machine because the at-boot relabelling never finishes, then rebooting, and then running the manual relabel. Just doing the manual relabel without the at-boot relabel as I mentioned in my post had mixed results, and I have no idea why.
1 Like
How do you perform at-boot relabelling?
I set SELinux to permissive mode, then restarted the system via the root terminal after re-enabling SELinux, as the template fails to start in normal mode even in permissive mode. I then ran the following command:
restorecon -Rv /
However, this command completed almost instantly.
Am I doing something wrong, or is the solution simply not working for me?
Iām sorry, I used --unset and it did work, but I mixed things up as it was not re-enabling selinux. I was too confident and modified the instructions to put selinux 1 instead of my --unset, but it does not work.
First, increase the qrexec_timeout value. Then, set SELinux to permissive and remove the .qubes-relabeled file from the root mount point (/.qubes-relabeled). After rebooting, the qubes-relabel-root service will start, and after a moment, the template will shut down automatically. See if that resolves your issue.
If not, try reinstalling all SELinux packages in the template:
sudo dnf reinstall $(rpm -qa --qf "%{NAME}\n" | grep selinux | tr '\n' ' ')
1 Like
Neither approach worked.
I disabled SELinux, increased qrexec_timeout to 3600, set SELinux to permissive mode, removed the .qubes-relabeled file, shut down the template, re-enabled SELinux and restarted the template.
However, I still encountered a timeout error.
Then, I disabled SELinux again, started the template in the root terminal, and reinstalled the SELinux packages using the command you provided. The reinstallation completed successfully. I shut down the template, re-enabled SELinux, and restarted it, but the timeout error persisted.
Having the same issue as @marcos-morar, tried everything but still canāt get template to boot with selinux enabled.
EDIT: Tried again with just the at-boot relabelling after reinstalling selinux packages and it worked.
Steps
dom0$: qvm-features $vm_name selinux 0
dom0$: qvm-start $vm_name
# finish pending update and reinstall selinux packages
vm$: sudo dnf update
vm$: sudo dnf reinstall $(rpm -qa --qf "%{NAME}\n" | grep selinux | tr '\n' ' ')
# change `/etc/selinux/config` to `SELINUX=permissive`
vm$: sudo rm /.qubes-relabeled
vm$: poweroff
dom0$: qvm-prefs $vm_name qrexec_timeout 3600
dom0$: qvm-features $vm_name selinux 1
dom0$: qvm-start $vm_name
# allow a couple mins for relabel to complete, machine will shut off automatically
dom0$: qvm-start $vm_name
vm$: # change `/etc/selinux/config` to `SELINUX=enforcing`
vm$: poweroff
dom0$: qvm-start $vm_name
vm$: sestatus #confirm it's enforcing
# optional, change timeout back to 60s
dom0$: qvm-prefs $vm_name qrexec_timeout 60
2 Likes
Thatās strange. Why this at-boot relabelling is not working for me? I mentioned all the steps here. If there is nothing wrong with those steps then ā¦
Check my latest edit and see if it works for you
Hi!
Iām encountering an issue when trying to start the Fedora-41 Template in Qubes OS. The error message is:
"Cannot connect to qrexec agent for 60 seconds"
I suspect this might be related to the template not shutting down properly after a recent update.
Iāve tried increasing the qrexec timeout period to 300 seconds, but the issue persists.
Can anyone tell me how to resolve this?
Log file is attached.
startup.log (78.9 KB)
Wrong! Ignore this comment
Problem is (probably - I thinkā¦) here:
OK .[0m] Started .[0;1;39msystemd-oomd.service.[0m - Userspace Out-Of-Memory (OOM)
Either something is using excessive memory, or your template max memory is just a little bit too smallā¦
Whatever, any appearance of the OOM system spells BAD (except for its startup message, but I donāt think that is what this line is indicatingā¦)
[2025-07-13 12:56:05] [ 2.796871] SELinux: Context system_u:object_r:qubes_qubesdb_daemon_exec_t:s0 is not valid (left unmapped).
Same issue as here:
1 Like
This is the correct diagnosis, I think!
The linked thread recommends to disable SElinux for the update.
An alternative is to roll back the template, if you can live without the updates:
https://www.qubes-os.org/doc/volume-backup-revert/
Try booting the template VM in debug mode using qvm-start --debug --console Fedora-41, and check for systemd service failures (especially qubes-qrexec-agent.service). If systemd is stuck, you can try booting into an older kernel or entering rescue mode via GRUB. Alternatively, clone the template and reinstall the qubes-core-agent packages using a chroot or recovery shell. If nothing works, reinstalling the template via sudo qubes-dom0-update qubes-template-fedora-41 is the most reliable fix.
1 Like
The steps for at-boot relabeling didnāt work for me.
I reverted the volume to a previous snapshot, and now the template is working fine. However, when I run dnf update, it says āNothing to do.ā Since I reverted to an older snapshot, shouldnāt there be new updates available, including those that were interrupted and āborkedā the template?
This has hung for me (~20min) at:
Despite best efforts, it seems the solutions here are performing inconsistently.
Iāve filed a Github issue.
Note there seems to be something similar observed by Marmek Marmarek in a different issue, but that is on 4.3 - Iām on 4.2.4.
Iām way outside my technical depth, so thatās the best I can contribute.
1 Like
[x@dom0 Desktop]$ qvm-start fedora-41-xfce-EXTRAS
Cannot connect to qrexec agent for 3600 seconds, see /var/log/xen/console/guest-fedora-41-xfce-EXTRAS.log for details
log.log (583.6 KB)
should now be fixed: vmupdate: disable SELinux during update Ā· QubesOS/qubes-core-admin-linux@1fd93fc Ā· GitHub
1 Like
Thanks for this!
Iāll postpone the fedora-41 update till after the patched qubes-core-admin-linux package makes it to my dom0.
Note: I donāt use the template at all, itās there just in case I need a fedora setup to test something (I donāt want to be waiting 30+ minutes to download and update the template every time). If you use the template, it may be advisable to update anyway - I canāt be the judge of how much other peopleās attack surface will increase by postponing the update!
I would like to chime in and confirm while chromium was being installed it ran an rpm scriplet that caused an error in the updater which eventually exited. It happened to all my standalones and templates with chromium as an extra package. I hope this gets fixed soon so others are spared the drama of trying to fix it.
1 Like