testing for MX 18.3

[Stevo]

...
yeah, 19 will be buster. and despite buster's "feature freeze", its still a moving target. I'm not even joking a little. If we did a buster release a month ago, recent updates would have broken it. They keep shifting dependencies definitions on certain key packages....

And despite the challenge, the MX team have been able to keep the MX Linux stable?
RESPECT!

There hasn't been a Buster edition of MX yet, so...no challenge yet.

[Richard]

New Kernel Question? Never mind.
Found the answer on D_O's original post.

The 4.19.0-5-amd64 is working very well, plus it is normally some 8 to 10°C cooler. than with the Liquorix-5.0.0-8.1-amd64; once I got intel_pstate & thermald properly configured.

[Sanji]

Hi

I tested the
linux-image-4.19.0-5-amd64-unsigned
kernel just now.

For me it has the same problem which the previous 4.19 kernel had where the system can freeze up. I can confirm that this is still an issue for me on the newer updated 4.19 kernel.

I will go back to using the 4.20 antiX kernel which works fine for me.

[i_ri]

hello dolphin_oracle and Steveo
Coming back to this topic This is where it started for this machine upgraded to the 4.19.0-5 when it was presented here.

MX-18.2_x64 today looked at update packages. On the listing there is a update for the 4.19.37-1 [disguised as 4.19.0-5] update to 4.19.37-2.
There became available a 4.19.43 yesterday so selcted to upgrade to that instead. Now machine is running 4.19.43 But the 4.19.37-2 is still on the update list. upgrading would install 4.19.37-2. (It has the kbuild too.)
What direction to take to iron out this wrinkle? 4.19.37-2 or 4.19.43?

[dolphin_oracle]

I don't know where your 43 is coming from, but we are looking at 37-2 for the 18.3 iso.

[AK-47]

4.19.37-1 [disguised as 4.19.0-5]

I can easily see why that convention is confusing. Is that something out of Debian or is that an MX/antiX convention?

[kmathern]

I don't know where your 43 is coming from, but we are looking at 37-2 for the 18.3 iso.

It looks like it's up to a -3 (4.19.37-3) now in buster & stretch-backports: https://packages.debian.org/source/buster/linux

edit: nevermind, -3 was just to fix a fail to build problem for powerpc, so -2 is probably still okay to use: https://metadata.ftp-master.debian.org/ ... _changelog


43 is a antiX kernel

Code: Select all

linux-image-4.19.43-antix.1-amd64-smp      4.19.43-antix.1-amd64-smp-1  http://la.mxrepo.com/antix/stretch/
linux-image-4.19.0-5-rt-amd64-unsigned     4.19.37-2~mx17+1             http://la.mxrepo.com/mx/repo/
linux-image-4.19.0-5-cloud-amd64-unsigned  4.19.37-2~mx17+1             http://la.mxrepo.com/mx/repo/
linux-image-4.19.0-5-amd64-unsigned        4.19.37-2~mx17+1             http://la.mxrepo.com/mx/repo/

[figueroa]

Debian renumbers the kernels released by upstream (kernel.org) according to its own convention. Its always been a little confusing. MX sticks with the Debian number. You can see exactly which kernel you are running on the first line of dmesg output:

Code: Select all

$ dmesg | head -1
[    0.000000] Linux version 4.19.0-5-amd64 (stevep@mxlinux.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.19.37-2~mx17+1 (2019-05-15)

[dolphin_oracle]

or

Code: Select all

uname -a

[i_ri]

hello dolphin_oracle and SteveO
uname -a? not when I can have a chuckle with any chance to type inxi -bs.
machine allowed the upgrade of 4.19.37. It boots to the 4.19.43.
I think that is the first time a update to a previous kernel has been encountered here. Now I know the outcome.