Cannot Reassign USB to dom0

[stone212]

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

R3.2 64-bit Linux

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

dom0

---

Expected behavior:

Reboot should return control of USB device 00:1a.0 to dom0

OR

These instructions should do it:

https://www.qubes-os.org/doc/assigning-devices/
(See "Bringing PCI device back to dom0")

Actual behavior:

Despite reboot and attempting those instructions, USB devices completely halt on starting up the VM to which the USB controller was assigned during an earlier session. Using another USB controller, the devices perform as expected.

Also, the instructions are ambiguous.

• They do not specify whether to execute those instructions on dom0 or on the attached VM. I chose dom0 since the directory (/sys/bus/pci/drivers/pciback) does not exist on the VM

• The instructions do not say you must execute as root. They don't even say sudo. I had to create a root password and log in as su to execute the instructions.

• Are these supposed to be single quotes or back-ticks?
  MODALIAS='cat /sys/bus/pci/devices/0000:<BDF>/modalias'

They are back-ticks on the website, but of course I can't paste them into the editor that way here.

• Substituting with 00:1a.0, here's how it went for me:

# echo 0000:00:1a.0 > /sys/bus/pci/drivers/pciback/unbind
bash: echo: write error: No such device

# MODALIAS=`cat /sys/bus/pci/devices/0000:<BDF>/modalias`

# MOD=`modprobe -R $MODALIAS | head -n 1`

# echo 00:1a.0 > /sys/bus/pci/drivers/$MOD/unbind
bash: /sys/bus/pci/drivers/dhci_pci/unbind: No such file or directory

After reboot, "sudo lspci | grep 'USB'" on the VM shows:
00:00.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
And on dom0, I see:

00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)

Steps to reproduce the behavior:

1 - Attach USB controller to a VM using the instructions at https://www.qubes-os.org/doc/assigning-devices/

2a - Try rebooting to detach.

2b - Try the manual approach:

https://www.qubes-os.org/doc/assigning-devices/
(See "Bringing PCI device back to dom0")

General notes:

---

Related issues:

[andrewdavidwong]

