ubuntuusers.de

Hallo zusammen, zunächst einmal gleich besten Dank für eure Hilfe und auch die tollen Anleitungen und Tutorials. Ich war jahrelang stiller Mitleser. Leider habe ich mittlerweile ein Problem, bei welchem ich nicht weiterkomme. Ich nutze einen Intel NUC 13 Pro (mittlerweile ja Asus nach der Übernahme) und habe hier auch diverse Bios Versionen durchprobiert. Verwendet wird Ubuntu 2024.04.1 LTS

Mit Kernel aktueller als 6.5.0-1027 bekomme ich seit geraumer Zeit (der Kernel hat schon einige Monate auf dem Buckel) Kernel Panics.

Das sieht dann beispielsweise so aus:

/var/lib/systemd/pstore/1738593513/001# cat dmesg.txt
Oops#1 Part2
<4>[   45.542168] RSP: 002b:000000c0014cc498 EFLAGS: 00000206 ORIG_RAX: 000000000000002c
<4>[   45.542199] RAX: ffffffffffffffda RBX: 0000000000000010 RCX: 00005749bc99a00e
<4>[   45.542226] RDX: 0000000000000014 RSI: 000000c0007b6af8 RDI: 0000000000000010
<4>[   45.542253] RBP: 000000c0014cc4d8 R08: 000000c0010f5420 R09: 000000000000000c
<4>[   45.542280] R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
<4>[   45.542307] R13: 00005749c0971000 R14: 000000c0000061a0 R15: 0000000000000075
<4>[   45.542336]  </TASK>
<4>[   45.542348] Modules linked in: xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables tls cfg80211 xe snd_hda_codec_hdmi drm_gpuvm drm_exec gpu_sched drm_suballoc_helper snd_hda_codec_realtek drm_ttm_helper snd_hda_codec_generic sunrpc binfmt_misc nls_iso8859_1 snd_sof_pci_intel_tgl snd_sof_intel_hda_common soundwire_intel snd_sof_intel_hda_mlink soundwire_cadence snd_sof_intel_hda snd_sof_pci intel_rapl_msr snd_sof_xtensa_dsp intel_rapl_common snd_sof intel_uncore_frequency intel_uncore_frequency_common snd_sof_utils snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi soundwire_generic_allocation soundwire_bus joydev snd_soc_core x86_pkg_temp_thermal intel_powerclamp snd_compress i915 ac97_bus snd_pcm_dmaengine coretemp snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi kvm_intel snd_hda_codec drm_buddy snd_hda_core ttm kvm snd_hwdep mfd_aaeon asus_nb_wmi cmdlinepart
Oops#1 Part1
<4>[   45.542452]  drm_display_helper ov13858 asus_wmi snd_pcm v4l2_fwnode spi_nor cec mei_hdcp mei_pxp ee1004 irqbypass snd_timer v4l2_async ledtrig_audio mtd rapl intel_pmc_core snd sparse_keymap i2c_i801 mei_me rc_core spi_intel_pci videodev intel_cstate pmt_telemetry platform_profile wmi_bmof soundcore i2c_smbus spi_intel mei input_leds i2c_algo_bit igen6_edac intel_vsec mc pmt_class acpi_pad acpi_tad mac_hid sch_fq_codel overlay iptable_filter ip6table_filter ip6_tables br_netfilter bridge stp llc arp_tables dm_multipath efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 btrfs blake2b_generic dm_crypt raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid crct10dif_pclmul crc32_pclmul polyval_clmulni nvme polyval_generic ghash_clmulni_intel intel_lpss_pci nvme_core ahci sha256_ssse3 ucsi_acpi intel_lpss xhci_pci typec_ucsi video igc sha1_ssse3 thunderbolt libahci idma64 nvme_auth xhci_pci_renesas typec
<4>[   45.542861]  wmi pinctrl_tigerlake aesni_intel crypto_simd cryptd
<4>[   45.543139] CR2: 0000000000000000
<4>[   45.543155] ---[ end trace 0000000000000000 ]---

Oops Part 1:

