Qubes OS 4.0 reaches EOL on 2022-08-04

Qubes OS 4.0 is scheduled to reach end-of-life (EOL) on 2022-08-04 — one month from the date of this announcement.

What about patch releases?

The Qubes OS Project uses the semantic versioning standard. Version numbers are written as ... When a major or minor release reaches EOL, all of its patch releases also reach EOL. For example, in this case, when we say that “Qubes 4.0” (without specifying a number) is approaching EOL, we’re specifying a particular minor release, inclusive of all patch releases within it. This means that Qubes 4.0.0, 4.0.1, 4.0.2, 4.0.3, and 4.0.4 will all reach EOL at the same time (on 2022-08-04), since they are all just patch releases of the same minor release.

How are EOL dates determined?

According to our support policy, stable Qubes OS releases are supported for six months after each subsequent major or minor release. This means that Qubes 4.0 reaches EOL six months after Qubes 4.1 was released. Since Qubes 4.1.0 was released on 2022-02-04, Qubes 4.0’s EOL date is six months later, on 2022-08-04.

Fun fact: Qubes 4.0.0 was initially released on 2018-03-28, which means that it will be four years, four months, and one week old when it reaches EOL. That’s the longest support period for a stable Qubes release in our project’s history!

What should I do?

First off, if you’re already using Qubes 4.1, then you don’t have to do anything. This announcement doesn’t affect you.

However, if you’ve stood by the venerable Qubes 4.0 till now, then you’ll want to make sure you upgrade to Qubes 4.1 by 2022-08-04. When you upgrade, though, depends on a few factors. You have several options (in no particular order):

Allow me to explain what I mean by the last option: While we certainly hope to be able to announce the stable 4.1.1 release within the next few weeks, we cannot guarantee that outcome. After all, the entire point of having release candidates is because sometimes major bugs are discovered in builds that were thought to be nearly ready for release. While we don’t expect any, we can never be certain that no such bug will be found.

So, for those looking for a clean installation option, the main advantage of the existing 4.1.0 ISO is that it is already available right now, while there’s a decent chance but no guarantee that the stable 4.1.1 ISO will be ready in time. Meanwhile, the release candidate is intended for testers and adventurous types who don’t mind a bit of risk. The release candidates are not intended for cases in which system reliability is required for important work.

The main disadvantage of the existing 4.1.0 ISO is that it’s quite old by now. It’s missing some security updates (which you should download immediately after installing, if you choose to go that route) and comes with an old Fedora template that has already reached EOL (which you should upgrade immediately after installing or refrain from using in favor of other templates).

If you’re not in any particular hurry to upgrade (and, if you’ve been content to stick with 4.0 until now, then you’re probably not), one strategy is simply to wait until closer to the EOL date, and see whether the stable 4.1.1 ISO arrives in time. If it does, great! You can preform a clean install using that. If it doesn’t, then you haven’t lost anything. You still have the same choices you have right now. Just make sure you to leave yourself enough time to upgrade one way or another!

This is a companion discussion topic for the original entry at https://www.qubes-os.org/news/2022/07/04/qubes-os-4-0-eol-on-2022-08-04/
1 Like


o7 R4.0, you served us well.


While it is great that each option is explained in detail, if you want to do a clean install, all 3 options have downsides. An in-place upgrade might then be the solution, but at least for me that gave me several issues which were fixed with a clean install. Also, potential new users, that don’t have the in-place upgrade option, might be ‘scared off’ because they have multiple options but none is ideal. I propose to possibly extend the EOL date with just a few week if necessary, until 4.1.1 is deemed stable. That will make things easier and give the Qubes OS project a more professional impression to possible new users.

In order to get Qubes to boot my new hardware at all, I installed, I believe, the 2022-06-04 version from here: Index of /qubes/iso/. The official 4.1 wouldn’t work at all.

This doesn’t make me a brave guy willing to try an unstable version…I had no choice!

(I just checked. No, it can’t be that…it had to be a slightly earlier version no longer present as I did the install in late May. It may have had a March date on it.)

So I am inferring that I installed a predecessor of the not-yet-stable 4.1.1.

If I’ve been doing updates since then, do I now have the release candidate installed?

No, release candidate has packages from stable repo while ISO from here Index of /qubes/iso/ has packages from testing repo.

OK…so is my install actually newer than the release candidate?

And does it now have the latest things from the testing repo, or am I “frozen” in time?

Given that the one from the testing repository would work, while 4.1.0 would not, I’m trying to figure out what I should do here. I probably shouldn’t install 4.1.0 (since I know that won’t work) but should I install 4.1.1 either in its current state or when it is released? When will it have whatever it was I needed from the testing repo, to be able to boot?

If you installed Qubes with ISO from here Index of /qubes/iso/ and

  • you have testing updates enabled in Qubes Global Settings and updated your dom0 to the latest updates then you’ll have newer packages compared to release candidate.
  • you have stable updates enabled in Qubes Global Settings and updated your dom0 to the latest updates then you’ll have some packages that are newer compared to release candidate and some packages that are the same version as release candidate. After some time you’ll only have the same packages versions as in release Qubes ISO.

In most cases you need to have a newer kernel that has fixes to the problems you encounter during boot.

It sounds to me like, sticking to “stable updates” basically means that I’m letting the stable world catch up to me. In no way will I ever be behind it, nor will I get further ahead of it. And that’s fine; I have no desire to live on the bleeding edge unless I have to.

I know I need (some subset of?) the testing updates I already have, but I don’t need more than that.

(For anyone else here, concerned about kernels, I am showing 5.18.3-1.fc32 as my kernel)

That’s right.