Update how-to-update.md

[ninavizz]

Per https://github.com/QubesOS/qubes-issues/issues/#6871 added a blurb in the CLI section, to advise users that 1. The terminal in the update-vm will in fact open, and 2. Where the logs will be saved to. My notation on two may be incorrect, so pls check?

[andrewdavidwong]

Since this only applies to 4.1, I'll have to figure out the best way to handle this. See:

https://www.qubes-os.org/doc/documentation-style-guide/#release-specific-documentation

[DemiMarie]

Does this only apply to dom0 updates?

[ninavizz]

@andrewdavidwong I went ahead and took a stab at an update, mostly following the styleguide. Unfortunately, users tend to visually snapshot redundant text, and skip-over sections that appear redundant of text they've already read. Because of that, I did not want to 1:1 follow the styleguide, and create a block of text that's 80-90% redundant with what is up above.

I appreciate your rationale in the docs styleguide for retaining histories per version-specific guidance, with the 100% redundancy guidance. It just works against usability with how humans consume written content; a bummer of a phenomenon long observed in user research.

[ninavizz]

@DemiMarie Err... I'd thought you were the expert on that? Andrew and I are just making updates to the docs per the original issue this pointed to. If my text is incorrect, pls let me know! :D

[andrewdavidwong]

Unfortunately, users tend to visually snapshot redundant text, and skip-over sections that appear redundant of text they've already read. Because of that, I did not want to 1:1 follow the styleguide, and create a block of text that's 80-90% redundant with what is up above.

I appreciate your rationale in the docs styleguide for retaining histories per version-specific guidance, with the 100% redundancy guidance. It just works against usability with how humans consume written content; a bummer of a phenomenon long observed in user research.

That's part of the reason we don't want to do it this way anymore. We want to have release-specific docs instead: QubesOS/qubes-issues#5308

Might try to implement this for 4.1.

[DemiMarie]

@DemiMarie Err... I'd thought you were the expert on that? Andrew and I are just making updates to the docs per the original issue this pointed to. If my text is incorrect, pls let me know! :D

Sorry about that! There are two different concepts here:

1. The updates proxy, which is implemented as an HTTP proxy tunneled over qrexec. This is used so that dnf, apt, and other package managers can obtain packages from the Internet without template qubes having to have a network connection.
2. The UpdateVM, which is what dom0 uses to obtain updates. It uses a completely different architecture: the metadata is not processed in dom0, but rather in the UpdateVM, which computes dependencies and sends the appropriate packages to dom0 over qrexec (qubes.ReceiveUpdates service). dom0 then canonicalizes the packages (using rpmcanon), checks their signatures (both in rpmcanon and again via rpmkeys -K), and finally calls createrepo_c to create a whole new package repository of already-verified packages. It is that repository that dnf in dom0 actually pulls from. This is the case that pops up a terminal in the UpdateVM when run interactively, so that the user has a progress bar to see the UpdateVM downloading packages (the slow part).
   Once the packages are downloaded, the remaining steps in the process are quite fast.

[DemiMarie]

Logs aren’t actually sent back to dom0. Instead, dom0 recomputes the list of tasks on its own, and it is that new list that is displayed in the dom0 terminal window.

[andrewdavidwong]

@ninavizz, could you revise this PR so that it doesn't reference different Qubes releases and instead just speaks to the user on Qubes 4.1 (so, no past/future or version number references; just assume the user is on 4.1).

[andrewdavidwong]

@ninavizz, could you revise this PR so that it doesn't reference different Qubes releases and instead just speaks to the user on Qubes 4.1 (so, no past/future or version number references; just assume the user is on 4.1).

Actually, scratch that. The way you've done it here is already correct. My mistake.