cat dmesg-efi_pstore-173859351301001
Oops#1 Part1
<4>[   45.542452]  drm_display_helper ov13858 asus_wmi snd_pcm v4l2_fwnode spi_nor cec mei_hdcp mei_pxp ee1004 irqbypass snd_timer v4l2_async ledtrig_audio mtd rapl intel_pmc_core snd sparse_keymap i2c_i801 mei_me rc_core spi_intel_pci videodev intel_cstate pmt_telemetry platform_profile wmi_bmof soundcore i2c_smbus spi_intel mei input_leds i2c_algo_bit igen6_edac intel_vsec mc pmt_class acpi_pad acpi_tad mac_hid sch_fq_codel overlay iptable_filter ip6table_filter ip6_tables br_netfilter bridge stp llc arp_tables dm_multipath efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 btrfs blake2b_generic dm_crypt raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid crct10dif_pclmul crc32_pclmul polyval_clmulni nvme polyval_generic ghash_clmulni_intel intel_lpss_pci nvme_core ahci sha256_ssse3 ucsi_acpi intel_lpss xhci_pci typec_ucsi video igc sha1_ssse3 thunderbolt libahci idma64 nvme_auth xhci_pci_renesas typec
<4>[   45.542861]  wmi pinctrl_tigerlake aesni_intel crypto_simd cryptd
<4>[   45.543139] CR2: 0000000000000000
<4>[   45.543155] ---[ end trace 0000000000000000 ]---

Der Bootvorgang ist soweit normal, ich entschlüssele alles per luks (und dropbear via ssh) und für grob etwa 5 Sekunden kann ich mich auch anmelden und alles erledigen bis es eben zum Kernel Panic kommt. Dann hilft nur noch ein manueller Neustart per Knopfdruck und zurückgehen auf den 6.5.0-1027. Das gilt auch für aktuelle Kernel wie etwa 6.8.0-52.

Falls ich weitere Infos bereitsteuern kann - kein Problem.

Ansonsten bin ich natürlich für jede Hilfe oder Hinweise dankbar.

Probiere doch mal aus, ob ein normales Noble Numbat Live System vom USB-Stick läuft.

• Downloads/Noble Numbat

Falls ja, dann würde sich wohl empfehlen, anstatt dem oem Kernel, den normalen generic Kernel zu verwenden, im Terminal:

sudo apt-get install--reinstall linux-generic

Sollten irgendwelche Module per DKMS eingebunden sein, dann:

sudo update-initramfs -c -k all && sudo update-grub

Grub Konfiguration aktualisieren ist aber auf jeden Fall dann schon mal gut:

sudo update-grub

Selbst wenn es doppelt gemoppelt sein sollte, falls APT das bereits beim konfigurieren von linux-generic macht.

Lesenswert ist auch im Wiki:

• Kernel

Besten Dank soweit. dkms ist wohl nicht installiert

 dkms status
Command 'dkms' not found, but can be installed with:

update-grub soeben durchgeführt genauso

sudo apt-get install--reinstall linux-generic

leider gleiches Verhalten nach starten mit einem aktuellen Kernel

Was mir noch aufgefallen ist - teils kommt beim Login der Hinweis

*** System restart required ***
Pending processor microcode update!
Diagnostics:
  The currently running processor microcode revision is 0x4121 which is not the expected microcode revision 0x4123.

Diesbezüglich:

dmesg | grep -i microcode
[    1.320551] microcode: Microcode Update Driver: v2.2.

dpkg -s intel-microcode | grep Version
Version: 3.20241112.0ubuntu0.24.04.1

Ach und noch eine Info, die ich gestern nicht kommunziert hatte: Ich verwende Ubuntu *SERVER* also keine GUI. Aber das sollte hinsichtlich meiner Schwierigkeiten eigentlich keinen Unterschied machen.

Live Stick via Rufus und des angegebenen ISOs klappt. der dort verwendete Kernel ist 6.8.0-41-generic

dpkg -s intel-microcode | grep -i version
Version: 3.20240813.0ubuntu0.24.04.2

dmesg | grep -i microcode
microcode" current revision> 0x00004121

Trotz darüber grübeln. Eigenartig! Aber es scheint so, als wären diese Intel-NUCs ein wahrer Quell von Problemen. So was ähnliches hast Du vermutlich auch schon gefunden.

