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 (https://forum.manjaro.org/t/failed-to-execute-init-error-2-kernel-panic-after-latest-update/31383) 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.
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.
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.
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.
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.
It seems I'm a bit luckier than you guys... I've upgraded glibc via -testing and using -zen 4.13 without problems.
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
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.
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.
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?
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.
@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:
[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.
I do have intel-ucode installed and this is my hw:
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.
Is the microcode actually being loaded? Verify through dmesg like so:
#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.
# $Id$
# Maintainer: Thomas Bächler <thomas@archlinux.org>
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:
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:
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:
#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:
#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.
I got identical output from all my installations, I haven't checked devuan yet
[ 0.000000] microcode: microcode updated early to revision 0xba, date = 2010-10-03
[ 0.880799] microcode: sig=0x6fb, pf=0x1, revision=0xba
[ 0.880843] microcode: Microcode Update Driver: v2.2.
[ 1.195946] microcode: sig=0x6fb, pf=0x1, revision=0xb6
[ 1.195994] microcode: Microcode Update Driver: v2.2.
This hasn't happened in months, ever since Manjaro-Orc.
Ok, a couple or more weeks ago I had tried this on this specific installation and it froze.
I had disabled auto X login so I could be on console and maybe get a glimpse of what happens and if nothing weird happens try to start X with the sddm script or manually.
For some reason the microcode wasn't installed as I thought, but I installed the latest linux-zen and rebooted.
It booted fine, I started X and went straight into the login screen. All fine. Then I look at microcode and the tool, but the tool failed to install. I was on firefox and at the same time I tried to invoke gksudo something and everything froze.
Rebooted and looked at logs, no errors on X. I thought if I repeat everythin it would freeze again. It has been about 10hrs since then. Everything work great and I am actually on linux-zen. But as you see above the output changed. On the other two installations I haven't tried but I bet something in recent updates must have changed to make it work. The linux-mainline 4.14 I compiled from Aur last week it froze before it even got to the console login. I think it was while it was changing resolution on the console screen. This is no -efi system, plain old bios boot.
So how do you fix something that is no longer broke?
Second installation good!
Could it be the updated firmware that we received today via sys-testing? On this installation I had intel-micro since I installed it, 4.13 never would work.
I now wonder whether 4.14 will work as well, and I just deleted it a few days ago.
dc. artix2@GX755
xdc. ------------
'.. ddlc. OS: Artix x86_64
c0d:oxllc; Model: OptiPlex 755
:0ddlolc,lc, Kernel: 4.13.7-1-zen
:ko.:0ddollc..dlc. Uptime: 21 minutes
;KkxoOddollc' cllc. Packages: 1161
,Kkkkxdddllc, .lll: Shell: bash 4.4.12
,Xkkkddddlll;...';dlllldxk: Resolution: 1920x1080
,Xkkkddddlllloxxxddollloooo, WM: Openbox
xxk0kkkddddollloooooooolooooc;. WM Theme: Isawagorilla
dddkkkddddollc::;,'.... .lll; Theme: Adwaita-dark [GTK2/3]
.xdxkkxddl'cl:. .llc, Icons: Gnome [GTK2/3]
.0kkkxddl. ;'. ;llc. Terminal: lxterminal
.KOkdcddl. cllc. Terminal Font: Monospace 14
0Okd''dc. .cll; CPU: Intel 2 Duo E6550 (2) @ 2.333GHz
kOkd' .llc, GPU: Intel Integrated Graphics
dOd, 'lc. Memory: 796MiB / 3814MiB
:,. ... CPU Usage: 8%
Disk (/): 13G / 20G (71%)
Font: Sans 12 [GTK2/3]
Install Date: Sat 29 Jul 2017 3:46 PM
Locale: en_IE.UTF8