qubes-input-proxy-sender has Missing Dependency in Fedora-23-Minimal Template

[entr0py]

Qubes OS version (e.g., R3.1):

R3.1

Affected TemplateVMs (e.g., fedora-23, if applicable):

fedora-23-minimal

---

Expected behavior:

sys-usb should ask for permission to access usb input devices on reboot

Actual behavior:

no confirmation dialog

Steps to reproduce the behavior:

1. configure dom0 policy
2. install qubes-input-proxy-sender
3. attach usb keyboard/mouse
4. reboot sys-usb

General notes:

installing packages: usbutils, libusb does not resolve.
setup is working with standard Fedora-23 template.

---

Related issues:

[marmarek]

Do you see any error messages related to input-proxy in journalctl?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Do you see any error messages related to input-proxy in journalctl?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[entr0py]

On startup:

xen_pciback: vpci: 0000:00:1d.0: assign to virtual slot 0
pciback 0000:00:1d.0: registering for 46
pciback 0000:00:1d.0: enabling device (0000 -> 0002)
xen: registering gsi 20 triggering 0 polarity 1
Already setup the GSI :20

Nothing on shutdown.
Missing drivers?

[entr0py]

On startup:

xen_pciback: vpci: 0000:00:1d.0: assign to virtual slot 0
pciback 0000:00:1d.0: registering for 46
pciback 0000:00:1d.0: enabling device (0000 -> 0002)
xen: registering gsi 20 triggering 0 polarity 1
Already setup the GSI :20

Nothing on shutdown.
Missing drivers?

[marmarek]

What about journalctl in sys-usb?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

What about journalctl in sys-usb?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[entr0py]

qubes-input-sender-mouse@event1 starts with res=success
and then stops with Failed with result 'exit-code'.

If I'm not mistaken, it's accompanied by qrexec-client-vm[##]: Request refused

[entr0py]

qubes-input-sender-mouse@event1 starts with res=success
and then stops with Failed with result 'exit-code'.

If I'm not mistaken, it's accompanied by qrexec-client-vm[##]: Request refused

[marmarek]

When have you plugged your mouse in? Have you tried to unplug + plug it again?

[marmarek]

When have you plugged your mouse in? Have you tried to unplug + plug it again?

[entr0py]

PC is a notebook with all usb ports attached to one controller. (XHCI disabled in BIOS)

1. unplug all usb devices
2. start sys-usb
3. plug in mouse
4. kernel recognizes mouse
5. qubes input proxy sender started.
6. service starts then stops
7. unplug mouse
8. qubes input proxy sender stopped.
9. plug in mouse
10. repeats
    Every time service is stopped - qrexec-client-vm: request refused.
    Works fine in sys-usb based on standard Fedora-23 template.

[entr0py]

PC is a notebook with all usb ports attached to one controller. (XHCI disabled in BIOS)

1. unplug all usb devices
2. start sys-usb
3. plug in mouse
4. kernel recognizes mouse
5. qubes input proxy sender started.
6. service starts then stops
7. unplug mouse
8. qubes input proxy sender stopped.
9. plug in mouse
10. repeats
    Every time service is stopped - qrexec-client-vm: request refused.
    Works fine in sys-usb based on standard Fedora-23 template.

[marmarek]

Works fine in sys-usb based on standard Fedora-23 template.

Is it the same VM, or you have different USB qube (named differently than sys-usb)?
Setup configures access to qubes.InputMouse service to sys-usb VM, so if yours is named differently, you need to update /etc/qubes-rpc/policy/qubes.InputMouse.

[marmarek]

Works fine in sys-usb based on standard Fedora-23 template.

Is it the same VM, or you have different USB qube (named differently than sys-usb)?
Setup configures access to qubes.InputMouse service to sys-usb VM, so if yours is named differently, you need to update /etc/qubes-rpc/policy/qubes.InputMouse.

[entr0py]

omg. Marek, you shouldn't have to babysit like this. So sorry to waste your time.
<- the moron that configured qubes-rpc policy and forgot.
Thanks! Template works fine. Please close issue.

[entr0py]

omg. Marek, you shouldn't have to babysit like this. So sorry to waste your time.
<- the moron that configured qubes-rpc policy and forgot.
Thanks! Template works fine. Please close issue.