So Fedora 37 became available march 3, and Fedora 36 is end of life as of May 16?
I’m glad Fedora is giving people enough time to make a leisurely transition.
To be fair, Fedora 37 itself was released before March 3, but it takes time for the Qubes developers to create the Fedora 37 template.
Even so…unless it took Qubes developers more than a year, that seems like a ridiculously short time for Fedora to support a release–even if it took the developers two years (and I can’t imagine it took that long), the implication would still be a painfully short lifetime for Fedora releases.
Thanks for the split. I apologize for making it necessary; I shouldn’t have griped.
No worries. 
You don’t have to use Fedora, you can use Debian. Debian release a new version every 2 years.
I use fedora for templates because dom0 is based on it in order to supposedly avoid any incompatibilities when setting the system.
And I agree release cycle is ridiculous, especially for those who have dozens of templates…
But, if dom0 can use fedora 32, then why not to use fedora EOLs for offline qubes’ templates until it’s possible? So, to use latest fedora only for sys-net and sys-firewall basically and other qubes going online or that needs latest release…
1 Like
The red hat folks probably have financial incentives in a short release cycle. This way they may charge consulting fees for product upgrades more frequently…
I think ultimately a solution to this would be to have reliable (or roll-backable) one-click template inplace upgrades. I’ve had success with inplace upgrades from fedora-36 to fedora-37. But then one also has to set all the other global settings and create a fedora-37-dvm and all that.
I couldn’t find the issue for this, but I’m sure I’ve seen it on the issue tracker before.
3 Likes
I agree, or at worst I suspected it’s all about money.
What I do is:
download fedora-current-minimal, then
[user@fedora-EOL~]$ sudo dnf repoquery --qf ‘%{name}’ --installed | grep -v – ‘-debuginfo$’ | grep -v ‘^(kernel-modules|kernel|kernel-core|kernel-devel)$’ > pkgs_a.lst
[user@fedora-EOL~]$ datamash transpose < pkgs_a.lst > fedora-EOL.lst
then
[user@fedora-current~]$ sudo dnf install content-of-fedora-EOL.lst
clean entries that are reported as issue by dnf, and run it again and I get new template prepared in seconds.
Then I just change the template of fedora-EOL-dvm to fedora-current-minimal, and rename it eventually if needed to fedora-current-dvm.
I couldn’t figure out faster, or more convenient way for me for a transition.
1 Like
Oh, yes, I should have mentioned my VMs (except for windows 7 of course) are all debian-11. Now I feel quite vindicated in that choice. (Actually, I do have a couple of Fedora 37 minimal qubes I was using to try to debug sys-audio. I probably ought to just delete them.)
Their release cycle is once every two years, as you said, and at least you have some time to switch over before the penultimate version goes end-of-life
I’m not aware of any such incompatibilities and haven’t noticed any myself.
Of course. That’s why I used “supposedly”. I’m just following basic concept - if dom0 is based on fedora, let’s not get into situation to think something doesn’t work elsewhere because I use debian there. Nothing more than that.
This is highly relevant to why Qubes isn’t considered user-friendly.
Upgrading Debian templates is a big slog for me–I’m sure Joe the journalist (or Josephina) will not find the prospect --or, more likely, surprise-- of needing to upgrade all their Fedora templates twice a year pleasant.
I think @deeplow’s solution of an in-place upgrade would make it far less user-unfriendly (assuming it could be done while assuring users it hasn’t broken things–security things), but ultimately switching to Debian as default would be better.
Speaking of journalists–how is SecureDrop doing? Does it need frequent template upgrades?
1 Like
On Debian, you can use .bash_history as a log file of your changes, and repeat the same steps when you upgrade.
If you only installed software, you can execute the history as a shell script.
1 Like
Neat! Thanks for the tip
Does this mean a Debian in-place upgrade (executed by Salt/dom0) would be easier to implement?
It would be dangerous to blindly replay the history, I wouldn’t do it without looking in the file first.
But you can already choose to install only Debian templates in the installer. Do you mean simply having the Debian box checked and the Fedora unchecked by default in that section?
It may not sound like much, but for your average Joe, the current default implies that Fedora is recommended by the Qubes Team over Debian.
When their security is on the line and there’s isn’t enough time to scrutinize every setting, they’re far more likely to go with the flow. This will end up costing them a lot more time and effort in the long run, but they wouldn’t know–nor should they be expected to.
Little UI changes like these make huge differences
A post was split to a new topic: How is the SecureDrop Workstation doing? Does it need frequent template upgrades?