I’ve already explained this.
In dom0 - manually run qubes-dom0-update
In a template - manually run the package tool - perhaps sudo dnf update
or sudo apt update as appropriate.
In both cases you will see the amount to be downloaded. You say “No” at
the prompt, and then can decide whether to update using the GUI updater.
In dom0 - manually run qubes-dom0-update
Currently it says “No dom0 updates available”. I will keep checking in next days. One thing is sure: this command dos not give info about how much will be downloaded during the process of checking for updates (refreshing the repository info). It is not insignificant, as I have seen (using vnstat) it downloads about 90 MiB only during this phase. This obviously raises the secondary question: is there a way to block automatic check for updates and do that only manually? (at least until a proper solution for displaying actual update details is found)
In a template - manually run the package tool - perhaps
sudo dnf update
orsudo apt updateas appropriate.
After reading the docs I see that the correct commands are: sudo dnf check-update (fedora) and sudo apt list --upgradable (debian). None of them shows total or individual package sizes to be downloaded. They only list the upgradable package names and their versions.
So, the question remains.
I would swear that when there are updates available you are informed how much it takes to download and how much it would occupy space on disk, prompting you with Y/n.
No, the question has been answered.
It’s good that you did some research for yourself.
But in this case you should follow what I said instead of what you read.
If you run the command in dom0,(when updates are available), you will see
both the package names and how much will be downloaded.
If you run the command I gave, e.g in a Debian template apt update, you will see both the package names and how much will ve
downloaded.
In both cases, as @enmus says, you will be prompted whether to continue.
Say “N” if you want to use the GUI tool.
Although there is a proper solution, if somewhat unwieldy, you can
easily turn off automatic checking. Open Qubes Global Settings. Look at
the “Updater checks” section.
Now that I ran sudo dnf update in the fedora template it shows individual and total download size. So, indeed, this part of the question was answered. Thanks. Thank you for answering the secondary question too.
If you run the command in dom0,(when updates are available), you will see
both the package names and how much will be downloaded.
OK. As I wrote, I will keep checking.
If you run the command I gave, e.g in a Debian template
apt update, you will see both the package names and how much will ve
downloaded.
For Debian here is what I get:
root@debian-11:~# apt update
Hit:1 https://deb.qubes-os.org/r4.1/vm bullseye InRelease
Hit:2 https://deb.debian.org/debian bullseye InRelease
Get:3 https://deb.debian.org/debian-security bullseye-security InRelease [48.4 kB]
Fetched: 48.4 kB in 4s (11.0 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
7 packages can be upgraded. Run 'apt list --upgradable' to see them.
Then I ran what it suggests:
root@debian-11:~# apt list --upgradable
gir1.2-javascriptcoregtk-4.0/stable-security 2.36.6-1~deb11u1 amd64 [upgradable from: 2.36.4-1~deb11u1]
gir1.2-webkit2-4.0/stable-security 2.36.6-1~deb11u1 amd64 [upgradable from: 2.36.4-1~deb11u1]
libjavascriptcoregtk-4.0-18/stable-security 2.36.6-1~deb11u1 amd64 [upgradable from: 2.36.4-1~deb11u1]
libsnmp-base/stable-security 5.9+dfsg-4+deb11u1 amd64 [upgradable from: 5.9+dfsg-3]
libsnmp40/stable-security 5.9+dfsg-4+deb11u1 amd64 [upgradable from: 5.9+dfsg-3+b1]
libwebkit2gtk-4.0-37/stable-security 2.36.6-1~deb11u1 amd64 [upgradable from: 2.36.4-1~deb11u1]
linux-image-amd64/stable-security 5.10.136-1 amd64 [upgradable from: 5.10.127-2]
So, the only size shown is that 48.4 kB. Unless I am misreading this output, this is not the size of the packages that will be downloaded but rather just the size of the “refresh” of the repo info.
Could you please clarify this confusion?
At least for Debian you can install Synaptic (you can download package once, transfer it, but do not install in a template, and from a template transfer it each time to a dispVM) in order to get arguably better visual preview according to your needs…
Although, I’m not sure if we are talking about gigs per month here, and each monthly plan should cover much more than that…
Setting a cacher qube would help you to spare bandwidth and it’s simple as
I mean…
$ sudo apt full-upgrade
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
Calculating upgrade… Done
The following packages were automatically installed and are no longer required:
xxxxxx
Use ‘sudo apt autoremove’ to remove them.
The following packages will be upgraded:
xxxxx xxxx xxxxx
xxxxxxxxx xxxx
6 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 20.9 MB of archives.
After this operation, 12.3 kB of additional disk space will be used.
Do you want to continue? [Y/n]
And this indeed isn’t Qubes specific…
Are you suggesting that the correct command for Debian is apt full-upgrade and not apt update as suggested by @unman?
And this indeed isn’t Qubes specific…
I believe you. My question is not intentionally a non-Qubes one. I am just struggling with things as I am new to Qubes and through that new to its components too (Debian included).
BTW my earlier question #3 from 2022-08-01 is still valid. I would be glad to know what you and others think about it. Thanks.
You just need to read what is written. If there’s no updates or upgrades, you won’t see anything. If there are updates but no upgrades, you use apt update. If there aren’t updates, but only upgrades you run correspondent command apt full-upgrade. if there are both updates and upgrades you run both commands? Do not forget `dist-upgrade.
Running the command isn’t the same as updating. You have to read what is written. It’s not the command that is “dangerous” but what it does and what you are letting it to do.
It’s not about if it’s appropriate. Anyone is free to suggest whatever feature she would like to. Proper way to do that is on Github,
You just need to read what is written.
That’s exactly what I am doing. Thanks for the links too.
My follow up questions arise from the difference between what the docs (including warnings), @unman and you suggest as proper commands.
Runningthe command isn’t the same asupdating. You have to read what is written. It’s not the command that is “dangerous” but what it does and what you are letting it to do.
I understand that running a command and updating can be different (in case the command would ask the user whether to continue) or the same. Being new to the process, I had no way to know which one was the case and as it is a sudo command, considering also the warning in the docs (which I have read), I thought it would be better to ask before doing anything without understanding what the result would be. I hope that clarifies that the reason for the follow up questions.
Considering the obvious need for extra “education” and the additional work one has to do for something as simple as knowing how much an update will download I think it is appropriate to have it as a feature.
Thank you for your help.
apt update gets the latest information from the repositories.
apt full-upgrade will start the process of downloading the updates,
but won’t actually do anything unless you say “Yes” when prompted. It
will tell you what packages would be updated and how much would be
downloaded.
I thought I had included both commands, but apparently not.
I’m fairly sure that this is already covered in a GitHub issue.
I never presume to speak for the Qubes team.Thanks. Definitely not good month for my focusing…
Thank you!
I have just noticed something which seems Qubes specific:
After updating all templates (there is currently no update for dom0) in the Debian template I ran apt dist-upgrade and it showed that linux-image-5.10.0-10-amd64 will be removed. I allowed that.
Does that mean that Qubes Update does not run apt dist-upgrade thus not allowing the cleanup this command allows? If yes, do you think this is an issue to be reported? If no, what is the intention?
*I understand this is somewhat off-topic but I thought it might be good to clarify that too, as it is directly related to updates.
You are right, Qubes Update doesn’t run dist-upgrade.
That’s fine. In most cases it’s better not to run that, especially
non-interactively.
dist-upgrade and full-upgrade are both capable of removing packages,
whereas upgrade will not. Removal is probably fine for old kernel packages
(probably), but can cause confusion otherwise.
So, you would like to know the size of a repo before you sync it?
That would rely on the repo server actually telling you, and most don’t.
I don’t know if you can say that any more. Nice try 
Nice!
You learn by experience. Don’t be afraid to break things. The knowledge and skills you build by fixing them is second-to-none.
(don’t break any production machine, of course…)
You can never have enough education. You never stop learning. Knowledge is power 
You basically told Debian to upgrade EVERY single package, even if it breaks stuff. Some packages rely on specific versions of software in order to work (Python is a notorious example of this. “this function is ‘old’, let’s get rid of it!”).
“Security reasons” basically means that the updates are obtained in another VM, and then passed through into the template via qrexec. The package managers in the Debian, Fedora, Arch, CentOS and Gentoo templates have been configured so that they will work if you open a terminal and type in their respective update command.
The only main difference is that whatever system updates you download will be cached inside your template instead of a disposable management VM (and I’m sure you know that everything in your template is visible in the AppVMs you base on that template).
This one is less about preventing nasty things from getting in, but more about limiting the amount of unique information they can get about where they got into, if anything does get in.
This is fairly important, too. Yes there are ways to get the same results via command line, but the GUI is more of a convenience tool.
Not at all. As far as your network traffic goes, you’ve basically done a repo sync, and that’s all any third party would be able to see.
That would likely require quite a lot of back-and-forth via qrexec between dom0 and the VMs. Security concerns aside, it would be a lot of hacking stock-standard distribution package managers, which would require a custom version of each template’s package manager. It would only really be worth the effort if it was accepted upstream, and I honestly don’t see that happening, unfortunately…
I understand where you’re coming from with zypper, pacman, dnf, apt, and emerge showing the size of each package, but any solution like that would need to coexist with vanilla package managers from the distributions, to minimise maintenance work.
But hey, it can’t hurt to come up with a design and suggest it 
It shows the details of the qubesctl command, not the package manager inside the template.
Yes, what you’re suggesting is a button that would open a window showing something like:
qvm-run <template> --pass-io 'tail -F /var/log/package-manager/progress.log
(this is not a 100% real command, just FYI) 
There are definitely things that can be done, but I wouldn’t expect anything any time soon, at least until a layout can be agreed upon…
Issues · QubesOS/qubes-issues · GitHub
I can explain this. In Qubes 4.0, a separate window didn’t open, and the output of the dnf command was shown in red in the dom0 terminal.
You’re right in the sense that qubes-dom0-update by default automatically syncs the repos and downloads any and all new packages without asking first. The confirmation for the user is only presented once they are downloaded and moved into dom0, so I’ll give you that one.
What currently happens:
qubes-dom0-update → sync repos → download any and all updates → move to dom0 → show updates and sizes → user confirmation → install updates
What @qubist is suggesting:
qubes-dom0-update → sync repos → show updates and sizes → user confirmation → download → move to dom0 → install updates
I can see what your concern is with this process. I have updated Qubes OS with mobile data in the past, and have used my entire month’s allowance in 10 minutes. Yes, I know that the simple answer would be to just find a better internet connection, but if that isn’t an option for some people for whatever reason, knowing whether you’re downloading a security update or a completely new version of Xen before you do it would actually be helpful
Salt scripts weren’t exactly designed to do things like that.
That doesn’t mean that extra grains couldn’t be created in the pillars to show this, though…
So just to clarify, what you want is:
Am I right?
On a side-note, there is actually a Qubes OS Tumbleweed template out there “in the wild”, and I have been trying to get my hands on it.
Thank you for the detailed answers!
I don’t know if you can say that any more. Nice try
Hehe Well, maybe not a 100% noob any more but still fairly new.
You learn by experience. Don’t be afraid to break things. The knowledge and skills you build by fixing them is second-to-none.
Sure. I have already reinstalled the whole Qubes OS 4 times (or were they 5?). Not because I broke it but out of desire to (re)make things the right way. I am trying to reduce the rate of reinstalling by refining my knowledge rather than by breaking and fixing more things.
You can never have enough education. You never stop learning. Knowledge is power
On a lifetime scale - sure. Still, in the context of this thread, I hope you would agree it should not be necessary to become an expert in order to do such simple things. So by “education” and “additional work” I meant all the time and energy spent by all the people taking part in this thread for outlining a solution to a very simple problem which is already solved by most (perhaps all) distros/OSs. In the case of Qubes OS the info is obviously already there (or quite easily retrievable) - it just needs to be shown properly.
You basically told Debian to upgrade EVERY single package, even if it breaks stuff.
IIUC dist-upgrade removes only dependencies which were but are no longer necessary. Why would that break stuff? For so many years openSUSE’s zypper up/dup has never broken anything for me. Are you saying that Debian’s dependency handling is fragile and unreliable?
“Security reasons” basically means […]
Thanks for explaining. The warning is already removed, as mentioned earlier, and now those 2 Salt formulae are suggested as a command line alternative to using the GUI Qubes Updater.
The only main difference is that whatever system updates you download will be cached inside your template […] if anything does get in.
Would using those 2 Salt formulae result in such caching (and all its implications which you and @unman explained) or is it identical to using the GUI updater?
Also, will using the 2 Salt formulae result in missing those
The GUI Update tool is sometimes used to make configuration changes in dom0
and in templates. If you don’t use it then you will miss these.
Does this mean that by using the 2 Salt formulae from the docs one will miss those changes?
This is fairly important, too. Yes there are ways to get the same results via command line, but the GUI is more of a convenience tool.
What are these ways? Where can I read more?
That would likely require quite a lot of back-and-forth via qrexec between dom0 and the VMs. Security concerns aside, it would be a lot of hacking stock-standard distribution package managers, which would require a custom version of each template’s package manager. It would only really be worth the effort if it was accepted upstream, and I honestly don’t see that happening, unfortunately…
Why a lot of back-and-forth and hacking? Is it not as simple as running qvm-run with the commands suggested here in the template, parsing its output and outputting it to the GUI? Even I can do it in a bash script (but not in GUI). What security concerns do you see in that?
You’re right in the sense that
qubes-dom0-updateby default automatically syncs the repos and downloads any and all new packages without asking first. The confirmation for the user is only presented once they are downloaded and moved into dom0, so I’ll give you that one.What currently happens:
qubes-dom0-update→ sync repos → download any and all updates → move to dom0 → show updates and sizes → user confirmation → install updates
Just to note: Currently the “sync repos” step takes about 150 MiB of download and about 10 MiB of upload traffic. I don’t know why this is so huge but it is really not quite acceptable for one who is on a limited mobile traffic. You know that from experience I wonder if that can be optimized through e.g:
What @qubist is suggesting:
qubes-dom0-update→ sync repos → show updates and sizes → user confirmation → download → move to dom0 → install updates
Turns into:
qubes-dom0-update → “Is there an update at all?” → “Would you like to sync repos?” → Y → tell the user how much ‘sync repos’ would download and suggest to the user to sync repos for more details (e.g. when pressing the Details button) → sync repos → show updates and sizes → user confirmation → download → move to dom0 → install updates
Salt scripts weren’t exactly designed to do things like that.
I had never heard of Salt before using Qubes OS, so this is new to me. Where can I see the source code of those scripts? Maybe we can suggest a redesign based on the parsing mentioned above.
So just to clarify, what you want is:
- The ability to be able to see the size of updates at a confirmation screen before any data packets are transferred
- Fairly feasible and straightforward
Yes.
- The ability to see progress and log updates in the Qubes Updater GUI
- Less straightforward and a little “hacky”, but just as feasible
That would mean actual Details. Otherwise the Details button makes no sense before anything is updated. Either it should be removed (which is even worse) or it should function properly matching at each phase of the process.
- The ability to see how much data will be sent/received before a repo sync
- Impossible, unless you already know the size of the repo…
I wonder if there is a way to know the size of the repo, i.e. if repos contain such “metadata for the metadata”. Otherwise perhaps an HTTP head request (curl -I) could give the size of the ‘sync repo’ data before downloading it. Would that make it possible?
On a side-note, there is actually a Qubes OS Tumbleweed template out there “in the wild”, and I have been trying to get my hands on it.
Where can I learn more?
I’m told that it does, specifically here:
https://github.com/QubesOS/qubes-mgmt-salt-dom0-update/blob/master/update/qubes-vm.sls#L47
IMHO, this makes sense, since the Linux kernel version cannot be upgraded with just apt-get upgrade, which means that, if the Qubes Update tool were to use only apt upgrade (and not apt dist-upgrade), then users who update solely via the Qubes Update tool would never get kernel version upgrades.
This is not quite accurate. The main reason has to do with the fact that Salt is capable of delivering security fixes that standard package manager updates cannot (see here for more).
I believe that’s what this issue is about:
The Salt commands are equivalent to using the GUI updater. The documentation states this: “Advanced users may wish to perform updates via the command-line interface. The recommended way to do this is by using the command-line equivalents of the Qubes Update tool. [Then goes on to list the Salt commands.]”
[Side note: I just noticed we still have a 4.0 section here, so I’ll remove that now.]
No, because they are equivalent to using the Qubes Update tool.
Simply by using the Salt commands that we have been discussing, since they are equivalent to using the Qubes Update tool.
That would be a question/complaint for the upstream projects (Fedora and Debian, I suppose). When it comes to this specific aspect of the situation, we are simply using the tools and infrastructure they’ve built.
https://github.com/QubesOS/qubes-mgmt-salt-dom0-update/tree/master/update
More generally, here are all the Salt-related repos:
The perfect example is the Qubes packages inside a template. They have specific dependency versions, and if the distribution repos contain newer versions of dependencies and you force an upgrade, the package manager will usually remove the Qubes packages.
(ahem…ARCHLINUX!!!…sorry, I had something in my throat )
Disclaimer: I love Arch, but my Arch templates break more than my Gentoo templates…
I think you’re putting words in my mouth, and I don’t see how this will benefit anyone.
apt is solid, and there’s a reason why it has stuck around. But like any piece of software, it is only as good as the information you feed it.
(and before you say that I’m insinuating that apt is somehow being fed bad information from any entity, I am saying nothing even remotely close to that).
Because dom0 needs to know what’s going on by receiving status updates from the VMs, hence the back-and-forth.
It may well could be. Communication between process inside a single VM is the same as on any computer, and you know that. Any communication that goes between VMs (and/or dom0) is only done via the qrexec protocol.
As long as there is a communication channel that cannot be (easily) exploited/hijacked, then it’s potentially viable option.
Yeah, you definitely can’t say that you’re “new to Qubes” anymore after that comment
A VM should talk to dom0 as little as possible, and only when absolutely necessarily, in a nutshell. If you open up an extra channel for anything to get out of a VM and into dom0, you potentially increase dom0’s attack surface.
Unfortunately, as awesome as the distribution package managers are, you cannot assume that they are fully “trusted”, so if you were to give them a direct route into dom0, well, I’m sure someone could potentially find a way to exploit that…
Having said this, this wouldn’t be the only way to achieve what you’re suggesting.
Comment edited to reflect accurate information