templates update fail over sys-usb (but work using sys-net, on Qubes 4.x rc4)
Dave C
```
user@f26-devel ~]$ sudo dnf install tmux
Error: Failed to synchronize cache for repo 'updates'
```
While in an appvm, the same command works fine.
The failure above occurs when I have sys-firewall using *sys-usb* (that is,
tethering over usb).
When I switch sys-firewall to use *sys-net*, then `dnf` works!
I've checked my settings in "Qubes Global Settings" and they show "UpdateVM" is sys-firewall. But I have to wonder is it actually using sys-net? Or does it only work when sys-firewall uses sys-net?
Yuraeitha
You made your sys-firewall handle USB devices? I'm not sure as I'm no expert, but this might be unsafe? As far as I know, USB devices should be put in either sys-net (for example if you have USB-modems or USB-tethering to get internet), or in a random VM that has no internet access, like sys-usb. Whichever suits the needs more. If you need internet on the USB controller, then I believe the appropriate place is to put this USB controller in sys-net. But as said, I'm no expert, you may want to verify the above.
However regarding the issue you encounter, I've seen this too on Qubes 4 a few times a good while back too, but not recently. When I first saw it, my sys-firewall (and all other VM's) was not even started. Only sys-net was running, yet it was to my surprise possible to download updates that I could install, despite saying it was going through sys-firewall, but it wasn't even running.
It disturbed me a bit, but at the time it was still early RC-2 or so, so I did not think much of it since it would probably get fixed before final release. But now you're seeing it too, which makes me wonder what is going on if the bug is still present, I thought it was fixed by now.
Are you fully updated?
If you are using current-testing, are you also using current-testing in template updates too so that there are no mismatch between dom0/template updates?
Noticeable differences from my experience of the bug, is that I only saw the issue for dom0 updates, and I never managed to encounter it for template updates. Another noticeable difference is that I use Ethernet cable and Wi-Fi, but I have never used USB-tethering or USB-modems for internet on Qubes 4.
Dave C
> On Saturday, February 3, 2018 at 9:18:45 PM UTC+1, Dave C wrote:
> > I've noticed that in templates, `dnf` fails, i.e.
> >
> > ```
> > user@f26-devel ~]$ sudo dnf install tmux
> > Error: Failed to synchronize cache for repo 'updates'
> > ```
> >
> > While in an appvm, the same command works fine.
> >
> > The failure above occurs when I have sys-firewall using *sys-usb* (that is,
> > tethering over usb).
> >
> > When I switch sys-firewall to use *sys-net*, then `dnf` works!
> >
> > I've checked my settings in "Qubes Global Settings" and they show "UpdateVM" is sys-firewall. But I have to wonder is it actually using sys-net? Or does it only work when sys-firewall uses sys-net?
>
> You made your sys-firewall handle USB devices?
No, I configured sys-firewall to use sys-usb for networking, instead of the default setting sys-net. Same as you describe, I think.
BTW, the problem seems have gone away after I clicked the OK button in the "Qubes Global Settings" dialog.
I'm not sure the problem, but it behaves as if sys-net is used to update templates, even while Qubes Global Settings *shows* sys-firewall. But clicking OK on that dialog seems to have made the setting actually be sys-firewall.
As I said I'm not sure, but if that's the case it is a minor bug in the 4.x rc4.
Dave C
> On Saturday, February 3, 2018 at 12:34:18 PM UTC-8, Yuraeitha wrote:
> > On Saturday, February 3, 2018 at 9:18:45 PM UTC+1, Dave C wrote:
> > > I've noticed that in templates, `dnf` fails, i.e.
> > >
> > > ```
> > > user@f26-devel ~]$ sudo dnf install tmux
> > > Error: Failed to synchronize cache for repo 'updates'
> > > ```
> > >
> > > While in an appvm, the same command works fine.
> > >
> > > The failure above occurs when I have sys-firewall using *sys-usb* (that is,
> > > tethering over usb).
> > >
> > > When I switch sys-firewall to use *sys-net*, then `dnf` works!
> > >
> > > I've checked my settings in "Qubes Global Settings" and they show "UpdateVM" is sys-firewall. But I have to wonder is it actually using sys-net? Or does it only work when sys-firewall uses sys-net?
> >
> > You made your sys-firewall handle USB devices?
>
> No, I configured sys-firewall to use sys-usb for networking, instead of the default setting sys-net. Same as you describe, I think.
>
> BTW, the problem seems have gone away after I clicked the OK button in the "Qubes Global Settings" dialog.
Actually, shortly after, a similar problem appeared. When sys-firewall uses sys-usb, `dnf install ...` fails later than I reported earlier. It errors out this way:
```
Transaction Summary
================================================================================
Install 12 Packages
Total download size: 3.9 M
Installed size: 7.1 M
Is this ok [y/N]: y
Downloading Packages:
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Error downloading packages:
Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f26&arch=x86_64 [Received HTTP code 500 from proxy after CONNECT]
[user@f26-devel ~]$ sudo dnf install openssl-devel
Last metadata expiration check: -1 day, 17:20:05 ago on Sat Feb 3 20:14:15 2018.
```
But again, if I configure sys-firewall to use sys-net, and use wifi instead of usb tether, `dnf install ...` succeeds.
Odd! and still a mystery.
Yuraeitha
Try see if restarting the whole network and VM's so only dom0 is left works, and then start it up again (or restart Qubes altogether). Then without further settings adjustment after restart, does it work with updates now? I've experienced issues too in sys-firewall, it's mostly malfunctioning gpg checks in sys-firewall though, but a quick restart of all my network based VM's and sys-net/sys-firewall too, at which point I can easily install the updates with correct gpg checks. It has happened quite frequently the last 10 days or so, roughly, but never happened to me before that. Perhaps this is similar to yours?
The config file working after clicking "ok" sounds familiar, like the common bug in Linux in general, where configs are not read after major system updates or unexpected powerdown, situations like that. But your second post means it wasn't fixed anywway, I assume?
It might be a good idea to put this on github, chances are that they might fix it soon if the problem is general issue for all USB tethering's, which could affect many people, thus possibly given higher priority in the limited resources available. They can also better keep track of the issue on github. Try report it on github if possible.
btw, just to be sure, are you using it in this order?
sys-net --> sys-usb --> sys-firewall, and tying your Qubes-Global-Settings for NetVM updates to sys-usb?
What happens if you exclude sys-usb entirely in the above chain, and put your USB controller on the sys-net? It might not be needed to have a sys-usb, unless you have more than one USB controller, at which point you can better protect the other controller from being affected by internet connections by pulling the second or third USB controller behind the firewall. It just sucks that some systems only have one USB controller though.
Dave C
[ ... snip ... ]
> It might be a good idea to put this on github, chances are that they might fix it soon if the problem is general issue for all USB tethering's, which could affect many people, thus possibly given higher priority in the limited resources available. They can also better keep track of the issue on github. Try report it on github if possible.
I'll try to reproduce when time permits, and write this up better in a github issue.
>
> btw, just to be sure, are you using it in this order?
> sys-net --> sys-usb --> sys-firewall, and tying your Qubes-Global-Settings for NetVM updates to sys-usb?
No, I'm switching between
1. sys-net --> sys-firewall --> appvms (the out of the box default)
2. sys-usb --> sys-firewall --> appvms (sys-net disconnected)
And the behavior I see is...
setting #1, `dnf install ...` *succeeds* in appvms, *succeeds* in templates
setting #2, `dnf install ...` *succeeds* in appvms, *fails* in templates
The way the templates fail has switched from the error in my first post, to the error in my later post.
Yuraeitha
ahh I see. I haven't done much alteration from the original sys-net --> sys-firewall my self, but in my experience the moment they are pulled apart without getting all the required sub-settings changed too, bad things tend to happen. If you haven't tried this approach down below yet, try see if it works. If not, a different approach is needed, though I can't see why the below should not work, adding sys-usb only complicate things a whole lot more than it needs to.
Using the information you provided: "But again, if I configure sys-firewall to use sys-net, and use wifi instead of usb tether, `dnf install ...` succeeds."
Try go back to the original sys-net --> sys-firewall --> appvm's scheme, the one you reported working too. like you did before, change back UpdateVM for updates in global settings to sys-firewall. Make sure to re-attach your Wireless device, or ethernet device, if they were removed in the device list on sys-net, but in addition to that, also add your USB controller alongside it. In this suggestion avoid sys-usb entirely, make sure it's not tied with the above approach in any way.
If as you said that your updates work with Wireless or Ethernet, but not with the USB tethering (using the above layout), and USB works normally in sys-net otherwise, then you may have narrowed down the possible area the issue can exist. That is, if both Wireless/Ethernet/USB-for-other-things works in sys-net, but your USB internet tethering does not work, then it may much more specific related to the USB tethering drivers or USB tethering settings. If it works with this approach, then all good. But if it does not work, yet for example USB-storage devices or other USB devices can be seen and work in sys-net, then you may be closer to finding the actual reason why it won't work.
Further, it's also that your USB controller is pci-reset sensitive, which means it cannot reset the cards memory on request, unless it's been shut down. You may want to either add the reset flag to your USB device, either via termianl or via the VM-settings UI, or alternatively, restart Qubes altogether. If you do that, then you can test whether pci-reset is part of the problem or not. For example, once you do the setup suggested in this post, and you added your USB controller to sys-net. Once there, try restart your Qubes OS before testing, to be sure pci reset is not causing trouble, and then try see if it works or not.
(You're not using USB keyboard/mouse right? If you have no alternative input-type for keyboard/mouse, then moving the USB controller to another VM like done above might be dangerous if not taking precautions).
Marek Marczykowski-Górecki
Hash: SHA256
nice GUI for VM updates yet, but you can configure it manually in
/etc/qubes-rpc/policy/qubes.UpdatesProxy (adjust target=sys-net).
Related ticket:
https://github.com/QubesOS/qubes-issues/issues/3527
- --
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?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlp4zJQACgkQ24/THMrX
1yxhaAf/Q3iO2/kYqW4v8n2t6Lhc5QQH1ycGc3IDP6uZpHAz4qyaRfdRPz0IDMRf
gSz8dN8+Zea0qmb6IeDKF8HB9iNecTpfNSW6x1tWsK7z3QRbYN9Y2oqzPkadHSJA
YkSMMmvEiKyu9SLN5Lu8KtYWHOaMPk9b1LfbljzM/m3Tk1nk8X8goGqu/UyvLkPc
GkgXzNEmz8vxhMzcmEwcJJrPXVIghmQRyfdKWYcQ4S9T3VL3WzpkGZsilqS6DwzE
rqY91Fz6KCLGTe0ML0VUfnfvyc+Zn2/o9uRPD5NsbtEZA3qJdxPcSVB1/c+hz4b5
szhAD7iVs7CpV154idpZbWWp92GGFg==
=nWKv
-----END PGP SIGNATURE-----