I just did a fresh install. From that, I did an update. This got me kernel 4.15.3-towo.2-siduction-amd64. That gave me a kernel panic when starting. When I went back to the old kernel, it showed that there was an update, 4.15.4-towo.1-siduction-amd64. When I installed that, there was again a kernel panic.
Other than the below, there doesn't seem to be anything to help in journalctl. Obviously, I couldn't get a screen shot on the failed boots.
Is this a known issue, or is it just me and it must be something to do with the new computer?
kernel: ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespa
kernel: ACPI Exception: AE_NOT_FOUND, During name looku
kernel: ACPI Exception: AE_NOT_FOUND, (SSDT:xh_rvp08) w
kernel: ACPI Error: 1 table load failures, 8 successful
kvm: disabled by bios
kernel: platform regulatory.0: firmware: failed to load
Just did an update on an old laptop. It only takes it to 4.15.3, but there is no kernel panic. It might just be my new desktop.
updated to 4.15.4 just a minute ago, all good.
ZitatSystem: Host: siduce Kernel: 4.15.4-towo.1-siduction-amd64 x86_64 bits: 64 Desktop: KDE Plasma 5.12.0
Distro: siduction 17.1.0 Patience - kde - (201703051755)
Ok. Thanks.
All your output is cut off, but the last error message might be connetcte to this (https://www.linuxquestions.org/questions/showthread.php?p=5814902#post5814902) and maybe cause the kernel panic.
I don't think it's the regulatory.db error -- I believe that is harmless. I'm seeing it on several of my systems, and somewhere there is a kernel bug report that says don't worry about it.
user@n5110:~$ dmesg | grep regulatory.db
[ 3.595179] platform regulatory.0: firmware: failed to load regulatory.db (-2)
[ 3.595226] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 3.761560] cfg80211: failed to load regulatory.db
user@n5110:~$ inxi -Fz
System: Host: n5110 Kernel: 4.15.3-towo.2-siduction-amd64 x86_64 bits: 64 Desktop: LXQt
Distro: siduction 17.1.0 Patience - lxqt - (201703051830)
Machine: Device: portable System: Dell product: Inspiron N5110 serial: N/A
Mobo: Dell model: 034W60 v: A11 serial: N/A BIOS: Dell v: A11 date: 08/03/2012
CPU: Dual core Intel Core i3-2330M (-MT-MCP-) cache: 3072 KB
clock speeds: max: 2200 MHz 1: 1034 MHz 2: 1055 MHz 3: 807 MHz 4: 812 MHz
Graphics: Card: Intel 2nd Generation Core Processor Family Integrated Graphics Controller
Display Server: x11 (X.Org 1.19.6 ) drivers: modesetting (unloaded: fbdev,vesa)
Resolution: 1366x768@60.00hz
OpenGL: renderer: Mesa DRI Intel Sandybridge Mobile version: 3.3 Mesa 17.3.4
Audio: Card Intel 6 Series/C200 Series Family High Definition Audio Controller driver: snd_hda_intel
Sound: Advanced Linux Sound Architecture v: k4.15.3-towo.2-siduction-amd64
Network: Card-1: Realtek RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller driver: r8169
IF: enp5s0 state: down mac: <filter>
Card-2: Intel Centrino Wireless-N 1030 [Rainbow Peak] driver: iwlwifi
IF: wlp9s0 state: up mac: <filter>
Drives: HDD Total Size: 80.0GB (14.8% used)
ID-1: /dev/sda model: INTEL_SSDSA2CW08 size: 80.0GB
Partition: ID-1: / size: 16G used: 8.4G (57%) fs: ext4 dev: /dev/sda1
ID-2: swap-1 size: 2.15GB used: 0.00GB (0%) fs: swap dev: /dev/sda2
RAID: No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors: System Temperatures: cpu: 49.0C mobo: N/A
Fan Speeds (in rpm): cpu: N/A
Info: Processes: 194 Uptime: 14 min Memory: 972.8/3856.2MB Client: Shell (bash) inxi: 2.3.56
EDIT: Actually, it does say here (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=007f6c5e6eb45c81ee89368a5f226572ae638831) that in some cases it could crash the kernel, so Devil might be correct. But on at least two systems here it causes no problem.
EDIT #2: Here (https://www.spinics.net/lists/linux-wireless/msg168036.html) is where it says it is nothing to worry about.
The output from the kernel panic (for reference, not something that's affecting most people) is
BUG at /build/linux-siduction-14.15./kernel/time/timer.c:950
On an ASUS H170 Pro board, Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz.
It was the rt18812au dkms that was causing the panic. There's a new release that takes care of timers at https://github.com/abperiasamy/rtl8812AU_8821AU_linux
Solved with installing from ubuntu , package with regulatory.db : wireless-regdb
If no install , need to copy 2 files: regulatory.db and regulatory.p7s
ZitatSolved with installing from ubuntu , package with regulatory.db : wireless-regdb
If no install , need to copy 2 files: regulatory.db and regulatory.p7s
For sure that is not solved :o
prepare to do a reinstall soon ...
ubuntu is not binary compatible with debian
If your going to use ubuntu packages on debian, install ubuntu, saves you, and us a lot of headache
May be you are right , I don't know , but my wireless is back working after putting the 2 files in place.
And I had read about modification in kernel 4.15 , where regulatory.db is read directly by kernel
And also , the problem was solved for others also with copying regulatory.db and regullatory.p7s in /lib/firmware.
May be you have another solution , I not.
I found this :
+.B regulatory.db +is a newer, extensible database format which (since Linux 4.15) is read +by the kernel directly as a firmware file.there :https://patchwork.kernel.org/patch/10128823/And kernel is the same soucecode for all, only config differs
@piper - the reg.db and the other file will not be compiled within the build process.
@all: But one thing remains if bitten by this bug: Damn - you filed a bug for it in debian? Reason: It might be that Ubuntu will take the next package from debian and the files might sillently disappear in Ubuntu ...
For the record, the last post on this bug report (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892229) gives the "solution". That tarball is found here (https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2017.12.23.tar.xz).
But on 3 wireless siduction systems in my house, none has any problem about this.
https://tracker.debian.org/pkg/wireless-regdb - god damn, that's what i 'like' about debian.
Hmm, ok, 16.06 is a brand new one - the last flesh was rotten only a year before ...