This repository has been archived by the owner on Jan 5, 2024. It is now read-only.
sd-export-usb vm does not start [investigation] #10
Comments
|
I noticed that when things are bad *BAd Good |
|
Note: |
More detailsIn guest-sd-export-usb.log: And this is repeated until you unplug the device. Possible STR
|
sssoleileraaa
changed the title
|
I'm unable to reproduce this. As expected per freedomofpress/securedrop-workstation#307 I frequently have to update the bus ID config.json during replug event (and once, I think, even during a VM restart event), but as long as the bus ID in config.json is the same reported by sys-usb, One clarification question:
Is it safe to do so without first running I'm also curious if you get the "usb device sys-usb:x-y not available" error message I get in case of a USB ID mismatch, or if the "list.remove(x): x not in list" error message you see takes the place of the error message I see. |
|
Thanks for taking the time to try to repro. I ran through the normal workstation setup procedure this afternoon, and again encountered this error that makes
Note: After duck-duck-go-ing some of the warnings and errors in the logs, I think we can ignore
I'm having a hard time finding anything that makes even a little sense about I get zero results across search engines for I will keep trying because not being able to run the export vm prevents me from working on fixing the bus id issue. |
|
This is not a fix, but this time it worked when I did:
Next time someone runs into this issue, please run Note: killing qui-devices per QubesOS/qubes-issues#4878 (comment) is not a fix (it was still broken over a dozen times after trying this) |
Export VM logsLast week I learned that you can view a VMs logs by going to Here are the logs with warnings and errors I already mentioned above: Export VM logsDom0 logsThe error logs for the Export VM unfortunately were not very useful in figuring out what was going wrong with the Export VM not starting. One useful tip is to look at Dom0 logs when VMs are misbehaving. To see Dom0 logs, run Dom0 logsBuried in these logs is a stacktrace: TracebackRoot causeThis stacktrace points us to this line of code causing the policy.remove(
'{} {} allow\n'.format(vm.name,
device.backend_domain.name))You can see here that policy is the list containing the lines returned by with open(policy_path, 'r+') as f:
policy = f.readlines()
policy.remove(
'{} {} allow\n'.format(vm.name,
device.backend_domain.name))On my system, I see the following Qubes policy files So the bug is that Qubes tries to remove the policy That's it. The fix is to either write the policy to be |
|
This issue can be closed once upstream fix goes out in the next qubes update. (I tested the fix and verified that it works.) |
|
Thanks for the update @creviera, keeping off the backlog for now under the assumption above, but we can revisit if needed. |
|
This is an old issue and can be closed since it has not been seen in some time. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
A couple times, when sd-export-usb starts, I've seen these popup notifications with the error message:
Domain sd-export-usb has failed to start: list.remove(x): x not in listNot sure what's causing this, but this doesn't resolve the issue:
(Note:
make sd-exportneeds run with a usb device plugged in with config.json containing the correct USB device identifier)This fixed it once:
qvm-usb lswith the usb device plugged in, see what its assigned number is (it was a new number for me)config.jsonto the correct usb device numbermake sd-exportsd-exportand no longer see a bunch of qube popup notificationsThe other time, it did not. I ended up doing a combination of everything mentioned above with rebooting and finally a
make clean && make allbefore the issue was resolved.See QubesOS/qubes-issues#4849
The text was updated successfully, but these errors were encountered: