On R4.2, my thinkpad T470 has working suspend and resume
I apologize if the answers to this appeared elsewhere.
I know that to run the release candidate a complete install is necessary. And I know that once it’s actually released, you will be able to just run update to get it. (At least that’s what the first post says.)
I presume that templates (like debian 12) will still have to be downloaded, and any cloned templates will have to be rebuilt? (And appvms will have to have their templates changed.) In other words debian-11 templates will not update to debian-12?
In the long term, a rolling release such as
Arch should be considered as many breaches may happen due to too complicated unfollowed upgrading procedures.
Not automatically, and for good reason. We cannot assume that every user wants to upgrade all of their Debian 11 templates to Debian 12 at the same time in the same way. Some users might want to keep some templates on Debian 11 for a while. Some users might have made customizations to their Debian 11 template that would be broken by a forced automatic upgrade.
Agreed, and it’s nice to know.
I’m sure I don’t want to bite all of that off at once.
I wouldn’t mind doing the templates first, if they are ready before 4.2 is released.
A post was split to a new topic: Why the disk encryption phrase has the option of ‘f1’ to hide the bullets
I don’t really (personal opinion) enjoy the new menu, I find it less practical and dom0 console is hard to find. Nonetheless, the old menu lost all the icons/colors
R4.2 adds split-gpg and split-ssh management in the Qubes global settings GUI, this should be added to the new features list, it’s a huge usability improvement
Thanks for the suggestion!
Given it can take well over an hour to download and update a new template releasing R4.2 missing two (out of only 3) of the newer templates (whonix17 & debian12) doesn’t sound like a good use of time to me. A new user would be completely turned off.
My hope is to redo my pc on R4.2, but if the expectation is more hours of time after that time spent to update to the latest R4.2 version to the “actual” latest R4.2 version I’ll wait.
No need to worry. No templates will be missing. Qubes 4.2 will include both Whonix 17 and Debian 12. The message you’re quoting is referring to in-place upgrades, which are a different story. Existing templates have never been upgraded in-place automatically when upgrading Qubes OS itself in-place.
Thank you for the clarification. That makes sense.
Based on the responses this seems an appropriate place to mention a bug.
Two people have had this same issue running 4.2 with KDE and having audio drop out. I linked my issue thread in the comments and I arrived at a solution by disabling pulseaudios idling.
All bugs should be reported on the
qubes-issues issue tracker on GitHub:
Where can I learn more about the current state of the “in-place-upgrade” tool for QubesOS 4.1 (in order to upgrade to QubesOS 4.2) ?
I thought it still should work (for Upgrade to 4.2) too, but with a special switch in the command, so the upgrade function knows, it should use the upgrade to an RC-x version.
If not - then we have to wait until the final version is out!
To try it out without trouble I would suggest the following:
Boot up in a live system (for example TailsOS from an TailsOS USB stick) and doing an image from your entire QubesOS harddrive by using the “Drive” tool of the TailsOS stick (live system) and an USB harddrive, which has more space as your QubesOS harddrive.
After having your image of the QubesOS save on the USB drive - unplug it and boot into QubesOS again - do the upgrade and check out, what errors you’ll may run into. If there are any, you can’t solve - just turn off your device and boot up into the live system again and restore your 4.1.2 QubesOS again from the image…
After you’re using the same harddrive for QubesOS - nothing has to be changed on the bootloader, so this works fine on my side. Tried it several times on the upgrade from 4.0 to 4.1, because I ran into some errors during the “in-place-upgrade”.
“In-Place-Upgrade” always have some trouble with non-qubes-vms (as Windows10/11 qubes are or others with other OSes). Maybe it’s good to made backups from these qubes before - delete them and after you only have disp, templates, usual-vm’s and that regular Qubes stuff in the qubes manager - start the in-place-upgrade process.
Later you can restore those external qubes again from backup in 4.2
The in-place upgrade procedure is not ready yet (#7832). Currently, R4.2 can be tested by performing a clean installation.
Means for my previous post: Just do the image from your old QubesOS harddrive and install 4.2 from scratch. If you don’t were satisfied with 4.2 - just restore 4.1.2 from image by deleting 4.2
buy a new harddrive which is similar to the one in your device. Plug-out the old 4.1.2 hd and plug-in the empty new one and install 4.2 from scratch.
Perfect method should be:
- doing a backup of all qubes of the 4.1.2 system to an external harddrive
- booting TailsOS from a stick and doing an image of the entire 4.1.2 system on the external harddrive by using the Tails “Drive” application
- delete all partitions of the 4.1.2 system
- shutdown the device and unplug all sticks and external harddrives
- installing 4.2 from scratch from a CD-Rom/USB Stick/image
- restore all your qubes from the 4.1.2 qubes backup into your new 4.2 system
I did this in the past with my 1GB Qubes 4.0.4 system and a 10TB external harddrive
I’m just answering the question.
The (#7832) leads to the github issue regarding the in-place update tool.
Is it recommended to do a fresh clean install? Or will an update be sufficient? Thank you