[qubes-users] Qubes OS 4.0 reaches EOL on 2022-08-04

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?

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.

that is bad news for those who, like me, are stuck with 4.1 install
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

Same here. Only 4.x and 5.4.175 kernel works for me (Dell hardware :frowning: ). 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

Same here. Only 4.x and 5.4.175 kernel works for me (Dell hardware :frowning: ).
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.

Bernhard

> > Same here. Only 4.x and 5.4.175 kernel works for me (Dell hardware :frowning: ).
> > 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.

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.

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.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

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