The previous plan was “please user find some way to stay tuned” (important blog, subscribe by mail, mailing list, Whonix News) to inform about such issues before they happen. Since that mechanism is probably largely unknown or ignored…
The practice has been to support the older version for one month and to encourage upgrading. From then, the longer the upgrade has not been done, the less effort is spend on support.
Would definitely advise not using unattended upgrades with custom apt-pinning preferences (unless someone here has a solution). Recently ran into an issue that would’ve upgraded my Stable Whonix to Testing if I wasn’t paying attention (or using auto-updates). Posted to debian-user but no replies: https://lists.debian.org/debian-user/2016/05/msg00874.html
Have you considered separating updates and upgrades? In other words, make it so that when users follow the normal update procedure, they do not accidentally upgrade to a new version. Instead, upgrading to a new version could require an explicit command or procedure so that it must be done intentionally. (Of course, the user can still be asked/prompted to take that action.)
Given your answer, I think this would be a good situation to use the new Whonix News functionality that you described here: whonixcheck Whonix 14 ideas
Some advance notice should be provided before a version upgrade so users know to backup and/or expect a big update. Ideally, users should confirm the updates that they apply anyway but it’s safe to say that’s probably not the case.
Whonix XX will be released on Jan 1, 2017. Please prepare your system by reading the upgrade instructions here: www…
TL;DR: A Meta-package doesn’t contain code. It’s just a list of packages - in this case, all the packages that make up Whonix 13. Having the meta-package guarantees that you have at least all of the packages that you should. Not having the meta-package doesn’t necessarily mean that you are missing something but why take the chance?
To describe myself as upset right now is a major understatement. One of the major justifications to adding Whonx to Qubes was that much of the updating and maintaining of VMs would be handled by the Whonix templates within Qubes. Now, we find that this totally untrue.
I spent two hours downloading and installing regular updates and dist upgrades and only at the very end when I get this error message do find out that I did it all wrong. Worse, now that I am root there are packages to be installed that I just auto-removed when I was updating as non-root because that it what the upgrade program told me to do. I want to cry.
Not everyone is a forum junkie. Not everyone keeps up to date on what Whonix is doing. We should be able to rely on the regular update process to upgrade Whonix without any special instructions to following Qubes has an updater, use it!
If the net result of using Qubes with Whonix is that one has to go through the exact same nonesense to upgrade that one has to under KVM or Windows I’d rather go back there–all I have to do then is download the new release and start all over again. The amazing thing is that is would have been faster to download gigbytes over clearnet than all this non-sense over Tor and I doubt sincerely that I would be less safe.
Please understand, that Whonix is far more complex than most standard issue virtual systems.
Also, if redownloading and installing the entire system isn’t a problem, this may be done on Qubes at least as fast as on other systems, probably even faster. If you look at the guide, non Qubes users have to go through a similar amount of stress when trying to purely upgrade.
Furthermore, the fact that you were informed this late about issues and that some packages are reinstalling themselves sadly isn’t a Whonix related issue, but just created by how Debian (and most Linux based OS’s in general) handle updates.
A major talking point tof moving to Qubes was to avoid this problem. When I connect sys-whonix to Tor I get a message in the message box that says “Connecting to Tor” and then “Connect to Tor”. There is simply no reason on earth why that message cannot also read, when necessary, “A new distribution to Whonix is now available. Please see the whonix website for special instructions.”
These messages are the exact reason why people like myself do not run Whonix Check on a regular basis. There is no need because we get those notifications another way.
There is a way to deliver the correct information to the user right at the desktop. It’s not being used. Instead, what we have is notifications cast to the wind and pray that the user sees one of them and if not, well, their bad luck.
Whonix 14 should have a more-informed transition process.
Regarding the actual upgrade process: Qubes does not handle template upgrades. Each template is responsible for itself - meaning no guarantees can be made that future upgrades will be any simpler or more automatic. However, your point about being directed to upgrade instructions before actually upgrading is well taken (by me - but I’m not a dev )
Good to hear it. Let me be clear. I am grateful for the hard work that Patrick and others have put into Whonix and Qubes. It is simply the fact that when one is dealing with security, especially secure operating system, what one doesn’t like is to be surprised. This is the first time I have gone up a distribution while under Qubes and I didn’t expect this type of situation. I now know better.
FWIW this error message has now gone away after I followed the directions on the Wiki.
Keep in mind, in most cases, you can simply swap out your template for the newest one. There are actually 3 methods to upgrade your Whonix distribution:
In-place using apt-get (per wiki instructions)
Semi-fresh: Keep your existing proxyVMs & appVMs.
Download latest templates.
Switch templateVM for each of your existing VMs.
(Since Whonix templates are the same name regardless of version (ie qubes-template-whonix-ws), I like to clone them right after downloading to something like whonix-ws-13. Then I remove the templates right away. That way when whonix-14 comes around, I can download the new templates and still have my whonix-13 templates.)
Completely-fresh: Download latest templates.
Make new proxyVMs & appVMs.
Copy data only from existing VMs.
Actually, I would like someone to comment on the probability of breaking your system doing #2.
(My guess would be that it should be fairly safe until people start using bind directories and then have stale configs that persist…)