Qubes Upgrade to 4.2 - In Place Upgrade

which policy file applies here?

/etc/qubes-rpc/policy:

qubes.InputMouse.rpmsave

this is the policy file for the older format

/etc/qubes/policy.d/

it’s not clear which policy file dictates the mouse control in the new format

do you know which file it is?

Both old format policy files and new format policy files are used right now:

[user@dom0 ~]$ cat /etc/qubes/policy.d/35-compat.policy 
#
# NOTE:
#
# The following line enables compatibility mode. It reads files in old directory
# (/etc/qubes-rpc/policy). It also generates deny rules that were previously
# implicit after each file, but they are added only after policies for specific
# arguments, that is, for files with '+' in the name. For generic files, without
# '+', no such rules are generated and the control "falls through", which is
# a departure from previous semantics. It is done that way not to shadow the
# default rules.
#
# The "!compat-4.0" directive is transitional only and will be unavailable in
# next major release (R5.0). This file will be removed in that release also.
#

!compat-4.0

Since compatibility policy file has higher priority (35), the policies from old policy format files will have precedence over the policies from new policy format files with priority lower than 35 (>35).
You can try to remove the rpmsave files and redo the qubes-dist-upgrade stage 6, maybe the rpmsave files are causing the script to fail.

I’m still not clear on which policy file has precedence.

Policies in old policy files (in /etc/qubes-rpc/policy) will have precedence over all policies in new policy files (in /etc/qubes/policy.d/) that have filenames that start with number higher than 35.

qubes.InputMouse.rpmsave

sys-usb dom0 allow
$anyvm $anyvm deny

when I modified this file and rebooted the VM and powercycled the mouse, it

had no effect. Do modifications to this file require a reboot to take effect?

The qubes.InputMouse and qubes.InputMouse.rpmsave are two different policies, the Qubes OS don’t use the policy with the name qubes.InputMouse.rpmsave.
Once again:

all of the files in this directory have the .rpmsave suffix

Remove them all or move them to some other directory to save them just in case.

So I need to create a new file “qubes.InputMouse” and copy the contents of

the .rpmsave file to this new file?

If your system was upgraded correctly then the mouse policy should already be present in the new policy file /etc/qubes/policy.d/50-config-input.policy and there is no need to create the old policy file.
Just remove the rpmsave files and rerun sudo qubes-dist-upgrade -p to see if it’ll be finished successfully.

should I make a backup of these file first? Or just rm -rf and remove them all.

You can move them somewhere in your user home directory just in case.

what about commenting out the 35-compat.policy file?

Commenting out !compat-4.0 directive doesn’t seem to have an effect.

The qrexec-legacy-convert script is as follows:

#!/usr/bin/python3

from qrexec.tools.qrexec_legacy_convert
import main
import sys
if name==‘__main
__’:
sys.exit(main())

the other scripts that run are

qrexec_policy_graph.py

parser.py

I think your issue is that you didn’t complete the Qubes OS upgrade process and you have an error when you try to complete the stage 6:

I don’t know how to fix this error.

what does “transitional” really mean here, the start and end point of the “transition”

is not clearly defined.

It means that this compatibility mode support will stay in Qubes OS until version 5.0 so users will have time to switch their policies from old format to the new format.

It just doesn’t really make clear which policy is in use right now in real time. Unless

there is some command or something in Qubes Template Manager.

Is there any kind of “known good” example that can be used as a reference?

What would the ideal configuration file, or set of config files, look like?