Troubleshooting qvm-sync-appmenus on unsupported distro

I’m currently in the process of updating my repository for the CRUX (Linux) distro to work as a template VM in Qubes 4.1. I have previously succeeded in getting most functionality working in 4.0, and am now just modernizing it to the upcoming release.

I get the following error from dom0:

$ /usr/bin/qvm-sync-appmenus crux
Traceback (most recent call last):
  File "/usr/bin/qvm-sync-appmenus", line 11, in <module>
    load_entry_point('qubesdesktop==4.1.7', 'console_scripts', 'qvm-sync-appmenus')()
  File "/usr/lib/python3.8/site-packages/qubesappmenus/receive.py", line 407, in main
    new_appmenus = retrieve_appmenus_templates(vm, use_stdin=use_stdin)
  File "/usr/lib/python3.8/site-packages/qubesappmenus/receive.py", line 378, in retrieve_appmenus_templates
    new_appmenus = get_appmenus(vm if not use_stdin else None)
  File "/usr/lib/python3.8/site-packages/qubesappmenus/receive.py", line 159, in get_appmenus
    raise qubesadmin.exc.QubesException(
qubesadmin.exc.QubesException: Error getting application list

/var/log/qubes/qrexec.crux.log:

2021-08-19 08:22:18.963 qrexec-daemon[171001]: qrexec-daemon.c:1201:main: qrexec-agent has disconnected
2021-08-19 08:22:24.167 qrexec-daemon[171001]: qrexec-daemon.c:1101:handle_agent_restart: qrexec-agent has reconnected
2021-08-19 10:05:02.142 qrexec-daemon[171001]: qrexec-daemon.c:1201:main: qrexec-agent has disconnected

And the resultant error showing up in the console of the domU:

2021-08-19 09:13:15.238 qrexec-agent[441]: qrexec-agent-data.c:244:handle_new_process_common: executed: user:QUBESRPC qubes.GetAppmenus dom0 (pid444)
2021-08-19 09:13:15:252 qrexec-agent[441]: qrexec-agent-data.c:272:handle_new_process_common: pid 444 exited with 1

File exists in domU:

# md5sum /etc/qubes-rpc/qubes.GetAppmenus
30b51117b78612072794844aeddc3a59 /etc/qubes-rpc/qubes.GetAppmenus

Here are the current versions I’m pulling from github, all of which build successfully in the DomU:

qubes-linux-utils: 4.1.15
qubes-core-agent-linux: 4.1.26
qubes-core-qrexec: 4.1.15
qubes-core-qubesdb: 4.1.11
qubes-core-vchan-xen: 4.1.7
qubes-vmm-xen: 4.14.2-1
xen: 4.14.2-1

Here is my dom0 version list:

xen_version            : 4.14.1
Linux 5.10.42-1.fc32.qubes.x86_64
  
Installed Packages:  

kernel-qubes-vm.x86_64                            	1000:5.4.67-1.qubes 
kernel-qubes-vm.x86_64                            	1000:5.10.42-1.fc32.qubes 
python3-qubesadmin.noarch                         	4.1.12-1.fc32 
python3-qubesdb.x86_64                            	4.1.10-1.fc32 
python3-qubesimgconverter.x86_64                  	4.1.15-1.fc32 
qubes-anaconda-addon.noarch                       	4.1.5-1.fc32 
...
qubes-core-admin-addon-whonix.noarch              	4.0.2-1.fc32 
qubes-core-admin-client.noarch                    	4.1.12-1.fc32 
qubes-core-dom0.noarch                            	4.1.20-1.fc32 
qubes-core-dom0-linux.x86_64                      	4.1.11-1.fc32 
qubes-core-dom0-linux-kernel-install.x86_64       	4.1.11-1.fc32 
qubes-core-qrexec.x86_64                          	4.1.12-1.fc32 
qubes-core-qrexec-dom0.x86_64                     	4.1.12-1.fc32 
qubes-core-qrexec-libs.x86_64                     	4.1.12-1.fc32 
qubes-db.x86_64                                   	4.1.10-1.fc32 
qubes-db-dom0.x86_64                              	4.1.10-1.fc32 
qubes-db-libs.x86_64                              	4.1.10-1.fc32 
...
qubes-dom0-meta-packages.noarch                   	4.1.12-1.fc32 
qubes-img-converter-dom0.x86_64                   	1.2.10-1.fc32 
qubes-input-proxy.x86_64                          	1.0.23-1.fc32 
qubes-input-proxy-receiver.x86_64                 	1.0.23-1.fc32 
qubes-libvchan-xen.x86_64                         	4.1.7-1.fc32 
qubes-manager.noarch                              	4.1.15-1.fc32 
qubes-menus.noarch                                	4.1.7-1.fc32 
...
qubes-release.noarch                              	4.1-0.27 
qubes-release-notes.noarch                        	4.1-0.27 
qubes-repo-templates.noarch                       	4.1.2-1.fc32 
....
qubes-utils.x86_64                                	4.1.15-1.fc32 
qubes-utils-libs.x86_64                           	4.1.15-1.fc32 

Am I inappropriately coupling together incompatible versions? Where might I look to dig into this further?

Thanks in advance!

1 Like

Try to execute /etc/qubes-rpc/qubes.GetAppmenus in the domU and see what happens.

Hi, thanks for chiming in! Here’s the DomU output:

# /etc/qubes-rpc/qubes.GetAppmenus 
/usr/share//applications/firefox.desktop:Name=Firefox
/usr/share//applications/firefox.desktop:Name[en_US]=Firefox
/usr/share//applications/firefox.desktop:GenericName=Web Browser
/usr/share//applications/firefox.desktop:GenericName[en_US]=Web Browser
/usr/share//applications/firefox.desktop:Comment=Free web browser from Mozilla
/usr/share//applications/firefox.desktop:Exec=qubes-desktop-run /usr/share//applications/firefox.desktop
/usr/share//applications/firefox.desktop:Terminal=false
/usr/share//applications/firefox.desktop:Type=Application
/usr/share//applications/firefox.desktop:Icon=firefox
/usr/share//applications/firefox.desktop:Categories=Network;





/usr/share//applications/xterm.desktop:Name=XTerm
/usr/share//applications/xterm.desktop:#GenericName=Terminal
/usr/share//applications/xterm.desktop:Comment=standard terminal emulator for the X window system
/usr/share//applications/xterm.desktop:Exec=qubes-desktop-run /usr/share//applications/xterm.desktop
/usr/share//applications/xterm.desktop:Terminal=false
/usr/share//applications/xterm.desktop:Type=Application
/usr/share//applications/xterm.desktop:Encoding=UTF-8
/usr/share//applications/xterm.desktop:Icon=xterm-color_48x48
/usr/share//applications/xterm.desktop:Categories=System;TerminalEmulator;
/usr/share//applications/xterm.desktop:Keywords=shell;prompt;command;commandline;cmd;

# 

The empty lines shouldn’t be there, but they also shouldn’t hurt. The exception you’ve got earlier means the script exited with non-zero exit code - is it the case with manual call too? I don’t see any error message there…

That’s something that struck me, as well.

I’m invoking qrexec-agent like this on domU and running it in the foreground:

# /usr/lib/qubes/qrexec-agent

Incidentally, whether the qrexec-agent is up or down, dom0 reports the same exact error traceback: the only difference is whether or not I get the handle_new_process_common output.

With regard to versions, I picked the latest available 4.1.15 and built that–my dom0 runs qubes-core-qrexec-* 4.1.12-1; is downgrading to match versions useful here? EDIT: downgraded to 4.1.12 for qrexec and issue persists.

qvm-sync-appmenus works without issue on standard Fedora 33 (supported) appvms

Does qvm-run -p from dom0 work? Maybe try from dom0:

qvm-run -p --service <vmname> qubes.GetAppmenus
echo $?

This should show whether the issue is with the service itself, or qrexec as a whole.

1 Like

Alright, I got that figured out. It looks like the component that was interfering was pam.d. One look into /var/log/auth showed a slew of failures to load postlogin and system-auth, both of which were not present from a standard CRUX install.

Carrying over these files and removing references to pam_pwquality.so fixed the problem immediately!

Now, I only have the gui-agent part left till it’s functional, but I hope to figure that out shortly. Thanks again for your assistance.

1 Like