• https://www.reddit.com/r/intelnuc/comments/mhsbbp/if_your_nuc_is_running_ubuntu_2004_or_another/

• https://www.reddit.com/r/intelnuc/comments/1dl1sqg/nuc13anhi5_kernel_crash_problem_with_ubuntu_2204/

Dann ist da noch die Sache mit dem Microcode, wenn ich bei mir schaue, dann sieht das so aus:

sudo dmesg | grep -i microcode

[sudo] Passwort für ***: 
[    0.763851] microcode: Current revision: 0x00000a0b
[    0.774851] microcode: Updated early from: 0x00000a07

Wenn ich in die initrd reingucke, dann sehe ich auch den mit update-initramfs rein gebackenen microcode:

sudo lsinitramfs /boot/initrd.img | grep microcode

Wenn man in das Paket intel-microcode reinguckt:

dpkg -L intel-microcode

... dann sieht man auch die 2 Konfigurationsdateien:

/etc/default/intel-microcode

... und:

/etc/modprobe.d/intel-microcode-blacklist.conf

... und das Preinstall Skript

/etc/kernel/preinst.d/intel-microcode

... was über die cpuid auslesen versucht, das passende Modul für die jeweilige CPU zu laden. Zitat aus der Beschreibung:

# This script makes sure the cpuid module is loaded, before the
# kernel image has a chance to replace it with a new one that
# might not be compatible with the current kernel.

Wurde nach dem installieren vom Generic Kernel eigentlich das gemacht, mit anschließendem rebooten?

sudo update-initramfs -c -k all && sudo update-grub

Wenn mit dem intel-microcode und den Konfigurationsmöglichkeiten weder mit dem OEM Kernel noch mit dem Generic Kernel ein stabiler Betrieb möglich ist, gäbe es noch die Ausweichmöglichkeiten auf den Mainline Kernel, oder etwa auf den Liquorix Kernel, auch wenn der Liquorix Kernel eher für Multimedia und flinke Reaktion in Spielen gedacht ist. Ich benutze den selbst und bin daher etwas parteiisch zugunsten des Liquorix Kernel, der übrigens zu Zeit auf dem Stand:

uname -rsm

Linux 6.12.12-2-liquorix-amd64 x86_64 

... bei mir zur vollsten Zufriedenheit werkelt.

Im Wiki, der Artikel zm Mainline Kernel:

• Mainline-Kernel

Die Liquorix Webseite:

• Liquorix Kernel

Zitat:

Liquorix is an enthusiast Linux kernel designed for uncompromised responsiveness in interactive systems, enabling low latency compute in A/V production, and reduced frame time deviations in games.

Hallo trollsportverein,

danke erneut für die Unterstützung. Abseits vom Kernel Panic Problem gab es sonst keinerlei Instabilitäten. Ja gut, das Ethernet Problem dass 2.5Gbit teils "zusammenbricht" aber das geht soweit. Sonst hatte ich auch schon einiges finden können aber nichts hatte geholfen.

was mir noch aufgefallen war:

cat /etc/modprobe.d/intel-microcode-blacklist.conf
# The microcode module attempts to apply a microcode update when
# it autoloads.  This is not always safe, so we block it by default.
blacklist microcode

aber das wird ja hier geklärt

dmesg | grep -i microcode
[    1.320551] microcode: Microcode Update Driver: v2.2.

Ein erneuter Versuch via

sudo update-initramfs -c -k all && sudo update-grub

brachte leider auch keine Besserung.

Meine grub config ist auch recht normal meine ich:

cat /etc/default/grub
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="security=selinux"
# faulty kernel update https://medium.com/@kingaiva/how-to-make-grub-remember-your-last-selection-on-boot-7f99593c4df0
#GRUB_SAVEDEFAULT=true
#GRUB_DEFAULT=saved

# Multiboot option
# https://forum.manjaro.org/t/warning-os-prober-will-not-be-executed-to-detect-other-bootable-partitions/57849
#GRUB_DISABLE_OS_PROBER=false
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