It sounds like your USB controllers might be blacklisted in dom0. Try these instructions (but omit step 2 if you want to keep the USB qube, and ensure it doesn't autostart):

https://www.qubes-os.org/doc/usb/#removing-a-usb-qube

[andrewdavidwong]

It sounds like your USB controllers might be blacklisted in dom0. Try these instructions (but omit step 2 if you want to keep the USB qube, and ensure it doesn't autostart):

https://www.qubes-os.org/doc/usb/#removing-a-usb-qube

[stone212]

I don't know what you mean by a "USB qube" here. I assigned the USB controller to a regular VM that I use often. Then I tried to assign the USB controller back to dom0 and failed.

[stone212]

I don't know what you mean by a "USB qube" here. I assigned the USB controller to a regular VM that I use often. Then I tried to assign the USB controller back to dom0 and failed.

[andrewdavidwong]

The term "USB qube" is explained on the page I linked above. Please give it a read.

[andrewdavidwong]

The term "USB qube" is explained on the page I linked above. Please give it a read.

[stone212]

Yes, I read that but I still don't understand what "USB Qube" has to do with what I'm doing. At no point did I create a "USB Qube" so I don't understand why you think that the instructions relating to fixing the problem on a "USB Qube" relate to me. I'm not trying to be rude. I'm honestly trying to see how that page connects to my bug report.

[stone212]

Yes, I read that but I still don't understand what "USB Qube" has to do with what I'm doing. At no point did I create a "USB Qube" so I don't understand why you think that the instructions relating to fixing the problem on a "USB Qube" relate to me. I'm not trying to be rude. I'm honestly trying to see how that page connects to my bug report.

[andrewdavidwong]

"USB qube" refers to any VM that has possession of a USB controller.

Your first step was:

1 - Attach USB controller to a VM using the instructions at https://www.qubes-os.org/doc/assigning-devices/

By performing this step, you now have a USB qube.

[andrewdavidwong]

"USB qube" refers to any VM that has possession of a USB controller.

Your first step was:

1 - Attach USB controller to a VM using the instructions at https://www.qubes-os.org/doc/assigning-devices/

By performing this step, you now have a USB qube.

[stone212]

Ohhh... okay I will go through this with that in mind.

[stone212]

Ohhh... okay I will go through this with that in mind.

[stone212]

I am looking at those instructions. There is a problem here:

3. Open the file /etc/default/grub in dom0.

When I open the dom0 terminal, I find that there is no file called /etc/default/grub. I can create one if that will help. But I wonder if the fact that this doesn't exist is the cause of the problem in the first place?

I am using GRUB2 but I am controlling it from another OS that I dual-boot with Qubes. (In fact this is another problem I had - Qubes' GRUB2 didn't work, but I was able to do it manually in the other OS so I didn't even think of it as a bug/issue until now.)

[stone212]

I am looking at those instructions. There is a problem here:

3. Open the file /etc/default/grub in dom0.

When I open the dom0 terminal, I find that there is no file called /etc/default/grub. I can create one if that will help. But I wonder if the fact that this doesn't exist is the cause of the problem in the first place?

I am using GRUB2 but I am controlling it from another OS that I dual-boot with Qubes. (In fact this is another problem I had - Qubes' GRUB2 didn't work, but I was able to do it manually in the other OS so I didn't even think of it as a bug/issue until now.)

[stone212]

@andrewdavidwong Can you please verify that the instructions you point me to are up to date?

As mentioned above, step (3) in the instructions you send me are not applicable as there is no "/etc/default/grub" file in dom0.

Also, you may see from another issue that grub2 is ineffective when run from my Qubes partition. Details here:
#3022

[stone212]

@andrewdavidwong Can you please verify that the instructions you point me to are up to date?

As mentioned above, step (3) in the instructions you send me are not applicable as there is no "/etc/default/grub" file in dom0.

Also, you may see from another issue that grub2 is ineffective when run from my Qubes partition. Details here:
#3022

[andrewdavidwong]

@stone212: Sounds like you may be using (U)EFI instead of GRUB, or something like that. (Sorry, I know very little about this.)

[andrewdavidwong]

@stone212: Sounds like you may be using (U)EFI instead of GRUB, or something like that. (Sorry, I know very little about this.)

[stone212]

@andrewdavidwong I am definitely using GRUB2. You can see that in my other post as well as this one.

If you know very little about this then why are you responding to this Issue report? I don't mean to be rude but it seems that the best person to reply to an issue is someone who does know very much about that issue.

[stone212]

@andrewdavidwong I am definitely using GRUB2. You can see that in my other post as well as this one.

If you know very little about this then why are you responding to this Issue report? I don't mean to be rude but it seems that the best person to reply to an issue is someone who does know very much about that issue.

[andrewdavidwong]

@stone212:

If you know very little about this then why are you responding to this Issue report? I don't mean to be rude but it seems that the best person to reply to an issue is someone who does know very much about that issue.

1. It's part of my job to manage GitHub issues. (Of course, this doesn't mean I know about everything that is mentioned in every GitHub issue.)
2. I know enough about the other things we've been discussing (USB qubes) to respond competently.
3. You specifically asked me by name. Rather than ignoring you, I thought it would be more helpful to try to answer your question. But I didn't want you to interpret my answer the wrong way (i.e., as a certainty rather than a hypothesis), so I made it clear that I lack knowledge on this topic.

[andrewdavidwong]

@stone212:

If you know very little about this then why are you responding to this Issue report? I don't mean to be rude but it seems that the best person to reply to an issue is someone who does know very much about that issue.

1. It's part of my job to manage GitHub issues. (Of course, this doesn't mean I know about everything that is mentioned in every GitHub issue.)
2. I know enough about the other things we've been discussing (USB qubes) to respond competently.
3. You specifically asked me by name. Rather than ignoring you, I thought it would be more helpful to try to answer your question. But I didn't want you to interpret my answer the wrong way (i.e., as a certainty rather than a hypothesis), so I made it clear that I lack knowledge on this topic.

[stone212]

@andrewdavidwong Fair enough. It was my mistake to ask for you by name. Since you replied early on I assumed you were the guy to reply to. Of course you can't know everything about everything, no one can. I look forward to someone else on the team reading this who has the relevant skills. In the meantime I have removed Qubes because I couldn't wait any longer without access to my USB ports (mouse, keyboard, dongles, etc.)

[stone212]

@andrewdavidwong Fair enough. It was my mistake to ask for you by name. Since you replied early on I assumed you were the guy to reply to. Of course you can't know everything about everything, no one can. I look forward to someone else on the team reading this who has the relevant skills. In the meantime I have removed Qubes because I couldn't wait any longer without access to my USB ports (mouse, keyboard, dongles, etc.)