MX Linux Forum

Posted: **Wed Mar 28, 2018 1:13 pm**

We now have a newer backported Debian 4.15.11 kernel in the test repository for those that wish to test the latest version. As usual, it presents two version numbers:

Code: Select all

$ uname -a
Linux mx1 4.15.0-2-amd64 #1 SMP Debian 4.15.11-1~mx17+1 (2018-03-27) x86_64 GNU/Linux

It will not automatically upgrade over or replace any other kernels. This is by design. Changes from the Debian version include bumping the kernel context switch frequency from 250 to 1000 Hz, adding libelf-dev as a build-dependency for the headers, and other changes to make it work with our gcc-6 instead of gcc-7.

Posted: **Wed Mar 28, 2018 2:24 pm**

thumbs up

Posted: **Sat May 05, 2018 5:03 pm**

We now have a 4.15.0-1 (4.15.17) backported kernel that will upgrade in place over the stock 4.15.4 version in MX 17.1, plus a new 4.16.0-1 (4.16.5) backported kernel, both in the test repo. The easiest way to upgrade or install the new kernel is to use the test repo feature in the MX package installer and search for 4.15.0-1 or 4.16.0-1, and install the image and the headers package for your flavor. 32-bit users most likely will be using the pae kernel.

Users of the proprietary nvidia-driver package need to update that from the test repo for the 4.16 kernel, also, otherwise it won't work and you'll get no GUI when booting that kernel.

Posted: **Mon Jun 04, 2018 3:02 pm**

The 4.16 backported kernel has been updated to 4.16.0-2 (4.16.12), backported from the Sid sources. This will not be seen as an upgrade to any installed kernel, and must be installed manually. One way is to add the test repo in Synaptic, and search for "4.16.0-2", then install the linux-image and linux-headers packages for your architecture. Note that 64-bit users will also see the two 32-bit kernels, as well as an extra "rt" realtime kernel; 32-bit users will see pae and nonpae versions, so make like Indiana Jones and choose wisely.

Posted: **Sun Jun 10, 2018 3:20 pm**

We now have added the 4.17.0 kernel to the test repo, built using upstream's rc7 version as a template. Included are amd64, i386-pae, and i386 versions, but the realtime "rt" versions were disabled for this build. The kernel timer frequency is also bumped from 250 to 1000 Hz.

The major dkms driver packages will build with this new kernel as long as you have those updated from the test repo. However, virtualbox-guest-dkms builds will fail, so that puts a crimp to any plans to test the kernel in Virtualbox guests.

Posted: **Mon Jun 11, 2018 12:40 am**

can someone check nftables with kernel 4.17.0?

Code: Select all

lsmod | grep '^nf'

edit:
ps:
reason i ask is because nftables are missing from kernel 4.17.0 at config.
may not be critical, iptables may preferred by dev(s) to drop nftables.

Posted: **Tue Jun 12, 2018 8:50 pm**

This is what shows up.

Code: Select all

lsmod | grep '^nf'
nfsd                  413696  2
nfs_acl                16384  1 nfsd
nfs                   311296  0

It also appears that the Debian kernel does not enable the new built-in Virtual Box guest support, though the Liquorix 4.16 kernel does. That might have been a way to work around the guest dkms failures. Maybe I'll copy over the config and rebuild it again.

Posted: **Wed Jun 13, 2018 4:25 am**

ok, thanks.
tried compile kernel 4.17.1, nftables still are missing from source, seem plausible dev(s) did something.
compiled latest kernel 4.16.15, no error(s) or missing module(s).
(except for dkms vb-guest, need to remove n reinstall with option --force)

Code: Select all

$ uname -a
Linux mx 4.16.15 #1 SMP PREEMPT Tue Jun 12 17:16:52 +08 2018 x86_64 GNU/Linux

Code: Select all

$ dkms status
broadcom-sta, 6.30.223.271, 4.16.15, x86_64: installed
ndiswrapper, 1.61, 4.16.15, x86_64: installed
virtualbox, 5.2.12, 4.16.15, x86_64: installed
virtualbox-guest, 5.2.12, 4.16.15, x86_64: installed (original_module exists)

Code: Select all

$ lsmod | grep '^nf'
nfsd                  352256  2
nfs_acl                16384  1 nfsd
nfs                   282624  0
nf_reject_ipv6         16384  1 ip6t_REJECT
nf_conntrack_ipv6      16384  7
nf_defrag_ipv6         32768  1 nf_conntrack_ipv6
nf_reject_ipv4         16384  1 ipt_REJECT
nf_conntrack_ipv4      16384  7
nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
nf_conntrack_netbios_ns    16384  0
nf_conntrack_broadcast    16384  1 nf_conntrack_netbios_ns
nf_nat_ftp             16384  0
nf_nat                 32768  1 nf_nat_ftp
nf_conntrack_ftp       16384  1 nf_nat_ftp
nf_conntrack          131072  8 nf_conntrack_ipv6,nf_conntrack_ftp,nf_conntrack_ipv4,nf_conntrack_broadcast,nf_nat_ftp,nf_conntrack_netbios_ns,xt_conntrack,nf_nat

Posted: **Wed Jun 13, 2018 5:17 pm**

Stevo wrote: Sun Jun 10, 2018 3:20 pm We now have added the 4.17.0 kernel to the test repo, built using upstream's rc7 version as a template.

I've been using it for the last day or two and everything's working fine - finally the AMDGPU drivers allow me to have HDMI audio!

Posted: **Wed Jun 13, 2018 5:49 pm**

sacules wrote: Wed Jun 13, 2018 5:17 pm
Stevo wrote: Sun Jun 10, 2018 3:20 pm We now have added the 4.17.0 kernel to the test repo, built using upstream's rc7 version as a template.
I've been using it for the last day or two and everything's working fine - finally the AMDGPU drivers allow me to have HDMI audio!

Much improved amdgpu drivers were advertised for the 4.17 kernels, for sure!

Posted: **Wed Jun 13, 2018 11:56 pm**

Indeed. However, I can't use VirtualBox as a host, I get the following error:

Code: Select all

Kernel driver not installed (rc=-1908)

The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. Please reinstall virtualbox-dkms package and load the kernel module by executing

'modprobe vboxdrv'

as root.

where: suplibOsInit what: 3 VERR_VM_DRIVER_NOT_INSTALLED (-1908) - The support driver is not installed. On linux, open returned ENOENT.

Posted: **Thu Jun 14, 2018 1:09 am**

The 4.17 kernel requires an upgrade of Vbox to 5.2.12, which can be installed from the test repo. You'll also need to install the 4.17 linux-headers for your kernel.

Posted: **Thu Jun 14, 2018 7:52 am**

I installed the 4.17 kernel. I thought the amdgpu driver was installed by default with this kernel. However it was not on my system. I have forgotten how to enable the driver. Can you guide me?

Posted: **Thu Jun 14, 2018 4:08 pm**

The amdgpu driver actually is in two parts; one is built into the kernel, and the other is xserver-xorg-video-amdgpu, which should already be installed. However, I don't have any hardware to test how the stock Debian xserver-driver works with the new kernel, but sacules' post seems to show that it works and has improved functionality. I'm not sure if you need to use a config file to switch from radeon to amdgpu, but kmathern would no doubt know. What are you showing with "inxi -G" now?

Posted: **Thu Jun 14, 2018 7:07 pm**

Code: Select all

Graphics:  Card-1: AMD Kaveri [Radeon R7 Graphics] driver: radeon v: kernel 
           Display: x11 server: X.Org 1.19.2 driver: ati,radeon unloaded: fbdev,modesetting,vesa 
           resolution: 1920x1080~60Hz 
           OpenGL: renderer: Gallium 0.4 on AMD KAVERI (DRM 2.50.0 / 4.17.0-1-amd64 LLVM 3.9.1) 
           v: 4.3 Mesa 13.0.6

I recall enabling it with an earlier kernel but forgot the steps.

Posted: **Thu Jun 14, 2018 7:38 pm**

Do either of the two ways in the answers here seem familiar? https://askubuntu.com/questions/927601/ ... o-i-change

My preference would be to try blacklisting the radeon driver first.

Posted: **Thu Jun 14, 2018 7:48 pm**

neither seem familiar. I tried the modprobe solution but got a failure to find the added line.

I thought there was another way to another way to blacklist the radeon driver without editing /etc/default grub,

Tried another method to blacklist the radeon driver. I edited /etc/modeprobe.d by adding a blacklist.conf file and adding "blacklist radeon" to that file. Tat had no effect.

Posted: **Thu Jun 14, 2018 9:24 pm**

I haven't been able to get the amdgpu driver to work on my Kabini GPU with 4.16 or 4.17 kernels.

