This is a response to this mailing list thread: [qubes-users] Error upgrading Debian 11 to 12 (usrmerge)
Is this an unresolved problem? I’m running into this too. Similar problems found online, but this exact version seem to be qubes specific?
I solved this by switching to VM’s own kernel, thus dom0 wouldn’t create /lib/modules mount point, installing usrmerge, then switching back to default (dom0-provided) kernel.
1 Like
I tried Qubes-Settings for the VM
Advanced->Kernel - set to (provided by qube)
Is that what you did?
Then I tried PVH,HVM and PV. But wasn’t able to launch a terminal in any of them.
I’m having the same problem upgrading some Whonix templates from 16 to Whonix 17.
I tried apt purging usrmerge but it is just reinstalled, and then I read that you can’t go backwards.
I just spent 24 hours updating to Qubes 4.2-rc4 so going backwards at this point is really not gonna be fun. But the systems with this usrmerge error are unuseable. I can’t even launch a terminal once shutting down.
I tried mv’ing everything from /lib/modules to /usr/lib/modules but some things won’t delete from /lib/modules (current kernel, initramfs, vmlinuz) probably for good reason.
I tried symlinking /lib/modules to point to the files in /usr/lib/modules. Strangely it creates /lib/modules/modules instead of overwriting /lib/modules.
Tomorrow I may have to start rebuilding these qubes from scratch to get them to work. Will not be fun. So any other suggestions are very welcome.
Lots of posts on other forums about this, but only solutions involve deleting duplicates/making symlinks. Which does not seem possible here as Qubes seems to be using /lib/modules for system critical files.
By the way, I never reposted the error here. It is:
/lib/modules is a mount point.
Probably this system is using User Mode Linux.
To continue the conversion please:
- replace '/lib/modules' with /usr/lib/modules' in /etc/fstab
- reboot
- try again
These are not in /etc/fstab though.
Trying @fhd29073 solution again on Whonix workstations (tried Debian before). Here’s some more info on the failures when trying to boot using kernel provided by qube.
using PVH (default):
virt_mode PVH require kernel to be set
using HVM:
Cannot connect to qrexec agent for 60 seconds, see /var/log/xen/console/guest-info1.log for details
(that file is empty)
using PV, errors from /var/log/libvirt/libxl/libxl-driver.log:
023-10-17 13:32:09.074+0000: xc: panic: xg_dom_core.c:205: failed to open file 'None/vmlinuz': No such file or directory: Internal error
2023-10-17 13:32:09.075+0000: libxl: libxl_dom.c:646:libxl__build_pv: xc_dom_kernel_file failed: No such file or directory
2023-10-17 13:32:09.075+0000: libxl: libxl_create.c:1716:domcreate_rebuild_done: Domain 77:cannot (re-)build domain: -3
The idea that doing this will prevent Qubes from putting stuff in /lib/modules and allow usrmerge to work makes sense, but I cannot figure out how to do it 
To switch to VM’s own kernel, one need to follow Managing qube kernels | Qubes OS with some additions, namely, for Debian:
sudo apt install linux-image-amd64 linux-headers-amd64 grub2 qubes-kernel-vm-support
sudo grub-install /dev/xvda
If grub-install fails with a message about blocklists, add --force option
sudo grub-install --force /dev/xvda
In qube settings: set HVM mode, kernel none (provided by qube), check the “run in debug mode”. Start the qube, then if the usual terminal fails to start, use the debug console to log in and issue sudo apt install usrmerge.
Then revert all the settings and continue to upgrade.