Attached is my full conversation with an AI; it seems it is still recoverable, but I don’t have the expertise to know the right commands to run.
Thanks, that is very important information.
The fact that lightdm.service is failing explains the black screen: the graphical login manager isn’t starting.
However, the failures of sys-firewall, the VPNs, and the other VMs are likely consequences of the Qubes environment not having fully started up.
At this stage, we need to determine why lightdm is failing.
Can you run these two commands and copy the output?
sudo systemctl status lightdm.service --no-pager -l
then:
sudo journalctl -u lightdm.service -b --no-pager
I’d also like to check that your disk isn’t full:
df -h
Finally, one last very useful command:
sudo journalctl -b -p err --no-pager | tail -100
Why I think this is the right direction
The fact that:
you can open a console (Ctrl+Alt+F2);
you can log in to dom0;
lightdm is failing;
shows that the kernel and dom0 are working. The problem is therefore likely related to the startup of the graphical interface or a component it depends on.
One last question: did you recently install a proprietary NVIDIA driver or modify the graphics configuration, or does this system use only the default graphics driver (Intel/AMD)? That could help guide the diagnosis.
Yes, I saw AMD and NVIDIA updates for dom0 before the reboot.
That is very important information.
process 62853 code exited
The message:
Process xxxx code=exited
is unfortunately not the error itself. It is merely an indication that a process launched by lightdm has terminated.
What we need is the line (or lines) that follow, for example:
status=1/FAILURE
Failed to start X server
Failed at step…
Segmentation fault
Xorg exited with return code…
or any other error line.
Can you run this command?
sudo journalctl -u lightdm.service -b --no-pager | tail -50
It will display the last 50 lines regarding lightdm, which usually contain the cause of the problem.
Another important check
Since you can access dom0, also run:
startx
Then copy the resulting message exactly. If it is a graphics server (Xorg) issue, this command often yields a much more explicit error than systemctl.
At this stage, I think the problem is graphics-related rather than an issue with sys-usb or the VMs. The VM failures are likely a consequence of the Qubes graphical interface failing to start. Once we have the full lightdm message or the result of startx, we can target the fix.
I’m seeing “failure status=1/FAILURE”
“FAILED WITH result EXITCODE”
“restart counter 1” and then the same thing with “counter 2” etc. \[from\] sudo journalctl -u lightdm.service -b --no-pager | tail -50
Thanks. We’re making progress.
What you’re describing means that systemd is trying to restart lightdm several times and then giving up (status=1/FAILURE). However, the actual cause still isn’t appearing. It is usually found a bit further up in the logs or in the Xorg logs.
I suggest running the following commands, in this order:
sudo journalctl -b | grep -Ei “lightdm|Xorg|X11|nvidia|amdgpu|mesa|segfault”
Then:
ls /var/log/Xorg.\*
If an Xorg.0.log file exists:
grep -E “^((EE|WW))” /var/log/Xorg.0.log
Finally, I’d like to check if the window manager starts correctly:
startx
and have you copy the full message it displays.
Another important lead
Since you mentioned that the dom0 update included AMD/NVIDIA packages, I’d also like to know what hardware you are using:
lspci | grep -Ei “VGA|3D|Display”
This will tell me if your computer is using:
Intel only;
AMD;
NVIDIA;
or an Intel + NVIDIA combination.
My impression at this stage
I no longer think it’s a disk space issue (1.1 GB of logs is normal).
I think we are dealing with one of these two scenarios:
lightdm can no longer launch Xorg after the graphics update.
The latest installed kernel is causing problems with your hardware.
If the commands above don’t show anything obvious, we can also try booting the previous kernel from GRUB, which is often a good way to confirm if the kernel update is the cause.
sudo journalctl -b | grep -Ei “lightdm|Xorg|X11|nvidia|amdgpu|mesa|segfault” This command showed a huge amount of code, and I’m not in the normal dom0 environment but in the terminal version (Ctrl+Alt+F2), so I can’t easily copy and paste the code. For the rest here is what is marked:
grep -E “^((EE|WW))” /var/log/Xorg.0.log
Nothing
startx
xauth file/home/myname/.serverauth.63143 does not exist
x-wrapper-qubes: execv: exec format error
xinit giving up
xinit unable to connect to x server connection refused
x init server error
lspci | grep -Ei “VGA|3D|Display”
00:02.0 VGA compatible controller intel corporation raptor lake-s gt1 uhd graphics 770 rev 04
Thanks, this information significantly changes the diagnosis.
The most telling message is this one:
x-wrapper-qubes: execv: Exec format error
This isn’t just a simple lightdm failure. It means `x-wrapper-qubes` is trying to execute a file that isn’t in the correct executable format (corrupted file, wrong binary, or incompletely installed package).
Since you only have an Intel UHD 770 GPU, the NVIDIA packages seen during the update are likely dependencies and almost certainly not the direct cause.
Most important check
From the terminal, run:
file /usr/libexec/x-wrapper-qubes
and also:
ls -l /usr/libexec/x-wrapper-qubes
The path might differ depending on the Qubes version. If the first file doesn’t exist, try:
which x-wrapper-qubes
then:
file $(which x-wrapper-qubes)
Also check the file system
Run:
df -h
and:
mount | grep " / "
I want to make sure the root partition isn’t mounted as read-only.
Why I suspect a corrupted package
The “Exec format error” message typically appears when:
an executable is corrupted;
a script has lost its interpreter (#!);
a file for the wrong architecture was installed;
or an update was interrupted.
This isn’t a typical symptom of an Intel graphics driver issue.
One last question
When you ran the dom0 update, did it finish normally with a message like:
Complete!
or were there errors at the end before you rebooted? The output of the `file /usr/libexec/x-wrapper-qubes` command is particularly important: it should tell us whether this file is indeed an executable or if something went wrong during the update.
Yes, it finished with “complete” and the green indicator; I confirmed it and rebooted.
Thanks. The fact that the update ended with “Complete!” makes an interrupted update less likely.
However, the `x-wrapper-qubes: execv: Exec format error` is not normal. That is the point we need to focus on.
Before reinstalling anything, I’d like to verify if the file is the one expected. Run these three commands:
which x-wrapper-qubes
file $(which x-wrapper-qubes)
rpm -qf $(which x-wrapper-qubes)
Depending on the output, we will know:
if the file exists in the correct location;
if it is a valid executable or if it is corrupted;
and which package installed it.
I also have another hypothesis.
Since you are running Qubes 4.3 and the problem appeared right after a dom0 update, it is possible that this is a regression in recently released packages, rather than an issue specific to your installation.
If that is the case, the solution might be to boot using the previous kernel or to reinstall one or more dom0 packages, but I’d prefer to confirm this first.
One last important question: do you have access to the GRUB menu at startup? If so, can you check if it offers multiple kernels (for example, a current kernel and a previous one)? If an older kernel is available, we can run a simple test to see if the problem stems from the latest set of installed packages.
/usr/bin/which: no wrapper qubes in /home/monnom/.local/bin:home/monnom/bin:/usr/local/bin:usr/bin:/usr/local/sbin:usr/sbin file $(which x-wrapper-qubes) usr/bin/which: no x-wrapper-qubes in /home/monnom/.local/bin rpm -qf $(which x-wrapper-qubes) /usr/bin/whitch: no x-wrapper-qubes
OK, now we’re getting a much clearer picture.
Your output shows the following key points:
x-wrapper-qubes is not found
so the file is missing or broken
and that is precisely why you are getting:
x-wrapper-qubes: execv: Exec format error
👉 Simple conclusion: your dom0 installation has an issue with a Qubes graphics package (most likely a broken or incomplete qubes-gui / lightdm / xorg wrapper)
It is not an Intel GPU issue, nor is the disk full.
🎯 Probable diagnosis
After a dom0 update:
a package related to the Qubes GUI was installed incorrectly or partially removed
lightdm is trying to launch x-wrapper-qubes
but the binary no longer exists → crash → black screen
✅ Solution (without reinstalling all of Qubes)
We are going to repair the dom0 GUI packages.
1. Check if the package still exists
In dom0:
rpm -qa | grep qubes-gui
and:
rpm -qa | grep xorg
2. Reinstall essential GUI components
Then run:
sudo qubes-dom0-update qubes-gui-daemon qubes-gui-dom0
If it suggests dependencies, accept them.
3. Reinstall LightDM + wrapper
sudo qubes-dom0-update lightdm xorg-x11-server-Xorg
4. Restart the graphics service (test before rebooting)
sudo systemctl restart lightdm
🧠 If it still fails
We will run a fallback test:
boot without the GUI
From GRUB:
select the kernel
add systemd.unit=multi-user.target
If it works → we know for sure that the GUI is broken.
⚠️ Important note
The symptom of x-wrapper-qubes missing + exec format error is typical of:
a broken Qubes GUI package
an incomplete dom0 update
or a qubes-gui version conflict
👉 It is NOT a hardware failure. If you want to speed things up
You can also just paste the output of this command for me:
rpm -qa | grep qubes
and I’ll tell you exactly what to reinstall without touching the rest.
rpm -qa | grep qubes-gui
returns
qubes-gui-daemon-selinux-4.3.15-1.fc41.x86_64
qubes-gui-daemon-4.3.15-1.fc41.x86_64
qubes-gui-dom0-4.3.15-1.fc41.x86_64
rpm -qa | grep xorg
returns
xorg-x11-drv-wacom-serial-support-1.2.3-1.fc41.x86_64
x11-xauth-1.1.3-2.fc41.x86_64
server-xwayland-24.1.9-1.fc41.x86_64
x11-drv-libinput-1.4.0-3.fc41
xinit-1.4.3-1
drv-amdgpu-23.0.0-6.fc41
drv-ati-22.0.0-3
drv-evdev
dev-intel
drv-nouveau
drv-qxl-.01.6-6
drv-vmware
drv-wacom
x11-server-common
x11-serveur-xorg
Alright, we can be pretty sure about the cause now.
👉 Your qubes-gui packages are present and consistent
👉 So the problem isn’t a complete uninstallation
But the critical symptom remains:
x-wrapper-qubes: execv: Exec format error
and especially:
x-wrapper-qubes not found
🧠 What this really means
In Qubes OS, x-wrapper-qubes is normally part of:
👉 qubes-gui-daemon / qubes-gui-dom0
So if:
the packages are installed ✔️
but the file is missing ❌
then there are 2 likely possibilities:
🔴 1. Partially broken dom0 installation (very likely)
The file was:
deleted
or never correctly deployed during the update
or overwritten by a package transition (recent Qubes 4.3 update)
🔴 2. GUI version inconsistency (possible after an update)
The packages are at version:
4.3.15-1.fc41
👉 If a component remains on an old version or there is a mismatch, lightdm breaks immediately.
🚑 Clean solution (rebuilding dom0 GUI)
We will force a complete reinstallation of the GUI components. 1. Cleanly reinstall the Qubes GUI
sudo qubes-dom0-update --refresh qubes-gui-dom0 qubes-gui-daemon qubes-gui-daemon-selinux
2. Force a reinstallation of the Xorg wrapper
sudo qubes-dom0-update xorg-x11-server-Xorg xinit lightdm
3. Check if the file reappears
After that:
ls -l /usr/libexec/x-wrapper-qubes
or:
find /usr -name “*wrapper*qubes\*”
4. Restart the graphics service
sudo systemctl restart lightdm
🧪 If that doesn’t work
Then we move on to a very important test:
Boot without GUI
In GRUB, add:
systemd.unit=multi-user.target
👉 If it works → 100% Qubes GUI-related issue
⚠️ My current diagnosis (important)
It is NOT:
Intel GPU ❌
Full disk ❌
sys-usb ❌
VM ❌
👉 It’s a breakage in the Qubes graphics stack (dom0 GUI / X11 wrapper)
💡 In plain English
Your system is healthy, but:
👉 the Qubes GUI is broken or incomplete following the update
If you like, after running your qubes-dom0-update, paste this for me:
ls -l /usr/libexec/ | grep qubes
and I’ll tell you immediately whether we can fix it or if we need to roll back the kernel/packages.
sudo qubes-dom0-update --refresh qubes-gui-dom0 qubes-gui-daemon qubes-gui-daemon-selinux
using sys-whonix as updatevm for dom0
downloading packages
got empty response from qubesd see journal ctl in dom0
This marks a clear turning point.
👉 Key message:
“got empty response from qubesd”
This means dom0 can no longer communicate properly with qubesd, the core of Qubes OS. So, this is no longer just a graphical issue:
➡️ the Qubes backend (qubesd) is broken or non-functional
➡️ and everything else (GUI, VMs, lightdm) is failing in a cascade
🧠 What this really means
In Qubes:
qubesd = central engine (VMs, services, updates)
dom0 updates depend on it
the GUI depends on it indirectly
So if you have:
lightdm failed ❌
VMs that won’t start ❌
qubesd empty response ❌
👉 we are past a simple graphical bug
👉 and dealing with a central Qubes service that is no longer responding correctly
🔍 Critical step (diagnosis)
In dom0, run:
sudo systemctl status qubesd --no-pager -l
Then:
sudo journalctl -u qubesd -b --no-pager | tail -200
⚠️ Probable cause (very important)
Given your history (dom0 update + reboot + broken GUI), the likely scenarios are:
🔴 1. qubesd is no longer starting correctly
crash at boot
broken dependency
Python error / systemd service issue
🔴 2. sys-whonix UpdateVM is broken
You have:
“using sys-whonix as updatevm”
👉 if sys-whonix isn’t working, dom0 updates fail indirectly
🔴 3. broken Qubes service chain
qubesd → GUI → VM → updatevm
one broken link blocks everything
🚑 What we’re going to do (logical order)
Check qubesd
Check sys-whonix
Test an alternative updatevm
Repair dom0 package if necessary
🧭 Very important
👉 DO NOT reinstall Qubes
👉 DO NOT touch the disk
👉 DO NOT delete VMs
We are performing a standard Qubes system repair
🧩 What I need from you now
Just copy and paste this for me:
sudo systemctl status qubesd --no-pager -l
This is the core of the problem. After that, I’ll be able to tell you exactly whether:
it’s a service that needs restarting
it’s a broken VM (sys-whonix)
or a dom0 rollback is required (if an update broke qubes-core)
`sudo systemctl status qubesd --no-pager -l` shows “active” in green at the top, but the problem is at the bottom with “failed to qubesman”
OK, that changes how we interpret the problem.
👉 qubesd = active (OK)
So the Qubes core is running.
But you have:
failed to qubes-memman / qubes meman service failed
(and probably other failing Qubes services too)
🧠 What this really means
You’re dealing with a classic Qubes scenario:
✔️ qubesd is running (backend OK)
❌ qubes-memman is failing
❌ VM services (sys-usb, sys-firewall, VPN) are failing
❌ GUI is broken (lightdm)
👉 BUT all of this is likely NOT the root cause
👉 it’s very often a cascading failure
⚠️ Important point: qubes-memman
qubes-memman manages:
VM memory
dynamic allocation
system qube startup
If it fails:
➡️ some VMs won’t start
➡️ sys-firewall/sys-usb fail
➡️ GUI can fail indirectly
🎯 Most likely hypothesis now
Given everything you’ve described:
👉 dom0 update OK (“Complete”)
👉 reboot OK
👉 but:
lightdm broken
x-wrapper broken initially
updatevm error “empty response”
memman failed
cascading VM failures
👉 technical conclusion:
💥 Qubes services partially inconsistent after dom0 update
Not a hardware crash. Not GPU. Not disk.
🚑 Next step (very important)
We’re going to target qubes-memman directly.
Run:
sudo systemctl status qubes-memman --no-pager -l
Then:
sudo journalctl -u qubes-memman -b --no-pager | tail -200
🔧 And an essential check
We also need to verify if memory is being detected correctly:
free -h
and:
cat /proc/meminfo | head
🧭 Why I’m doing this
qubes-memman can fail if:
there’s a Python bug / Qubes service issue
there’s a version mismatch after an update
there’s a systemd problem
inconsistent memory is detected
a dependency is broken after a dom0 update
💡 Important
The fact that:
qubesd is working ✔️
GUI and VMs are broken ❌
👉 means the system is recoverable without a reinstall
We are dealing with a situation requiring a Qubes software repair, not a fatal system failure.
Just send me the output from qubes-memman, and I’ll tell you exactly which fix to apply (often it’s just a repair command or a targeted reinstall, not a full system reinstall).
OK — that is the real key clue.
qubes-memman.service not found
👉 That means one very specific thing:
the service normally exists in Qubes, but on your system, it is missing from systemd.
🧠 What this implies
In Qubes OS 4.3:
qubes-memman = a Qubes core component
it should be provided by a dom0 package (qubes-core-dom0 or equivalent)
👉 If it isn’t found, then:
🔴 most likely scenario
A Qubes core package was:
partially updated
or indirectly uninstalled
or replaced, resulting in a version inconsistency
🎯 What matters
You now have a very specific combination of issues:
✔ qubesd OK
❌ memman missing
❌ GUI broken (lightdm / x-wrapper)
❌ VMs broken (cascading failure)
❌ updateVM error
👉 This points to:
💥 Incomplete or inconsistent Qubes dom0 core following an update
🚑 Solution (without reinstalling Qubes)
We are going to perform a clean reinstall of the Qubes dom0 core
1. Check the core package
rpm -qa | grep qubes-core
2. Reinstall the Qubes core
⚠️ Important command:
sudo qubes-dom0-update qubes-core-dom0 qubes-core-dom0-linux
3. Reinstall essential services
sudo qubes-dom0-update qubes-core-admin qubes-core-admin-client
4. Reinstall memman (if available)
sudo qubes-dom0-update qubes-meminfo-writer qubes-core-dom0
🧪 Then check
systemctl list-unit-files | grep qubes
and:
systemctl status qubesd
⚠️ Crucial point (very important)
The fact that:
service does not exist
👉 is NOT normal after a “Complete update”
So, we are dealing with a case of:
🔴 incomplete or inconsistent dom0 update of Qubes core packages
🧭 Good news
👉 This type of problem can be fixed without losing any VMs
We won’t touch:
your qubes
your disks
your encryption
💡 Overall hypothesis (clear now)
The update likely:
partially updated the GUI + Qubes core
but didn’t correctly install all Qubes systemd components
→ result: missing services + a cascade of failures
👉 Next step
Start by running:
rpm -qa | grep qubes-core
and send me the result.
Then I’ll tell you exactly:
what is missing
what to reinstall in a single, clean command
without breaking your system further 👍
rpm -qa | grep qubes-core
returns qubes-core-dom0-linux-kernel-install-4.3.21-1.fc41
qubes-core-dom0-linux-4.3.21-1.fc41
qubes-core-qrexec-libs
qubes-core-qrexec-4.3.12
qubes-core-admin-addon-whonix
qubes-core-admin-addon-kicksecure
qubes-cire-admin-client-4.3.33-1
qubes-core-dom0-4.3.46
OK, the problem is clear here.
👉 Your dom0 installation is inconsistent regarding Qubes core versions
Look:
qubes-core-dom0-4.3.46 ✔ (recent)
qubes-core-qrexec-4.3.12 ❌ (very old)
qubes-core-dom0-linux-4.3.21 (old)
a mix of unsynchronized components
🧠 What this means
You are facing a classic Qubes scenario:
💥 dom0 partially updated → inconsistent core versions
Result:
Broken GUI
Broken VMs
memman missing
Qubes systemd services missing or not loading correctly
Broken updatevm
⚠️ Crucial point
Qubes OS does NOT support mixed versions of core components.
Even if:
the update reported “Complete”
the system rebooted successfully
👉 the system can still be logically broken afterwards
🚑 SOLUTION (clean and standard Qubes procedure)
We are going to resynchronize the entire Qubes dom0 core
1. Force a full synchronization of Qubes packages
sudo qubes-dom0-update --refresh qubes-core-dom0 qubes-core-dom0-linux qubes-core-qrexec qubes-core-admin-client
2. Force a GUI repair as well (important)
sudo qubes-dom0-update qubes-gui-dom0 qubes-gui-daemon
3. Check if memman returns
systemctl list-unit-files | grep mem
4. Perform a clean reboot
sudo reboot
🧭 What I expect after this
After rebooting:
ideally:
lightdm OK
sys-usb OK
memman OK (or missing but non-critical)
VMs start up
💡 Important (final diagnosis)
It is NOT:
GPU ❌
Disk ❌
Hardware ❌
👉 It is:
💥 Qubes dom0 core partially out of sync after update
⚠️ Very important
Do NOT try:
reinstalling Qubes
a reckless manual downgrade
deleting packages
👉 we fix it properly via repo synchronization
👉 next step
Run only this:
sudo qubes-dom0-update --refresh qubes-core-dom0 qubes-core-dom0-linux qubes-core-qrexec qubes-core-admin-client
and paste any errors here if they appear.
I’ll guide you through the clean reboot afterwards 👍
same error downloading packages got empty response from qubesd see journalctl in dom0