I'm familiar with the boot parameters mentioned in Stevo's askubuntu link (radeon.si_support=*, radeon.cik_support=*, amdgpu.si_support=*, amdgpu.cik_support=*), and they used to work okay for me with 4.13, 4.14 & 4.15 kernels but so far not 4.16 or 4.17.

A /etc/modprode.d file like the one shown below (I called it 'amdgpu_si_cik.conf') also used to work for me with 4.13, 4.14 & 4.15 kernels.

Code: Select all

##################################################################
# Uncomment lines below to enable optional amdgpu driver support #
# for Southern Islands (si) and Sea Islands (cik) GPUs with 4.13 #
# series kernels and higher.                                     #
#                                                                #
# GCN generation 1 / Southern Islands chipsets:                  #
# CAPE VERDE, PITCAIRN, TAHITI, OLAND, HAINAN                    #
#                                                                #
# GCN generation 2 / Sea Islands chipsets:                       #
# BONAIRE, KABINI, KAVERI, HAWAII, MULLINS                       #
##################################################################

#options radeon si_support=0 cik_support=0
#options amdgpu si_support=1 cik_support=1

Posted: **Fri Jun 15, 2018 12:42 pm**

Stevo wrote: Thu Jun 14, 2018 1:09 am The 4.17 kernel requires an upgrade of Vbox to 5.2.12, which can be installed from the test repo. You'll also need to install the 4.17 linux-headers for your kernel.

Already had the headers, will try upgrading Vbox.

richb wrote: Thu Jun 14, 2018 7:07 pm

Code: Select all

Graphics:  Card-1: AMD Kaveri [Radeon R7 Graphics] driver: radeon v: kernel 
           Display: x11 server: X.Org 1.19.2 driver: ati,radeon unloaded: fbdev,modesetting,vesa 
           resolution: 1920x1080~60Hz 
           OpenGL: renderer: Gallium 0.4 on AMD KAVERI (DRM 2.50.0 / 4.17.0-1-amd64 LLVM 3.9.1) 
           v: 4.3 Mesa 13.0.6

I recall enabling it with an earlier kernel but forgot the steps.

I had a similar issue some months ago and solved it by upgrading the mesa drivers to the last version, which you can find in the test repos.

Posted: **Fri Jun 15, 2018 1:38 pm**

sacules wrote: Fri Jun 15, 2018 12:42 pm
Stevo wrote: Thu Jun 14, 2018 1:09 am The 4.17 kernel requires an upgrade of Vbox to 5.2.12, which can be installed from the test repo. You'll also need to install the 4.17 linux-headers for your kernel.
Already had the headers, will try upgrading Vbox.
richb wrote: Thu Jun 14, 2018 7:07 pm
Code: Select all
Graphics:  Card-1: AMD Kaveri [Radeon R7 Graphics] driver: radeon v: kernel 
           Display: x11 server: X.Org 1.19.2 driver: ati,radeon unloaded: fbdev,modesetting,vesa 
           resolution: 1920x1080~60Hz 
           OpenGL: renderer: Gallium 0.4 on AMD KAVERI (DRM 2.50.0 / 4.17.0-1-amd64 LLVM 3.9.1) 
           v: 4.3 Mesa 13.0.6 
I recall enabling it with an earlier kernel but forgot the steps.
I had a similar issue some months ago and solved it by upgrading the mesa drivers to the last version, which you can find in the test repos.

Stretch-backports has a newer mesa, or we currently have 18.0.4 in a separate experimental repo. I was a bit leery of having it in the test repo, since there are some that upgrade everything from there in one fell swoop.

Posted: **Fri Jun 15, 2018 1:39 pm**

Stevo wrote: Fri Jun 15, 2018 1:38 pm
sacules wrote: Fri Jun 15, 2018 12:42 pm
Stevo wrote: Thu Jun 14, 2018 1:09 am The 4.17 kernel requires an upgrade of Vbox to 5.2.12, which can be installed from the test repo. You'll also need to install the 4.17 linux-headers for your kernel.
Already had the headers, will try upgrading Vbox.
richb wrote: Thu Jun 14, 2018 7:07 pm
Code: Select all
Graphics:  Card-1: AMD Kaveri [Radeon R7 Graphics] driver: radeon v: kernel 
           Display: x11 server: X.Org 1.19.2 driver: ati,radeon unloaded: fbdev,modesetting,vesa 
           resolution: 1920x1080~60Hz 
           OpenGL: renderer: Gallium 0.4 on AMD KAVERI (DRM 2.50.0 / 4.17.0-1-amd64 LLVM 3.9.1) 
           v: 4.3 Mesa 13.0.6 
I recall enabling it with an earlier kernel but forgot the steps.
I had a similar issue some months ago and solved it by upgrading the mesa drivers to the last version, which you can find in the test repos.
Stretch-backports has a newer mesa, or we currently have 18.0.4 and a newer xorg-amdgpu driver in a separate experimental repo. I was a bit leery of having it in the test repo, since there are some that upgrade everything from there in one fell swoop.

Posted: **Fri Jun 15, 2018 3:08 pm**

I figured out a way (actually two ways) to get it to use the amdgpu driver for my Kabini gpu with the 4.17 kernel.

First, here's the inxi output:

Code: Select all

$ inxi -SGxxx
System:    Host: mx1 Kernel: 4.17.0-1-amd64 x86_64 bits: 64 compiler: gcc v: 6.3.0 Desktop: Xfce 4.12.3 
           tk: Gtk 2.24.25 info: xfce4-panel wm: Xfwm4 dm: lightdm 1.10.3 
           Distro: MX-16_x64 Metamorphosis 12 December 2016 
Graphics:  Card-1: Advanced Micro Devices [AMD/ATI] Kabini [Radeon HD 8240 / R3 Series] driver: amdgpu 
           v: kernel bus ID: 00:01.0 chip ID: 1002:9838 
           Display: server: X.Org 1.16.4 driver: amdgpu,ati unloaded: fbdev,modesetting,radeon,vesa 
           resolution: 1600x900~60Hz 
           OpenGL: renderer: Gallium 0.4 on AMD KABINI (DRM 3.25.0 / 4.17.0-1-amd64 LLVM 3.9.1) 
           v: 4.3 Mesa 13.0.6 compat-v: 3.0 direct render: Yes

I've been able to get it to use the amdgpu driver with either set of the following boot parameters,

these *** :

Code: Select all

amdgpu.cik_support=1 amdgpu.dc=0 modprobe.blacklist=radeon

or these *** :

Code: Select all

amdgpu.cik_support=1 radeon.cik_support=0 amdgpu.dc=0

***: If you have a GCN generation 1 / Southern Islands chipset (CAPE VERDE, PITCAIRN, TAHITI, OLAND, HAINAN), try replacing the 'cik' instances with 'si'.

In both cases, adding the 'amdgpu.dc=0' parameter is what finally got it to work. I don't know what the downside is to using it.

I do see a slight difference in the dmesg report between the two sets of boot parameters.

With the first set I see what's shown below, when it switches from EFI VGA to the amdgpudrmfb:

Code: Select all

[   10.607756] fb: switching to amdgpudrmfb from EFI VGA
[   11.095718] fbcon: amdgpudrmfb (fb0) is primary device
[   11.110920] amdgpu 0000:00:01.0: fb0: amdgpudrmfb frame buffer device

With the second set of boot parameters it first switches from EFI VGA to the radeondrmfb instead of the amdgpudrmfb, I don't know if that's a problem or not.

Code: Select all

[   10.648514] fb: switching to radeondrmfb from EFI VGA
[   11.748400] fbcon: amdgpudrmfb (fb0) is primary device
[   11.765293] amdgpu 0000:00:01.0: fb0: amdgpudrmfb frame buffer device

Posted: **Fri Jun 15, 2018 3:33 pm**

The first suggestion worked for my AMD Kaveri. Thanks

Code: Select all

amdgpu.cik_support=1 amdgpu.dc=0 modprobe.blacklist=radeon

Posted: **Fri Jun 15, 2018 4:43 pm**

Updating virtualbox and virtualbox-dkms, plus reinstalling the 4.17 headers, has definitely worked!

Posted: **Sat Jun 23, 2018 1:43 pm**

The "4.17.0-1" kernel in the test repo is now upgraded to a version based on 4.17.2. Since it has the same ABI (-1) as the 4.17.0 version, it will upgrade over that version. I'm not sure if DKMS drivers will automatically rebuild during the upgrade...if you don't see them doing that, you could reinstall the dkms packages in Synaptic to be sure, or "sudo dpkg-reconfigure <package>" them on the command line.

Posted: **Thu Jul 05, 2018 12:48 pm**

We now have the 4.17.3 version, backported from Sid, in the test repo, replacing 4.17.2. It should upgrade over 4.17.2, but might not update the dkms modules automatically. In that case, you can run

Code: Select all

apt policy *-dkms

to see which ones are installed, then

Code: Select all

sudo dpkg-reconfigure [package1] [package2] ...

to make they build.

Posted: **Thu Jul 05, 2018 12:50 pm**

Stevo wrote: Thu Jul 05, 2018 12:48 pm We now have the 4.17.3 version, backported from Sid, in the test repo, replacing 4.17.2. It should upgrade over 4.17.2, but might not update the dkms modules automatically. In that case, you can run
Code: Select all
apt policy *-dkms
to see which ones are installed, then
Code: Select all
sudo dpkg-reconfigure [package1] [package2] ...
to make they build.

This new build includes the internal Virtual Box and Anbox guest drivers, so the virtualbox-guest packages should no longer be required in guests.

I also have it a separate OBS repo that users of other Stretch-based distros might prefer to use instead. Instruction for that are:

As root, add the repo:

Code: Select all

echo 'deb http://download.opensuse.org/repositories/home:/stevenpusser:/kernel-backports/Debian_9.0/ /' > /etc/apt/sources.list.d/home:stevenpusser:kernel-backports.list

As a regular user, download the repo key:

Code: Select all

rm -f Release.key && wget -nv https://download.opensuse.org/repositories/home:stevenpusser:kernel-backports/Debian_9.0/Release.key -O Release.key

As root, add the key and update the apt database:

Code: Select all

apt-key add - < Release.key
apt-get update

The new kernel packages are now available to you, but won't be seen as upgrades of any packages, just like the backported kernel in stretch-backports. So you'll have to search for 4.17 linux packages that are now available.

Posted: **Thu Jul 26, 2018 6:07 am**

Hello,

Shall 4.15.17-1 kernel be pushed in regular updates soon ? I'm testing it since a few days. No problem here.

Posted: **Thu Jul 26, 2018 10:42 pm**

zorzi wrote: Thu Jul 26, 2018 6:07 am Hello,

Shall 4.15.17-1 kernel be pushed in regular updates soon ? I'm testing it since a few days. No problem here.

We don't have any debianized source from upstream Debian for that kernel revision. Refreshing the numerous Debian patches to match the possible source code changes would probably make doing it manually a very onerous job. I'd suggest one of the 4.17 kernels if you want to stay on top.

Posted: **Fri Jul 27, 2018 12:06 am**

Have been running the 4.17.4 kernel on AntiX for a few days now on both my main desktop machine and the Lenovo T430 everything has been running very smoothly.
Only thing I had to do was reinstall my nvidia drivers on the Main desktop after the kernel update also late night I updated my nvidia driver to 390.48 from the mx test repo and running sweet too..

Thanks for the updates.

Posted: **Wed Aug 15, 2018 1:25 pm**

The backport kernel version in the test repo has now been updated to an ABI of 4.17.0-2 (4.17.14). There's no metapackage for it yet, but it can be installed in Synaptic by doing a quick search for "4.17.0-2", then installing the appropriate linux-headers and linux-image for your current platform ("uname -a" to check that).

Posted: **Fri Aug 17, 2018 1:28 pm**

Thanks for this. When is the metapackage likely to be updated?

Posted: **Sat Aug 18, 2018 1:19 pm**

It depends on when the Sid maintainer updates it, though I'll look to see if I can do that myself...OK, it's in Sid now--backporting it now.

The backported kernel version in the test repo has just been updated to 4.17.0-3 (4.17.15), so the same search and install method in Synaptic applies, as it again is not an automatic upgrade yet without the metapackage.

Posted: **Mon Aug 20, 2018 2:35 pm**

The kernel maintainers issued 4.17.16 and then 4.17.17 in quick succession on Saturday to add some missing code, so we now have updated the backport to the 4.17.17 version in the test repo to include the full mitigation for the newly revealed speculative execution exploits.

Posted: **Fri Aug 31, 2018 3:06 pm**

A new backported 4.18.5 kernel has now landed in the test repo. Besides adjusting it to use gcc-6, the only configuration change I made was to bump up the kernel's context switch frequency from 250 to 1000 Hz, which is supposed to make it more responsive for desktop users, but worse for server duties.

Those that are using the proprietary Nvidia video driver should update to the 390.77 version, currently in stretch-backports, to be compatible with this kernel, before they install it. Ndiswrapper, broadcom-sta, and virtualbox 5.2.18 in our test repo all build sucessfully. Zfs-dkms has not yet been tested.

Posted: **Fri Oct 05, 2018 8:11 pm**

We now have the latest 4.18.10 (4.18.0-2) Debian kernel, backported from Sid, in our test repo. This has an ABI of -2 instead of -1, so won't upgrade automatically from the -1 version unless you have the kernel metapackage (example: linux-image-amd64) for your architecture also installed from the test repository. The Debian changelog is here.

Note that some AMD GPU users could be affected by this recently discovered bug: https://www.phoronix.com/scan.php?page= ... Power-Draw

This would also affect the Liquorix kernel, but probably will be fixed very soon.

Posted: **Thu Dec 27, 2018 3:38 pm**

We now have the latest 4.19.12 Debian kernel, backported from Sid, in the test repo, for those that may want to see if it fixes any bugs with our stock 4.19.5 kernel in MX 18--or just want to try the bleeding edge.

As usual, the kernel context switch frequency is bumped up from 250 to 1000 Hz in hopes of making it better for desktop than server use. It's still using the same "4.19.0-1" kernel ABI as all our backported 4.19 kernels.

Posted: **Sat Dec 29, 2018 2:54 am**

I'm testing it since yesterday. Nothing to report for the moment.

Posted: **Sat Dec 29, 2018 3:54 pm**

zorzi wrote: Sat Dec 29, 2018 2:54 am I'm testing it since yesterday. Nothing to report for the moment.

So no news is good news...

Posted: **Mon Dec 31, 2018 1:36 pm**

We've updated 4.19.12 in the test repo to 4.19.13, keeping the same 4.19.0-1 ABI name, so it will be seen as an upgrade to all the 4.19 Debian-type kernels in our repo, including the stock one in MX 18.

Posted: **Mon Dec 31, 2018 8:51 pm**

Upgraded to the 4.19.13-x64 kernel via MX Test repo.
Aok since this evening though haven't done much. More news if it happens. Thanks.

Posted: **Tue Jan 01, 2019 5:13 pm**

Stevo wrote: Mon Dec 31, 2018 1:36 pm We've updated 4.19.12 in the test repo to 4.19.13, keeping the same 4.19.0-1 ABI name, so it will be seen as an upgrade to all the 4.19 Debian-type kernels in our repo, including the stock one in MX 18.

Upgraded today. Nothing to mention for the moment.

Posted: **Sun Jan 20, 2019 6:58 pm**

We now have the latest backport from Sid, the 4.19.16 kernel, in the test repo, except this has the 4.19.0-2 ABI, so won't be an automatic upgrade to the MX 18 kernel.

Posted: **Sat Feb 16, 2019 7:13 pm**

The test repo version has been updated to the latest 4.19.20 from Sid, which has the 4.19.0-3 ABI version.

Posted: **Sat May 11, 2019 4:30 pm**

We now have the latest 4.19.0-5 (4.19.37) kernel, backported from Sid, in the test repo. Perhaps this update will be the default kernel in a proposed MX 18.3 point release, but we need testers besides me!

Posted: **Sat May 11, 2019 4:59 pm**

Stevo wrote: Sat May 11, 2019 4:30 pm We now have the latest 4.19.0-5 (4.19.37) kernel, backported from Sid, in the test repo. Perhaps this update will be the default kernel in a proposed MX 18.3 point release, but we need testers besides me!

Installs and runs fine here

Posted: **Sat May 11, 2019 5:10 pm**

Stevo wrote: Sat May 11, 2019 4:30 pm We now have the latest 4.19.0-5 (4.19.37) kernel, backported from Sid, in the test repo. Perhaps this update will be the default kernel in a proposed MX 18.3 point release, but we need testers besides me!

FI: I am going to try it (and install: linux-headers-4.19.0-5-common ... &. ... linux-image-4.19.0-5-amd64-unsigned ) ... my feedback will come after the test ...

EDIT:For the feedback, see here:
viewtopic.php?f=77&p=501767#p501767

Posted: **Wed May 15, 2019 7:52 pm**

Building yesterday's update to the 4.19.37-2 kernel in Sid, since they added a load of security mitigations:

Code: Select all

  * debian/bin: Fix Python static checker regressions (Closes: #928618)
  * Clean up speculation mitigations:
    - Documentation/l1tf: Fix small spelling typo
    - x86/cpu: Sanitize FAM6_ATOM naming
    - kvm: x86: Report STIBP on GET_SUPPORTED_CPUID
    - x86/msr-index: Cleanup bit defines
    - x86/speculation: Consolidate CPU whitelists
    - Documentation: Move L1TF to separate directory
    - cpu/speculation: Add 'mitigations=' cmdline option
    - x86/speculation: Support 'mitigations=' cmdline option
    - powerpc/speculation: Support 'mitigations=' cmdline option
    - s390/speculation: Support 'mitigations=' cmdline option
    - x86/speculation/mds: Add 'mitigations=' support for MDS
  * [x86] Mitigate Microarchitectural Data Sampling (MDS) vulnerabilities
    (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091):
    - x86/speculation/mds: Add basic bug infrastructure for MDS
    - x86/speculation/mds: Add BUG_MSBDS_ONLY
    - x86/kvm: Expose X86_FEATURE_MD_CLEAR to guests
    - x86/speculation/mds: Add mds_clear_cpu_buffers()
    - x86/speculation/mds: Clear CPU buffers on exit to user
    - x86/kvm/vmx: Add MDS protection when L1D Flush is not active
    - x86/speculation/mds: Conditionally clear CPU buffers on idle entry
    - x86/speculation/mds: Add mitigation control for MDS
    - x86/speculation/mds: Add sysfs reporting for MDS
    - x86/speculation/mds: Add mitigation mode VMWERV
    - Documentation: Add MDS vulnerability documentation
    - x86/speculation/mds: Add mds=full,nosmt cmdline option
    - x86/speculation: Move arch_smt_update() call to after mitigation decisions
    - x86/speculation/mds: Add SMT warning message
    - x86/speculation/mds: Fix comment
    - x86/speculation/mds: Print SMT vulnerable on MSBDS with mitigations off
    - x86/mds: Add MDSUM variant to the MDS documentation
    - Documentation: Correct the possible MDS sysfs values
    - x86/speculation/mds: Fix documentation typo
  * [x86] linux-cpupower: Update CPPFLAGS for change in <asm/msr-index.h>

Posted: **Tue Jun 11, 2019 3:12 am**

Hello,

I'm switching from Debian 4.9 to MX 4.19 kernel

I'm not able to install MX kernel metapackages (linux-headers-amd64 linux-image-amd64) from test repo, getting an error (see image below):

Posted: **Tue Jun 18, 2019 6:06 pm**

Added the Netflix security patches to address the security issues they found: https://www.bleepingcomputer.com/news/s ... y-netflix/

Updates should appear automatically. The main kernel ABI version remains at 4.19.0-5, though.

Posted: **Fri Aug 09, 2019 3:56 pm**

We now have the new 5.2.6 (5.2.0-1) Debian kernel backported from Sid in the MX 17/18 and 19 test repos.

We have a patched 418.74-2~mx(17/19)+1 Nvidia driver in the test repos that builds with it, but you should update to that first on an older kernel and make sure it works there before adding a new kernel. I'm also sending up a new nvidia-legacy-390xx-driver 390.129 that builds with the 5.2 kernel if your device is too old for the 418 driver. Currently the 340xx legacy driver has no update and has not been tested yet with the 5.2 kernel.

Update: Debian now has a 5.2.7 kernel upstream, so I'm working on that.

Posted: **Mon Oct 07, 2019 10:13 pm**

We now have the latest 5.3.2 kernel from upstream Debian in the test repos for MX 17/18 and 19 repos.

As is usual, if any of your hardware depends on a out-of-tree DKMS driver, such as nvidia-driver or broadcom-sta-dkms, you should update those from the test repo if possible before installing this kernel. We know that Nvidia 435.21, broadcom-sta-dkms, ndiswrapper-dkms, and Virtual Box 6.0.12 from the test repos will build and work on this kernel.

It is unknown if any of the legacy nvidia drivers support it yet, but I wouldn't bet on it.

Posted: **Thu Jan 02, 2020 4:36 pm**

The 5.4.6 kernel from Debian Sid is now available in our test repo, rebuilt against generic Stretch libraries.

Make sure to check what DKMS third-party drivers you're actually using, and upgrade those to the latest possible versions in the main and test repos, before you try to install and use this kernel.

MX Linux Forum

MX 17 Repository: The Backported Debian Kernel Thread

MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread

Re: MX 17 Repository: The Backported Debian Kernel Thread