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?
All your concerns can be solved by automating your installation. (not advertasing because it’s mine).
https://forum.qubes-os.org/t/fresh-installation-shell-script-minimal-templates-app-qubes-default-settings/16992
If you struggle with bash functions, follow the Sven’s guide.
https://forum.qubes-os.org/t/automate-debian-minimal-based-template-creation/11421
It takes some time to setting it up, but it’s a one time job. When it’s done, it’s done.
Update your script as you go, or make a note/todo at the top for new packages/settings/etc.
It’s based on Fedora, but you can easily adjust it to use debian.
When a new Fedora version is realeased, you just have to run the script.
In 1 or 2 hours tops, you get the exact same config than the previous release.
To me, the release cycle of fedora is not an issue (or too short) (YMMV).
(And you can still skip 1 version and update it every year).
1 Like
Thanks. I am not into scripting at all. I looked at your valuable resource, and as expected I couldn’t find at a first glance how to exactly automate upgrade from f37 to f38, copying all the settings and tweaks from f37 to f38 and setting lower level qubes based on f37, now to be based on f38.
I am almost sure it would be probably too much to ask you for such a script example, but thanks anyway…
yeah, as I said, it requires some time. The script is already an example of what you want.
It’s also a bit outscope of this thread. I post it, because it solve the issue of short release cycle.
I advice to read the Sven’s post. He explain a lot more than I do in my guide.
1 Like
The script alone won’t just upgrade you (at least not if it’s like Sven’s stuff, which I used as a starting point). What the scripts do is reliably generate the same thing, every time you run them. That doesn’t sound very useful but follow me just a bit.
If you went that route, you’d write scripts that re-create what you have now. Then when the next version comes out, you can hopefully change one line in the script (to reference the new version), re-run the scripts and now you have your own configuration, only now built with the new template.
I’m on Debian, and I think a new version of that will drop in a couple of months. After waiting perhaps a month for early adopters to find issues, I will find out for the first time whether I did the job properly on my scripts. (Meanwhile I used mine to largely recreate my desktop environment on my laptop when I switched it to Qubes.)
1 Like