Qubes 3.2 Kernel 4.12

[Epitre]

Hi,

For those who want to try the kernel 4.12, I put a devel-4.12 branch on my repo (https://github.com/fepitre/qubes-linux-kernel) following closely the work and the advices of Reg Tiangha (https://github.com/rtiangha/qubes-linux-kernel) for the 4.11 branch. Until a more viable solution, I uploaded signed RPM on sourceforge: https://sourceforge.net/projects/qubes-linux-kernel/files/?source=navbar

It should help people who have latest AMD and INTEL CPU platforms and also NVIDIA cards.

I have already prepared spins of Qubes 3.2 and 4.0rc1 with kernel-4.12 but I need to discuss with Qubes team how to release it so stay tuned.

Best,

[Epitre]

I added the files for the latest version 4.12.8 including the XSA 229 patch from R. Tiangha repo. Here are the links:

kernel: https://sourceforge.net/projects/qubes-linux-kernel/files/kernel-4.12.8-20.pvops.qubes.x86_64.rpm/download
kernel-qubes-vm: https://sourceforge.net/projects/qubes-linux-kernel/files/kernel-qubes-vm-4.12.8-20.pvops.qubes.x86_64.rpm/download
kernel-devel: https://sourceforge.net/projects/qubes-linux-kernel/files/kernel-devel-4.12.8-20.pvops.qubes.x86_64.rpm/download

[Reg Tiangha]

FYI, I haven't tested it yet on 4.12 myself, but there was a round of
kernel updates yesterday that included the XSA 229 patch into 4.4.84 and
4.9.45; I'd assume it's the same with 4.12.9 but it'd be worthwhile
checking (you'll know if it's included if a prompt comes during the
patching phase of the build). If so, then you'll need to remove it again.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I think it's a good idea to talk here about including more recent
kernels in mainline Qubes OS. Generally we have a policy for including
only "longterm" kernels. Mostly because our release cycle is much longer
than the kernel one, and in some cases new kernel "major" version may
break some things. And also require more time for reviewing config
changes.

The simplest thing to do would be to put new kernel packages into the
same repository and let user choose what to use. But there is a problem
with this: yum/dnf make it hard to handle multiple versions of the same
package. The default setting is to keep 3 latest kernel packages. This
make it impossible to stay with, say 4.9, while there are already 3 or
more new packages from 4.12 line.

I see a few options for this problem:

1. Use "unstable" repository for non-longterm kernels. We've done this
before, for 4.8 kernels. The problem with this approach is that unstable
repository contains unstable packages. This is a place where we put
some very experimental packages. Admittedly, recently this repository
rarely receive any packages. Or create new repository specifically for
non-longterm kernels.

2. Have non-longterm kernels packaged with different package name than
"kernel" (and "kernel-qubes-vm"). For example "kernel-4.12" as a package
name - so a full package name with version would be
"kernel-4.12-4.12.9-1". Basically a Debian approach.

3. Terminate the policy of using only longterm support kernels. This
require some more work on reviewing config changes and more testing
(probably longer time in current-testing when uploading new major
version). For this to happen, we'd prefer to have someone tracking
kernel changes - IIUC Reg Tiangha already do this anyway.

What do you think?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZoHd5AAoJENuP0xzK19csd6cH/isHp8F8BOpmcKj3djkxYtQv
luVGYaCGhfNHsbhPpnki7fAUdCIvz1ao+Rxs14Fhsrx1zHoQNTqhWWs7s5D9BoUX
7WkMB9JXa8xNyb+HmhVpetMSnG6fxj2bfuvXhZSfvWyPUYXUbU2Dd4UHjVIPorjc
QyRqJ+sG6IxMr5LEq02SNkbSd6+6TLq1V6j3UY+HRv4abZG62ZXI4wIXy2AfTAH+
1mw88wJaHzk9yVunlAhZA5w6JV/q7seu4ddhNGcTZ9FLGeCIqK3uedaC5ou45YEm
v7hfawEQeKa8e0qpyQzdtF4hIHL1LKKcWhzsgWHbnc3gB+1c5r9YOoW7UXDanTw=
=KGQL
-----END PGP SIGNATURE-----

[Epitre]

Hi,

Indeed Reg, I saw it this morning, in kernel-4.12.9, the XSA 229 patch has been included and I will update my repo. Thank you.

For the three possibles solutions of non-long term kernels you proposed Marek:

1 - Adding latest kernels in "unstable" repository is a good idea although it may be "risky". For example, if someone enable the whole repository and update everything. For that we would provide a short documentation for only enable the unstable repository for updating only the latest kernels. A solution to this would be, as you proposed, to create a separate repository for latest kernels.

2 - With respect to the first solution, some people may encounter problems between kernel versions, as it has been the case for example between branch 4.4 and 4.9 (e.g. NVIDIA cards...). So choosing a specific name, kernel-4.9, ..., kernel-4.12 as a basename for staying updated to a specific branch is currently, in my opinion, a safer idea that the first solution. Also, this way would keep the long term, stable and mainline kernels.

3 - In my opinion, this is the best solution to have a mainstream in kernel updates and also to solve the problem of having trouble between versions and staying a long time in a current branch such as the 4.9, notably with respect to newer hardware. Reg is doing a great job in tracking kernel changes and I would propose myself to help him in this way (e.g. track, test, build, etc.)

In summary, the last solution could be a major step in Qubes development and evolution so having at the first place, a separate repository for latest stable kernel to prepare the further evolution of Qubes is a good compromise, preventing possible user errors in updating the unstable repository. Also with respect to the second solution, it is probably less work to do.

[Reg Tiangha]

On 2017-08-25 1:16 PM, Marek Marczykowski-Górecki wrote:

> I think it's a good idea to talk here about including more recent
> kernels in mainline Qubes OS. Generally we have a policy for including
> only "longterm" kernels. Mostly because our release cycle is much longer
> than the kernel one, and in some cases new kernel "major" version may
> break some things. And also require more time for reviewing config
> changes.
>
>
>

I'm not sure if all of the packages in unstable have already been
superseded by newer packages by now, but if so, in theory there'd be no
problem is using it to host newer kernels.

If not, how about implementing a backports repository?

Newer kernels that aren't LTS could be put in there and a special ISO
that has the backports repository enabled by default could be made (for
those with hardware so new that they can't boot/install with the
standard ISO) and that could solve most of the hardware problems.

And I know that the QubesOS project doesn't really want to get into the
business of backporting system packages, but it seems to me that's more
for a capacity reason, rather than a technical reason. If the situation
in the future changes where there's more developer funding or more
capacity through reliable volunteers, maybe that repository could also
be used to backport a few more select packages in the future if the need
arises; for example, security updates to luks or glibc that are no
longer supported by Fedora, gcc updates to keep the kernel compile
environment in dom0 consistent across major Qubes releases, or fixing
pesky things like that unfinshed version of rpm that was pushed out in
FC23 and upgrading that to a complete version. I can also foresee the
day that a newer X may need to be backported to compliment a newer
kernel; some people are reporting higher X usage with the 4.9 kernel and
I wonder if pairing it with a slightly newer X version would solve it,
although I don't know if that X usage is coming from dom0 or from VMs
(if it's VMs then there'd be no point).

Anyway, I like the idea of having an LTS kernel option somehow, but also
have the ability to use a newer kernel if need be. So my suggestion
would be to have a choice of two ISOs with different kernels that people
can download and install to suit their hardware installation needs, and
have newer kernels in a separate repository that a user could opt into
later on if need be.

We'd just have to make sure there's enough capacity on this end to keep
up with porting patches, updating config options, and testing, but I
think there's enough people here who know how to compile a kernel now
that maybe some of them could help out with those sorts of efforts.
Might be worth putting a call out to see who might be interested in
helping with that and it'd be a great way for people to get involved and
contribute back to the project if they can't donate monetary funds.

Those are my thoughts.

[Holger Levsen]

On Fri, Aug 25, 2017 at 09:16:07PM +0200, Marek Marczykowski-Górecki wrote:
> I see a few options for this problem:
>
> 1. Use "unstable" repository for non-longterm kernels. We've done this

> before, for 4.8 kernels. [...] Or create new repository specifically for
> non-longterm kernels.

I like 1b much better than 1 :)

> 2. Have non-longterm kernels packaged with different package name than

> "kernel" (and "kernel-qubes-vm").[...]

works for me too.

> 3. Terminate the policy of using only longterm support kernels.

probably the least preferred option by me, unless you get a lot of help.


--
cheers,
Holger

[cez...@gmail.com]

Quote Reg Tiangha : "Anyway, I like the idea of having an LTS kernel option somehow, but also

have the ability to use a newer kernel if need be. So my suggestion
would be to have a choice of two ISOs with different kernels that people
can download and install to suit their hardware installation needs, and
have newer kernels in a separate repository that a user could opt into
later on if need be.

"

This I think is a really good idea, I will echo that suggestion.
Right now in particular, due to the higher than usual demand on newer kernels, due to the market being flooded with new hardware, such as Ryzen, etc.
Even if just a temporarily solution, it would be nice, untill we reach a more normal hardware market again.

Alternatively, perhaps a detailed guide for users how to compile Qubes with the new kernel themselves, which is userfriendly for more non-technical people. Not sure if that is possible to make without too much detail overhead though.