The Fedora release cycle is too short

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:

More transparent naming would help, no doubt, but I tend to think in
terms of the names.
I’ll make the Mint names consistent with other templates.

I am sure that Qubes Team has been suggested many times and decided not doing so on purpose, but I wonder if Qubes OS would be built on AlmaLinux or other RHEL downstreams.

An obvious downside of RHEL downstreams is theirs old(er) applications though they can remedy with Flatpak, Snap or such. Another disadvantage may be old(er) Xen if they are used for Dom0.

FYI (if you meant having dom0 use a rhel clone rather than fedora): quoting @marmarek’s reply to the same question:

That isn’t really helping - RHEL indeed is provide stable support long time, and they do that by supporting extremely limited package set. @fepitre tried to port dom0 to CentOS 8 before, and even when adding EPEL repositories many required packages were missing (see #1919 (comment)). So, we’d get longer support for base packages at the price of maintaining a lot more packages ourselves.

Now - that’s a bit old, maybe things have changed since then…


Thank you, @taradiddles ! Yes, that is another problem we will face if Dom0 is based on RHEL downstreams.

@unman I installed the Una template from your link and wanted to use Qubes native update tool (salt?) to update Una template. I can see the template in the gui and ask it to update but the circle keeps turning and nothing else happens . (is updating this way even possible? is it just something I missed?)

:EDIT never mind all that, it seems I just needed to wait long enough (veeeery long :upside_down_face:)

@unman just in case you don’t see the edit.

(@redmind the post edits only make it to the mail-based version of the thread if made within a few minutes of the post being created. So it might happen that folks using the forum via the mail sometimes don’t see the edits. Because of its content I assume yours came a bit later than that a few minutes :stuck_out_tongue:)

1 Like

I agree, and have switch over to debian for templates for any qubes I need to heavily customize for development. However, I’m out of luck for dom0 and I don’t believe qubes-os developers have time to follow and backport security issues for every package which could potentially be installed from fedora into dom0.

The current stable dom0 is fedora 32…and it no longer receives security updates from fedora. While Qubes-os tries to backport security patches…fedora 32 is a huge ecosystem and I don’t believe qubes-os can adequately maintain every package. While every package is not needed for dom0, the folks maintaining qubes-os don’t know what extra packages users installed from the fc32 repositories.

For example, I switch from Xfce to KDE in dom0…and then I take lots of screenshots so I install spectacle. Does the Qubes-OS developers really have time to pay attention to any security backports for spectacle. I don’t think so and this is why I think having out of date dom0 fedora releases is a security nightmare. If there happens to be a security issue in an older version of spectacle installed in fc32 not present in newer supported fedora releases, how will the Qubes team even know spectacle needs to be backported? And spectale is just a silly example of thousands of packages users can install and may need in dom0 from fc32.

I really wish dom0 was kept up to date with vendor security patches as I don’t think its possible for qubes keep up with and to backport security patches for every available package from the vendor which users may install in dom0.

Thankfully I’m running Qubes 4.2a and Fedora 37 in dom0…but fc37 will reach EOL shortly and then I need to pay attention to what I’ve installed in dom0 from fedora 37 which the folks at Qubes-OS might not be following for any security patches.

Note on dom0 and EOL

Dom0 is isolated from domUs. DomUs can access only a few interfaces, such as Xen, device backends (in the dom0 kernel and in other VMs, such as the NetVM), and Qubes tools (gui-daemon, qrexec-daemon, etc.). These components are security-critical, and we provide updates for all of them (when necessary), regardless of the support status of the base distribution. For this reason, we consider it safe to continue using a given base distribution in dom0 even after it has reached end-of-life (EOL).

Supported releases | Qubes OS

1 Like

This was discussed numerous times.