Qubes updates download speeds are ridiculously slow

  1. Is this because it’s going through sys-whonix or something?
  2. Is there a way to at least get a different “Tor profile” or something to see if that helps with download speeds?
  3. Finally, what is the difference between sys-whonix, whonix-ws-16, and whonix-gw-16 ? (Only the first is started for updates)
1 Like

No wonder. The former is an AppVM, whereas the last ones are templates. An AppVM is the one that runs while being based on a template.
So, sys-whonix is based on whonix-gw-16.
I don’t know how much knowledge you have so feel free to ask if something is unclear.

I’m not updating through whonix at all…and it still seems “ridiculously slow.” It’s hard to tell if the delay is in downloading or installing though, because I can’t tell what it’s doing while it’s doing it (I am referring to the GUI version of the updater). I can’t even tell the size of the download. (If it’s downloading a GiB of stuff, then I should be praising the download speed, not dissing it. If it’s less than a MiB, then it’s wretched.)

1 Like

Post can’t be empty

@SteveC, what happens when you open one of your templates and try updating using the command line package manager? What sort of speed are you getting then?

I’ll let you know the next time one claims to need updating!

Actually I could probably induce that; there’s this one template that, as soon as I create it with my scripts, demands an update (via the gui widget).

(As a side note, that should happen for one of two reasons: The template I cloned it FROM needs updating, or one of the packages I just downloaded onto it is out of date. The latter shouldn’t happen, should it? But the template I cloned it from doesn’t claim to need an update no matter how many times I start it and shut it down.)

Anyhow, if I remember, I’ll try it this evening.

The update of qubes which I did yesterday evening and the download of two templates today morning were slow on my side too.
Download speed is avg. 500kB/s
Use sys-net based on fedora-34.

Well I figured out part of my confusion. A template must be left open for “a while” before the system will realize it needs upgrades.

So, I have a “base” template, which actually does need updating, and a “target” template cloned from “base” which (correctly) shows as needing updating. This is handy because I can readily revert “target” to an un-updated state by recreating it. Clearly to run this test, I should let the gui upgrade “target” and time it, then recreate target, start it, wait for it to light up as needing an update, and do it from the command line, timing it and observing how long it takes to download vs. install. Doing these tests at close to the same time should eliminate the effect of varying connection speed at different times of the day.

The problem is I can’t be quite sure if I know how in the heck to upgrade target from the command line.

“date; qvm-template upgrade target; date” simply gives me a message:

Template 'target' of highest version already installed; skipping...

Opening a terminal on target, and issuing the following:

date; apt update && apt full-upgrade -y; date

gives me permission denied, and

date; sudo apt update && apt full-upgrade -y; date

gives me

user is not in the sudoers file. This incident will be reported.

(Which as far as I can tell, it’s never actually reported…since it would have to report it to ME.)

OK so I then do, on dom0;

date; qvm-run --pass-io -u root target "sudo apt update && apt full-upgrade -y"; date

which does clear the “sun” icon from target and thus appears to be the right command. (If it’s not please let me know!)

And that took 44 seconds. Most of which appeared to be install time.

Recreating target from scratch and using the gui (and a stopwatch) [making sure to not let it update base] I noticed it starts the management dvm, and only after 30 seconds or so does it get around to starting the target, which takes more time to start. So basically, in the time it took to update from the command line, it hasn’t even gotten started yet. Total time roughly 1:39–more than double but it may be mostly “fixed” overhead from the manager VM.

I’m going to ignore the fact that base needs to be updated, for now, just in case you need more tests run.

These are the exact reasons why I use apt-cacher-ng. When it gets slow, it’ll be slow only for one qube per distro, in general…

True point…and I’m using it too. Which is probably why the download was nearly instantaneous during my tests. But there still seems to be a lot of bloat in the GUI updater.

Yep. I route the updates through Tor, and the updates are really slow. Usually I have to carve out at least an hour of time dedicated only to update the whole system.

I’m almost completely using template generation through scripts…so I have a lot of templates, and if they update debian 11, ALL of my templates need updating. I’m actually probably better off just rerunning the script, but that takes a long time (and I have to shut almost all qubes down, except sys-net, sys-firewall and cacher). Overnight would work, except that there are two things I must do to one of the templates (a great granddaddy to most of them) manually, before I let the script continue and base more templates off of that one. I haven’t figure out how to script them.

Hi gs-542

Not expert and maybe wrong forum but Why is Tor Slow? may help. Hope mods forgive “off topic” :sweat_drops:

To speed up updates, I simply set my “Dom0 update qube” (and “Clock qube” and “net qube”) to my VPN qube.

For some reason my VPN qube wasn’t working for updates earlier, but that is possibly because I had restored the VPN qube from a backup based on older Qubes (4.0), maybe leading to some incompatibilities. Recreating the VPN qube from scratch solved the problem. I also added “network-manager”, “clocksync”, “qubes-updates-proxy”, “updates-proxy-setup”, and “qubes-update-check” as Services on the VPN qube but I’m not sure how important that is.

The above ought to be fine if you don’t need Tor-level privacy for your updates.