Behavior of Persistently Attached USB Unexpected

[XMachina]

• Restarting sys-usb unattaches persistent USB, and it cannot be reattached until target qube is restarted. On USB start, any perisistently attached USB devices should be reattached to any running target qubes.
• Attempting to start a qube with persistently attached USB fails because USB is required. I’m sure this is a UX choice, I’m just adding that as a user I expect persistent USB to be more flexible. Persistent to me would mean that it’s not required, just that the connection is always made when possible. Maybe there could be two “persistence” settings, one for the current behavior and one for the more flexible behavior? Either way, I think the current behavior has a propensity to cause problems, at least for me.
• Sometimes sys-audio doesn’t start on boot. This is likely because it attempts to start before sys-usb has finished, and this is an example of why I’m recommending the aforementioned behaviors instead of current.
  • (I have some problems with this installation that I cannot diagnose. I plan to reinstall here shortly, and this may just be one of the errata of what I assume to be an installation glitch. I believe it to not be, but full disclosure and all.)

[apparatus]

@XMachina

Sometimes sys-audio doesn’t start on boot. This is likely because it attempts to start before sys-usb has finished, and this is an example of why I’m recommending the aforementioned behaviors instead of current.

Workaround:

Audio qube

I’ve updated the script, since it was error-prone and with updated script you don’t need to specify the attached USB devices: Disable sys-audio autostart. Run these commands in dom0: sudo mkdir /etc/libvirt/hooks/ cat << 'EOF' | sudo tee /etc/libvirt/hooks/libxl >/dev/null #!/bin/bash guest_name="$1" libvirt_operation="$2" timeout=60 guest_to_start_on_usb="sys-audio" if [ "$guest_name" = "sys-usb" ] && [ "$libvirt_operation" = "started" ]; then ( exec 0</dev/null exec 1>/…