Qubes OS 4.0 reaches EOL on 2022-08-04
16 views
Skip to first unread message
Andrew David Wong
Jul 5, 2022, 12:16:22 AM7/5/22
to qubes-announce, qubes-devel, qubes-users
Dear Qubes Community,
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 [1] standard. Version
numbers are written as '<major>.<minor>.<patch>'. 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 <patch> 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 [2], stable Qubes OS releases are
supported for six months after each subsequent major or minor release
[3]. 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 [4], 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 [5], 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):
- Perform an in-place upgrade [6] any time between now and 2022-08-04.
- Perform a clean install now using the stable Qubes 4.1.0 ISO [7],
which was published on 2022-02-04 [4].
- Perform a clean install now using the first release candidate for
Qubes 4.1.1 [8].
- Wait to see whether the stable Qubes 4.1.1 ISO is published within the
next month.
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!
[1] https://semver.org/
[2] https://www.qubes-os.org/doc/supported-releases/
[3] https://www.qubes-os.org/doc/version-scheme/
[4] https://www.qubes-os.org/news/2022/02/04/qubes-4-1-0/
[5] https://www.qubes-os.org/news/2018/03/28/qubes-40/
[6] https://www.qubes-os.org/doc/upgrade/4.1/#in-place-upgrade
[7] https://www.qubes-os.org/downloads/#qubes-release-4-1-0
[8] https://www.qubes-os.org/news/2022/06/27/qubes-4-1-1-rc1/
This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/07/04/qubes-os-4-0-eol-on-2022-08-04/
--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org
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 [1] standard. Version
numbers are written as '<major>.<minor>.<patch>'. 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 <patch> 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 [2], stable Qubes OS releases are
supported for six months after each subsequent major or minor release
[3]. 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 [4], 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 [5], 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):
- Perform an in-place upgrade [6] any time between now and 2022-08-04.
- Perform a clean install now using the stable Qubes 4.1.0 ISO [7],
which was published on 2022-02-04 [4].
- Perform a clean install now using the first release candidate for
Qubes 4.1.1 [8].
- Wait to see whether the stable Qubes 4.1.1 ISO is published within the
next month.
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!
[1] https://semver.org/
[2] https://www.qubes-os.org/doc/supported-releases/
[3] https://www.qubes-os.org/doc/version-scheme/
[4] https://www.qubes-os.org/news/2022/02/04/qubes-4-1-0/
[5] https://www.qubes-os.org/news/2018/03/28/qubes-40/
[6] https://www.qubes-os.org/doc/upgrade/4.1/#in-place-upgrade
[7] https://www.qubes-os.org/downloads/#qubes-release-4-1-0
[8] https://www.qubes-os.org/news/2022/06/27/qubes-4-1-1-rc1/
This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/07/04/qubes-os-4-0-eol-on-2022-08-04/
--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org
Bernhard
Jul 6, 2022, 3:19:21 AM7/6/22
to qubes-users, qubes-announce, qubes-devel, a...@qubes-os.org, de...@invisiblethingslab.com, marm...@invisiblethingslab.com
> Dear Qubes Community,
>
> Qubes OS 4.0 is scheduled to reach end-of-life (EOL) on 2022-08-04 --
> one month from the date of this announcement.
problems for >1 year. My computer freezes while install.
I have asked many times how to include (e.g. by unpacking & repacking
the ISO) an additional 4.19 LTS kernel in the installer and boot it:
that would probably do the job. Alas, I got no help on this, yet. So I
launch my question again.
best, Bernhard
Peter Palensky
Jul 6, 2022, 3:27:12 AM7/6/22
to qubes-users
Same here. Only 4.x and 5.4.175 kernel works for me (Dell hardware :-( ). I am afraid of losing that when updating...
Demi Marie Obenour
Jul 6, 2022, 4:02:45 AM7/6/22
to Peter Palensky, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Wed, Jul 06, 2022 at 12:27:11AM -0700, Peter Palensky wrote:
> Same here. Only 4.x and 5.4.175 kernel works for me (Dell hardware :-( ).
> I am afraid of losing that when updating...
Yeah, this really needs to be addressed. Would it be possible to bisect
between kernels 5.4.x and 5.10.x to see what went wrong? The relevant
git tags are signed by Linus Torvalds or Greg Kroah-Hartman, and their
public keys are in the (signed) qubes-linux-kernel git repository.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLFQaAACgkQsoi1X/+c
IsH1uw/+PL5e6IKGZ/MVM48DO37xNFQdegP47fobmMV7xgK3sK4LQCNY8Mk38mEd
PpAaMq4r2YezSYmh3CBO/e/i+ccx3h9IsyeUtXLdiGM3FNVAmVZS4ARMiQTUs9Qc
B+BG0YpohSNedGc/exjKI3Sk92U/FTghe364ySFqUL4+U8zzk1eO2Gd5utLLfcBP
TskTB9LWEuHocvjhT0mNASe0+RVJrek00F3TYMpDpLJlJATWRjjWxsChNAK8bpzu
QMuqkDjWGvBJco6a0AwZizyJWjGU7gpmv1AWyvZPLbSk/1v4M6B82n9H/vEflUv5
QdwIFrMy/w0ePUnJ6XAp1Y35uB7K9IOV/KFdMFPEgROQfjQ2sR1G3bjLhbAiKl2B
TNwnPeo7cafeDSHxtnmAQGfiGW+7xRnZEvNyUBYf2fB6c1bxZXyaaQBSYvrkvYo1
iEydRrmOgvG8OhMvXvRQ2nhQRixlzbz/qLc/PmLkMaZhzTsiu5h8A4DEPeFUunXP
RtctcT/eG91I/5MoM8i4sOk1obyPBcbQIvFJKxEKz1IRrxsrs+j1vxyBOdRICrHb
sgm/0+izSNNNmI3n7igukvd6LlK0VSGVobx1WkMTlhzbRuthvizDZlUV/aKmi6XW
pQktXACFcSIep46DWTeH0InxhlQdOHSL8VKtwyxOE6gKlgDhPJA=
=8ULj
-----END PGP SIGNATURE-----
Hash: SHA512
On Wed, Jul 06, 2022 at 12:27:11AM -0700, Peter Palensky wrote:
> Same here. Only 4.x and 5.4.175 kernel works for me (Dell hardware :-( ).
> I am afraid of losing that when updating...
between kernels 5.4.x and 5.10.x to see what went wrong? The relevant
git tags are signed by Linus Torvalds or Greg Kroah-Hartman, and their
public keys are in the (signed) qubes-linux-kernel git repository.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLFQaAACgkQsoi1X/+c
IsH1uw/+PL5e6IKGZ/MVM48DO37xNFQdegP47fobmMV7xgK3sK4LQCNY8Mk38mEd
PpAaMq4r2YezSYmh3CBO/e/i+ccx3h9IsyeUtXLdiGM3FNVAmVZS4ARMiQTUs9Qc
B+BG0YpohSNedGc/exjKI3Sk92U/FTghe364ySFqUL4+U8zzk1eO2Gd5utLLfcBP
TskTB9LWEuHocvjhT0mNASe0+RVJrek00F3TYMpDpLJlJATWRjjWxsChNAK8bpzu
QMuqkDjWGvBJco6a0AwZizyJWjGU7gpmv1AWyvZPLbSk/1v4M6B82n9H/vEflUv5
QdwIFrMy/w0ePUnJ6XAp1Y35uB7K9IOV/KFdMFPEgROQfjQ2sR1G3bjLhbAiKl2B
TNwnPeo7cafeDSHxtnmAQGfiGW+7xRnZEvNyUBYf2fB6c1bxZXyaaQBSYvrkvYo1
iEydRrmOgvG8OhMvXvRQ2nhQRixlzbz/qLc/PmLkMaZhzTsiu5h8A4DEPeFUunXP
RtctcT/eG91I/5MoM8i4sOk1obyPBcbQIvFJKxEKz1IRrxsrs+j1vxyBOdRICrHb
sgm/0+izSNNNmI3n7igukvd6LlK0VSGVobx1WkMTlhzbRuthvizDZlUV/aKmi6XW
pQktXACFcSIep46DWTeH0InxhlQdOHSL8VKtwyxOE6gKlgDhPJA=
=8ULj
-----END PGP SIGNATURE-----
Bernhard
Jul 6, 2022, 5:15:56 AM7/6/22
to qubes...@googlegroups.com
On 7/6/22 10:02, Demi Marie Obenour wrote:
> On Wed, Jul 06, 2022 at 12:27:11AM -0700, Peter Palensky wrote:
>> Same here. Only 4.x and 5.4.175 kernel works for me (Dell hardware :-( ).
>> I am afraid of losing that when updating...
>
You see the 4.1 ISO contains an "extrakernels" folder (empty). The
> On Wed, Jul 06, 2022 at 12:27:11AM -0700, Peter Palensky wrote:
>> Same here. Only 4.x and 5.4.175 kernel works for me (Dell hardware :-( ).
>> I am afraid of losing that when updating...
>
question is: which files go there, and how modify the iso-boot procedure
so that one were allowed to select the kernel. Sounds like a reasonable
feature, no?
I failed on this: iso's are complicated, linux boot is complicated (and
therefore abstracted out into software).
> Yeah, this really needs to be addressed. Would it be possible to
> bisect
> between kernels 5.4.x and 5.10.x to see what went wrong? The relevant
> git tags are signed by Linus Torvalds or Greg Kroah-Hartman, and their
> public keys are in the (signed) qubes-linux-kernel git repository.>
unstable. I expect no gain from this! I guess adding the 4.19
(extra)kernel to the iso is the least painful way to go.
Bernhard
Demi Marie Obenour
Jul 6, 2022, 7:31:06 AM7/6/22
to Bernhard, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
On Wed, Jul 06, 2022 at 11:15:45AM +0200, Bernhard wrote:
> On 7/6/22 10:02, Demi Marie Obenour wrote:
> > On Wed, Jul 06, 2022 at 12:27:11AM -0700, Peter Palensky wrote:
> > > Same here. Only 4.x and 5.4.175 kernel works for me (Dell hardware :-( ).
> > > I am afraid of losing that when updating...
> >
>
> You see the 4.1 ISO contains an "extrakernels" folder (empty). The
> question is: which files go there, and how modify the iso-boot procedure
> so that one were allowed to select the kernel. Sounds like a reasonable
> feature, no?
It does.
> On 7/6/22 10:02, Demi Marie Obenour wrote:
> > On Wed, Jul 06, 2022 at 12:27:11AM -0700, Peter Palensky wrote:
> > > Same here. Only 4.x and 5.4.175 kernel works for me (Dell hardware :-( ).
> > > I am afraid of losing that when updating...
> >
>
> You see the 4.1 ISO contains an "extrakernels" folder (empty). The
> question is: which files go there, and how modify the iso-boot procedure
> so that one were allowed to select the kernel. Sounds like a reasonable
> feature, no?
> I failed on this: iso's are complicated, linux boot is complicated (and
> therefore abstracted out into software).
>
> > Yeah, this really needs to be addressed. Would it be possible to
> > bisect
> > between kernels 5.4.x and 5.10.x to see what went wrong? The relevant
> > git tags are signed by Linus Torvalds or Greg Kroah-Hartman, and their
> > public keys are in the (signed) qubes-linux-kernel git repository.>
>
> but as far as my dell hardware is concerned, 5.4 kernels are already
> unstable. I expect no gain from this! I guess adding the 4.19
> (extra)kernel to the iso is the least painful way to go.
The problem with staying on 4.19 is that eventually it will lose support
upstream. Qubes is not RHEL, and we can't support an old kernel
forever. That you cannot use your hardware on Linux 5.4+ is a bug, but
without access to the hardware in question there is no way (that I am
aware of) to figure out what the bug is so that it can be fixed.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLFcnUACgkQsoi1X/+c
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
IsGtZhAAyPLPFFD4mpyhPXy0BuKtUuqSqXw/TBp3TvLCp1YgAS/BbREd9V4k8iDb
h3JGz+WmrymWRtoTfv+3Ia2V7MojMMColSFoMwSJblIS+ccg9BRokLajGIFD74RC
p3+ZZX44fw5U7IZKB8Wf+g0izcI8lQAHgQFCBE9WDMELYPDd4SfDx4TTcz4pTxSy
i6qJO9bDDtt48nMP/8QouxbMcxTU/QUMibjq4YArRdITJ99+fSCa99P1wd0mvSP2
wg1WntaV5Qu/dUkcb34gEu1d0JlxD10G6KSnPYn1F+C6jXKeY143njU9EP+e+gi5
tpFfoZK/cdt6QnEO2fs3KppDxSR5cOza1lgPz2keVcf/oR/SQxia76GBe4qJ+zZg
a79uBn8AfAQ0WOtJ8dk+ElF09ZLJxDNmnByg7BV0DtocOcmMPeqpa6JF4p3jWSmf
+0xZdm0Pq1h+3gxcCG/AqkZ2n8YkCxvDBL54t4g4RrFF+KL8Rhop73w66uAr1sYR
uwu1yH3Yym5o+stCvT2DIRDTAO13MqwR4FUzuFRWINMYjFtmLHkzePyzZ31DPxWv
GvULyMPDm6yL6wTaTg7sHYQhksQhNkQwBm75yn8++U1eFf8GkH5HU1uoJN5Ng4LN
+DqbCxHrxJab/Fg+DG/I+VGeRT0wJPI7RwtOKMAFV9nShnSh/7E=
=3fn/
-----END PGP SIGNATURE-----
Bernhard
Jul 13, 2022, 9:22:56 AM7/13/22
to qubes...@googlegroups.com, marm...@invisiblethingslab.com, a...@qubes-os.org
Dear Demi Marie
> What about between bisecting between 4.19 and 5.4?
That sounds interesting. I am willing to test.
> The problem with staying on 4.19 is that eventually it will lose support
> upstream. Qubes is not RHEL, and we can't support an old kernel
> forever. That you cannot use your hardware on Linux 5.4+ is a bug, but
> without access to the hardware in question there is no way (that I am
> aware of) to figure out what the bug is so that it can be fixed.
of course it is not a solution: it is a continued workaround, that
allows to install 4.1 with an old kernel without being cut off other
updates, for the time that the real problem takes to solve. *That alone*
is helpful. Because what do I do next? Remove qubes 4.0 and install
vanilla debian instead? Stay on unsupported Q4.0? Both seem worse than
using the newest qubes on an old kernel: surely, it's not forever.
I would really appreciate help of the dev's on that single point: an
explication of how to sneak in an extrakernel in the iso. They do not
need to explain iso packing & unpacking (that is easy), only how to
twiggle the iso boot procedure.
Thank you so much! Bernhard
> What about between bisecting between 4.19 and 5.4?
> The problem with staying on 4.19 is that eventually it will lose support
> upstream. Qubes is not RHEL, and we can't support an old kernel
> forever. That you cannot use your hardware on Linux 5.4+ is a bug, but
> without access to the hardware in question there is no way (that I am
> aware of) to figure out what the bug is so that it can be fixed.
allows to install 4.1 with an old kernel without being cut off other
updates, for the time that the real problem takes to solve. *That alone*
is helpful. Because what do I do next? Remove qubes 4.0 and install
vanilla debian instead? Stay on unsupported Q4.0? Both seem worse than
using the newest qubes on an old kernel: surely, it's not forever.
I would really appreciate help of the dev's on that single point: an
explication of how to sneak in an extrakernel in the iso. They do not
need to explain iso packing & unpacking (that is easy), only how to
twiggle the iso boot procedure.
Thank you so much! Bernhard
Reply all
Reply to author
Forward
0 new messages