Skip to main content
Topic: Do not install kernels 4.13.x (Read 5037 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Do not install kernels 4.13.x

Recently, I upgraded my Artix system's kernel from 4.12.7 to 4.13.3, and after running mkinitcpio (which is done automatically after the upgrade) and rebuilding the GRUB configuration file, I rebooted it. I was presented with a kernel panic, and the error message indicated that there was no init found. Explicitly introducing the init executable file path to the kernel yielded the same results, the error read that the indicated init failed. Trying to boot with the 4.9 LTS kernel wasn't of any use either. The only thing that worked was taking the quickest but most brute approach, formatting the drive and reinstalling.

It could be said that this would be an isolated case, but after looking up this kind of problem, I came across this post on the Manjaro forums. He was on a Manjaro OpenRC system, and also upgraded to kernel 4.13. This led me to believe that something is up between kernel 4.13 and OpenRC. So I'm putting this out there for anyone thinking about installing newer kernels.

This is one of the reasons why only LTS kernels are supported, for the time being, at least.

Re: Do not install kernels 4.13.x

Reply #1
The only kernel I have ever had problems with was 4.13 (since rc1) and back in Manja-Orc I had even tried -RT without problems.
As soon as zen moved to 4.13 my system broke.  But why would your system not boot with lts?  On the new installation what kernel are you using?  It sounds more like something wrong with the grub entry than a kernel problem.
I am currently using linux-ck which is based on 4.12 too.  Upstream they call 4.13 stable as 4.13.3 and working on 4.14.
I have some hw incompatibility with 4.13 which I haven't been able to identify, and I am using very massively produced hardware just as it came off the shelf. 
I wonder when 4.13 will be admitted to debian/sid to see whether the problem reproduces itself.  In Manjaro there were a few having a problem as soon as 4.13 came out but nobody paid any attention then.  Go search 4.13-rc1 to verify.

Re: Do not install kernels 4.13.x

Reply #2
I have no idea why the LTS kernel was throwing the same error. I had no time to find out why, as I needed a working system as soon as I could, hence the formatting.

I am now using kernel 4.9.43-max98090, a patched kernel that includes fixed drivers for my particular audio card. I need to use this kernel if I want audio through my speakers and audio jack. On my previous installation, I was using kernel 4.12.7-max98090.

 

Re: Do not install kernels 4.13.x

Reply #3
Okay, so after more people in the forum having trouble with the same stuff, this is very likely what happened to me as well. I had glibc installed from system-testing, which is glibc 2.26-4. I had to install this in order to get Steam installed on my system. Having ran mkinitcpio with this version of glibc installed, the dreaded kernel panic ensued when rebooting. This is one detail I missed, which I paid no attention to. Apparently, the solution is the chroot into the installation, downgrade to 2.25 and re-run mkinitcpio.

Re: Do not install kernels 4.13.x

Reply #4
Have you tried linux-ck ?
I have problems with 4.13 ever since its introduction, it freezes everything up.
Linux-ck is still on 4.12 and runs fine.
I have an old Dell with all factory intel crap. C2Duo, i915  that hates 4.13 with a passion.
Linux-zen worked as long as it was on 4.12, from the day it switched to 4.13 it broke.

Re: Do not install kernels 4.13.x

Reply #5
It seems I'm a bit luckier than you guys... I've upgraded glibc via -testing and using -zen 4.13 without problems.

Re: Do not install kernels 4.13.x

Reply #6
For a while I thought it was something in 4.13 that was incompatible with my hardware (although very mass produced and unaltered). 
When 413-rc1 came out in Manjaro I tried it on my M...-openRC and X froze.  When I tried later editions of it the outcome was the same.
When linux-zen in artix moved to 4.13 my X froze.
Now that 4.13 came to Debian I thought I should try expecting it to break X as well.  NOPE!!!!
So I used Debian/sid 4.13 kernel in Devuan, which runs on sysvinit, and it worked great.  I pretty much tried anything I had installed to see if there is a problem.

Deduction?  Arch has messed something up in X that is incompatible with 4.13 and only created conflicts with certain hardware configurations.  The freeze is so abrupt that leaves no log traces of any problems.

https://sysdfree.files.wordpress.com/2017/10/screenshot_linux413atdevuan-e1507561787379.png

Re: Do not install kernels 4.13.x

Reply #7
linux-mainline 4.14.rc3?
It took all night to compile but it was done and finished.
I think the error came much earlier than X.  All I get is a black screen, not even half way down the oRC list the screen went black and irresponsive.

Artix has been wearing off my on/off button .... yeah I know, I can stick to lts, but this is not what linux is about.

Re: Do not install kernels 4.13.x

Reply #8
fungalnet, I haven't tried out linux-ck yet, I will do so once I get to my desktop, in December. Seems like this problem only happens with specific software configurations.

Re: Do not install kernels 4.13.x

Reply #9
Apparently, the solution is the chroot into the installation, downgrade to 2.25 and re-run mkinitcpio.

I chrooted into mine last night to upgrade and fix but mkinitcpio wouldn't run, something about 4.9...... not being valid.  Would having the broken version of glibc cause this?

Re: Do not install kernels 4.13.x

Reply #10
I tried 4.14rc3, rc4, rc5, same thing.  Everything freezes up not a hint of a log entry of what went wrong.
Meanwhile -lts (4.9) and -ck (4.12) still run fine.
On Devuan2-ascii 4.13 runs well, no 4.13 kernel has run on my system with arch, manjaro, or artix.

Re: Do not install kernels 4.13.x

Reply #11
@funglnet
Can you get the configuration from your Devuan kernel then do a diff on it to the linux-zen configuration?
It may lead to what Devuan did to allow it to function on your system. It could be related to a serious error that occur on my system while using the 4.13.x kernel.
I have been using linux-zen 4.13.x for quite sometime. At first, it appeared to working. But when a major tool chain file or openrc init was updated and found that I had no working init. I was able to get my system working by chrooting from an Artix ISO and re-installing the base and base-devel files. The last time this occurred I discovered that none of the files were downloaded and yet when I rebooted everything was good. The only difference was the kernel that was loaded. When I analized dmesg, a serious error message regarding TSC_DEADLINE was displayed:
Code: [Select]
[0.000000] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0xb2 (or later)
(The 0xb2 code is for the Intel Skylake processor. If your CPU is different then a different version code will be displayed.)
Now with the intel-ucode loaded, I have been able to update without the init not found issue. Openrc and glibc latest updates did not crash my system with the init failure where previous updates of glibc and openrc did. At first I thought that the message was not a serious one and ignored it at my peril. When researching this issue, I discovered that the linux kernel no longer had workarounds for Intel's bugs in the original CPU firmware with the 4.13 release. Of course all newer kernels will no longer have the workarounds as well.  This could be be the source of your kernel crashes if the Devuan kernel has embedded the microcode into the kernel or their initrd (initramfs) by default.
Of course at this point, it pure conjuncture since I do not know what CPU you are using and if you have your CPU's microcode loaded. I am assuming that AMD CPU's will also some similar issue with the kernel CPU workarounds being removed.

Re: Do not install kernels 4.13.x

Reply #12
I do have intel-ucode installed and this is my hw:

Code: [Select]
System:    Host: GX755 Kernel: 4.12.14-1-ck x86_64 bits: 64 Desktop: Openbox 3.6.1 Distro: Artix rolling
Machine:   Device: desktop System: Dell product: OptiPlex 755 serial: N/A
           Mobo: Dell model: 0PU052 serial: N/A BIOS: Dell v: A11 date: 08/04/2008
CPU:       Dual core Intel Core2 Duo E6550 (-MCP-) speed/max: 2000/2333 MHz
Graphics:  Card: Intel 82Q35 Express Integrated Graphics Controller
           Display Server: N/A drivers: intel (unloaded: modesetting,fbdev,vesa) tty size: 124x38


I have next to no experience deconstructing kernel internals, if you can help me out with specific procedures I'm willing to investigate.  I'm just so surprised with the hw being as common that I have not found others with similar issues, across distros.

Re: Do not install kernels 4.13.x

Reply #13
FYI
Quote
Arch Linux Security Advisory ASA-201710-26 ==========================================
Severity: High Date : 2017-10-17
CVE-ID : CVE-2017-5123
Package : linux
Type : privilege escalation
Remote : No
Link : https://security.archlinux.org/AVG-444
Summary =======
The package linux before version 4.13.7-1 is vulnerable to privilege escalation.
Resolution ========== Upgrade to 4.13.7-1. # pacman -Syu "linux>=4.13.7-1"
The problem has been fixed upstream in version 4.13.7.
Workaround ========== None.
Description =========== It was discovered that when the waitid() syscall in Linux kernel v4.13 was refactored, it accidentally stopped checking that the incoming argument was pointing to userspace. This allowed local attackers to write directly to kernel memory, which could lead to privilege escalation.
Impact ====== A local attacker is able to escalate privileges on the affected host.
References ==========
http://www.openwall.com/lists/oss-security/2017/10/12/18
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96ca579a1ecc943b75beba58bebb0356f6cc4b51
https://security.archlinux.org/CVE-2017-5123
______________________________________________

Re: Do not install kernels 4.13.x

Reply #14
Is the microcode actually being loaded? Verify through dmesg like so:
Code: [Select]
#dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09
[    1.005601] microcode: sig=0x506e3, pf=0x2, revision=0xba
[    1.005916] microcode: Microcode Update Driver: v2.2.
I had the microcode installed and choose to embed it in the kernel but it was not loading. I ended up using creating a modded intel-ucode PKGBUILD that would create a initramfs/cpio file that just held my CPU's microcode which sped up booting.
Code: [Select]
# $Id$
# Maintainer: Thomas Bächler <[email protected]>
pkgname=intel-ucode
pkgver=20170707
# Some random "download id" that intel has in their downloadcenter
_dlid=26925
pkgrel=1
pkgdesc="Microcode update files for Intel CPUs"
arch=('any')
depends=('iucode-tool')
install=$pkgname.install
url="https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&keyword=%22microcode%22"
replaces=('microcode_ctl')
license=('custom')
source=("https://downloadmirror.intel.com/${_dlid}/eng/microcode-${pkgver}.tgz"
        'LICENSE'
        'intel-microcode2ucode.c')
sha256sums=('4fd44769bf52a7ac11e90651a307aa6e56ca6e1a814e50d750ba8207973bee93'
            '6983e83ec10c6467fb9101ea496e0443f0574c805907155118e2c9f0bbea97b6'
            '5af76d7e23768c94ab03fbf0d280b30fccd9c1ce697111c9999f6d51955c5a98');

build() {
  cd "$srcdir"
  gcc -Wall ${CFLAGS} -o intel-microcode2ucode intel-microcode2ucode.c
  ./intel-microcode2ucode ./microcode.dat
}

package() {
  cd "$srcdir"
  install -d "${pkgdir}"/boot
  msg2 "Creating exact microcode cpio file for install CPU."
  iucode_tool -S --write-earlyfw=intel-ucode.img microcode.dat
  install -m644 intel-ucode.img "${pkgdir}"/boot/
  install -Dm644 LICENSE "${pkgdir}"/usr/share/licenses/${pkgname}/LICENSE
}
It does require building and installing the AUR iucode-tool prior to building the package though.
I use rEFInd to boot thus I had to add the microcode img file created to the /boot/efi/EFI/refind/refind.conf manual stanza like so:
Code: [Select]
menuentry "Artix Linux ZEN Kernel" {
    icon EFI/refind/icons/os_artix.png
    volume "artix"
    loader /boot/vmlinuz-linux-zen
    options "root=LABEL=artix rw initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux-zen.img"
    submenuentry "nvidia modeset on" {
        add_options "nvidia-drm.modeset=1"
    }
    submenuentry "pstate disabled" {
        add_options "intel_pstate=disable"
    }
    submenuentry "Boot with the fallback initramfs" {
        initrd /boot/initramfs-linux-zen-fallback.img
    }
}
The important part was to add both the initramfs for the kernel after the cpio in the options line to enable it to correctly load the microcode during boot. The Archlinux wiki for rEFInd microcode how to did not work for me.
Although grub should automatically enable the it, one should verify that it is actually loaded. If it isn't then you would have to add it the /etc/default/grub file GRUB_CMDLINE_LINUX= section or create  a custom configuration in /etc/grub.d/40_linux-zen (or another name you like but keep the 40 in front) then regenerate the working configuration file with:
Code: [Select]
grub-mkconfig -o /boot/grub/grub.cfg
I do compile my own linux-zen kernel as well to change the stuff more to my system as well. One thing to try is disable all AMD kernel options, disable all hardware that you do not need on your system (only keep the video drivers you require) and select the actual CPU you have in kernel instead of the generic one. In your case, it should be CORE2. If the kernel panic is so quick that nothing is showing then it would difficult to trace the cause. That is why I'm suggesting compile your own with just the stuff you need to remove some of the variables. You can use your working kernels configuration as a starting point and set the new options that arise. First one must check which modules are being loaded:
Code: [Select]
#lsmod
And be sure to have those enabled.
Did you check the Devuan kernel configuration that worked for you? You could use it as a base to compile your own. Boot your to Devuan partition and to obtain it's configuration run:
Code: [Select]
#zcat /proc/config.gz > config.x86_64
(I am assuming it is similar to Archlinux and Artix Linux.)
If it does not exist, it may be the /boot folder location has a configuration file which could be used something like this /boot/config-4.13.2-1-amd64. I am not sure since I do not run Devuan and have not run Debian for many years

Yes I have updated to linux-zen 4.13.7 when it was released. Thanks for the info anyway.