The Fedora release cycle is too short

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.


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


[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).

If you struggle with bash functions, follow the Sven’s guide.

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

I’ve encountered a few problems with using Debian due to the fact that new versions get into the repo slower. On few occasions things just stopped working as they used to because the version wasn’t “high” enough. In fact, just last week I had a web-based management console not loading at all (blank page). Turns out the provider (one of the big names in remote support systems) did some update on their system and the Firefox version for Debian (ESR) wasn’t good enough for it. I had to manually install the “stable” version and persto - it all works again. (I really don’t like installing things outside of the official repo).
However, I totally agree that Fedora lifecycle is a bit too short. From a user perspective, I think that releasing a new version every year is fine, but would like to see it supported for 24months. Upgrade takes time, applications and configurations don’t always slide smoothly into the next version even when doing in-place upgrade, so it makes it all very time consuming.
Could Qubes wonderful dev-team maybe consider to add qubes-official Ubuntu templates just for the LTS versions? :innocent:

Edit: just found out that it may violate Canonicals’ IP or something. :slightly_frowning_face:

The two-year freeze can be annoying, but you can use flatpak, snap, appimage, or alternative repos to get a newer version.

The Debian release cycle isn’t perfect, but it does provide a lot of stability.

Indeed it does.
And once that rabbit was stupidly pulled out of the hat, it’s not so
easy to put back in.
There have been approaches to Canonical on this issue.

An alternative might be to use Mint, which doesn’t so violate - I build
mint templates, and make them available here

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.

Thank you @unman , Mint should do it !
Debian will probably give more stability, but when something more “fresh” is needed, I will probably prefer Mint over Fedora for the reasons discussed in this thread.
Apparently, I knew about your templates but somehow missed the fact that Una = Mint 20.3 :crazy_face: