[SOLVED] Installed kernel 4.9.189 in AntiX-17 as advised. Now I have two problems!
antiX / MX LinuxThis forum is for the discussion of antiX and MX Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Installed kernel 4.9.189 in AntiX-17 as advised. Now I have two problems!
The first one is trivial. This kernel is not the default boot kernel, probably because it has a lower version number than the old one (4.18.7). I can only boot it by going into GRUB's advanced options sub-menu. A fix for this would be nice.
The second problem is more serious. I cannot run Xorg. I checked the Xorg log and the problem seems to be here:
Code:
[ 33.414] (--) CHROME(0): Mapping the frame buffer at address 0xF0000000 with size 131072 KB.
[ 33.415] (EE) CHROME(0): Unable to map the frame buffer.
Error: Invalid argument (22)
[ 33.415] (II) CHROME(0): Exiting viaMapMMIO.
[ 33.415] (II) CHROME(0): VIAFreeRec
[ 33.415] (II) CHROME(0): VIAFreeScreen
[ 33.415] (II) CHROME(0): VIAFreeRec
[ 33.415] (II) UnloadModule: "openchrome"
[ 33.415] (II) UnloadSubModule: "vgahw"
[ 33.415] (II) Unloading vgahw
[ 33.415] (EE) Screen(s) found, but none have a usable configuration.
[ 33.415] (EE)
Fatal server error:
Under the old kernel, the frame buffer mapping is successful, CHROME continues to initialise and X comes up normally. Openchrome is an unusual driver (they don't make these Via Chrome chips any more) but it would be a pity if it really won't work with this more secure kernel.
modprobe.blacklist=viafb might be something to try.
You may need an iomem or iommu option. I have yet to find any discussion or doc about how to determine which if any may or may not be indicated, but they seem to be indicated for older hardware and/or drivers to be able to cope with tighter restrictions on memory access while running newer kernels.
viafb doesn't seem to exist any more, though I remember it causing problems with older kernels. These kernels have a (presumably equivalent) module set with the flag FB_VIA. I don't know its precise name because it hasn't been set in either the working kernel or the bad one. So this is unlikely to be the source of the problem.
"iomem=relaxed" does it. I shall need to find a way of putting this permanently into GRUB. I'm not very knowledgeable about GRUB because I hate it and have always used LILO.
Thank you Mr Mazda. You are indeed very illuminating!
Now how do I get my new kernel to be the first one on the list? Do I have to uninstall the older (but higher numbered) kernel or is there a simpler way? And while we're at it, why doesn't the kernel installation script understand about LTS kernels?
PS: Looks like all I have to do for relaxed iomem is to put it into the GRUB_CMDLINE_LINUX_DEFAULT string, then update GRUB.
Last edited by hazel; 08-18-2019 at 11:58 AM.
Reason: Added postscript
Distribution: Mainly Devuan, antiX, & Void, with Tiny Core, Fatdog, & BSD thrown in.
Posts: 5,484
Rep:
Probably easiest to apt-get remove the unwanted kernel, grub should automatically use the 'new' one the next time you boot, if I remember right, (I normally only upgrade to later kernels).
Probably easiest to apt-get remove the unwanted kernel, grub should automatically use the 'new' one the next time you boot, if I remember right, (I normally only upgrade to later kernels).
Well, so do I. So does everyone. But because of the kernel's LTS system, a later kernel in an LTS series can have a lower version number than an earlier non-LTS kernel. So an upgrade (for meltdown mitigation in this case) can look like a downgrade. Apparently GRUB is too stupid to understand this.
Obviously I couldn't remove the old kernel until I got the new one to boot properly all the way to the X display manager. But now that I know the correct command line parameters to use, it should be safe to get rid of it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.