2019-06-24 09:33:14 2019-06-24 09:33:14 2019-06-24 09:33:11 429225
Our recent kernel problem
What actually happened?
An update to the MX-18.3 default kernel (4.19) was released that lacked the ability to rebuild various significant kernel modules such as nvidia, virtualbox, broadcom, and a few others. We normally push upgrades within a kernel series in order to keep pace with security measures, as we did here. The upgraded kernel was tested before release but the problem did not show up. In general, the problem has been very irregular in users affected and in effects it causes.
How did we respond?
It took us a while to figure out exactly what was happening, since the early reports differed greatly. Our first step was to try to get information to at least some users through announcements on the Forum, Facebook and Twitter. We know those do not reach everybody, of course, but it’s a start. We then took down the kernel update, which will disappear from repos as soon as they are synced up. Once that was done, we began to explore solutions, and have done a great deal of testing.
Are there solutions available for people who were affected?
We have developed and tested three different solutions that are are described in detail further down this page:
1) force the rebuilding of the kernel modules
2) install a different kernel
3) LiveUSB only: launch a recovery command sequence
Is it safe to return to normal update/upgrade??
As soon as the corrupt update is gone from the repo being used, normal update/upgrade can be reinstated. This should be completed in all repos by two days after the date of this post. If you want to test whether it is still there, right-click the MX Updater icon > Check for Updates and look for the presence of linux-image-4.19. If you see it there, then do not upgrade yet.
1) Force the rebuilding of the kernel modules
If you can get to a desktop, press F4 to open a terminal, and enter as normal user this command:
If you can’t get to a desktop and end up on a black screen with a blinking cursor, press Alt-F1 to get to a prompt. Log in as your regular user and then run that code.
2) Switch to a different kernel
This is part of 3) for LiveUSB, but may be relevant on an installed MX if procedure 1) did not work for you. If you already have another kernel installed, then reboot and select it by clicking on the “Advanced options” link on the boot screen. If you do not already have one, do one of the following:
if you can get to a desktop, press F4 followed by Alt-F1 if you can’t, press the letter “e” when the boot screen comes up, then look for the line that begins with “linux” and add a “3” (without the quotes) at the end of it
Once you arrive at a command prompt, become root and enter the command
Choose to Ignore updates if you see that screen first. You will be presented with a menu, from which you should select “Search for all kernels.” Choose a new one that suits your system; if you have no idea what to do, the Debian Stretch default 4.9 would be a safe choice.
3) LiveUSB only
Launch a recovery command sequence as laid out in this post: https://forum.mxlinux.org/viewtopic.php?p=510505#p510505.
7 thoughts on “Our recent kernel problem”
#News #Nachrichten #Debien #MXLinux #Computer #IT #Software #Linux #Gnu #OpenSource #Kernel #Tux