wo mir halt GRUB_SAVEDEFAULT und GRUB_DEFAULT etwas Komfort bieten aufgrund meiner Probleme um beim alten stabilen Kernel zu bleiben. Jedoch ist das ja hier gerade auch auskommentiert und somit inaktiv gewesen.

Den Liquorix Kernel kannte ich bisher noch nicht.

Somit

curl -s 'https://liquorix.net/install-liquorix.sh' | sudo bash

und in der grub config

GRUB_DISABLE_OS_PROBER=false

Jedoch beim Booten vom neuen Kernel:

Loading Linux 6.12.13-2-liquorix-amd64
error: bad shim signature.
Loading initial ramdisk ...
error: you need to load the kernel first.

Press any key to continue...

angeblich soll das laut https://forums.linuxmint.com/viewtopic.php?t=393337

gefixt werden durch deaktivieren im Bios von secure boot.

Und tatsächlich? Damit konnte ich nun in den von dir empfohlenen Kernel booten und es läuft soweit..? Nur..nach Überfliegen(wie man anhand der Uhrzeit vlt erkennen kann, ist es eine komische kurze Nacht) von https://wiki.ubuntu.com/UEFI/SecureBoot → eigentlich sollte es ja mit sauberen Treibern kein Problem sein und ist sogar sinnvoll aktiv zu sein. Ganz vorsichtig gefragt - wie kann ich den vermeindlichen unsignierten Treiber entdecken und mir am besten eine "saubere" alternative installieren?

Abermals besten Dank. Und spannend dazuzulernen. SElinux machte mir ja schon öfters Kummer, gerade im Zusammenspiel mit (Podman)Containern aber SecureBoot bis dato noch nicht.

Ich bin in der glücklichen Lage meine uralte Maschine seit vielen Jahren nutzen zu können. Das heavy Alteisen hat gar kein UEFI, und somit auch kein "Secure Boot". Daher musste ich mich damit auch nicht weiter beschäftigen. ¯\_(ツ)_/¯

Ich kann aber die sha256sums vergleichen. 😎 Da würde auch auffallen, wenn was manipuliert würde.

Der Liqourix Kernel ist ein Drittanbieter Kernel und daher wohl auch nicht von Canonical signiert. Das müsste man dann wohl mit Machine Owner Keys (MOK) machen, falls man überhaupt "Secure Boot" haben will.

Einen technischen Einstieg, auch zu den Hintergründen, bietet rodsbooks.com:

• Rodsbooks.com - Managing EFI Boot Loaders for Linux: Dealing with Secure Boot

Im Abschnitt Initial Shim Setup geht es dann um das Shim und den MOK:

• https://www.rodsbooks.com/efi-bootloaders/secureboot.html#initial_shim

Auf rodsbooks.com gibt es auch ein Script zum generieren von MOKs:

• https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh

Kann man auch schon mal reingucken. Aber ich würde dann erst mal gucken, wie es mit einem Ubuntu Weg aussieht, zum Beispiel da:

• https://ubuntu.com/blog/how-to-sign-things-for-secure-boot

Tippe ich mal etwas mutig in mein Terminal als normaler User ein:

update-secureboot-policy

Der Befehl 'update-secureboot-policy' wurde nicht gefunden, kann aber installiert werden mit:
sudo apt install shim-signed 

... dann sagt es mir auch schon was ich dafür installieren müsste. Kann ich aber für meine altes Voll-BIOS Heavy-Metall nicht gebrauchen. 😎

Nachttrag - Bei Oracle kann man auch mal kurz reingucken, den zweiten Absatz in der Einführung finde ich erhellend und leicht verständlich:

• https://docs.oracle.com/de/learn/mokutil-uefi/

Hey trollsportverein, Dank dir einmal mehr. Ich habe mich nun noch etwas eingelesen und denke, dass ich mit der jetztigen Lösung zufrieden bin. Lieber einen aktuellen Kernel als secure boot. Das signieren packe ich mal auf die sehr lange bucket list an nice to have Themen. Schade nur, dass es keine aussagekräftigeren Fehlermeldungen gab, aber hey - letzten Endes bin ich ja glücklich. Also großes Lob!

Ich markiere das Thema dann als gelöst