[GELÖST] Einfrieren nach Upgrade mit Warnung.

[Isegrimm666]

Guten Morgen ...

Ich habe gerade ein:

Code Select Expand

doas apt update && doas apt --solver 3.0 full-upgrade durchgeführt.

Nach einem ...

Code Select Expand

doas apt autoremove && doas /sbin/reboot now

... startete der Rechner mit folgender Fehlermeldung:

[0.098513]Spectre V2: WARNING unpriviledged eBPF is enabled with iBRS on, data leaks possible voa Spectre V2 BHB attacks!

... und fror danach ein.

Nach einiger Zeit erschien:

Timed out while waiting for udev queue to empty

Der Rechner ist ein Acer Nitro 5, der nach dem upgrade aktive Kernel ist 6.17.3-1-siduction-amd64.

Als ich den Rechner mit dem "Backup-Kernel" 6.17.2-1-siduction-amd64 startete, kam die Fehlermeldung zwar auch ... aber der Boot-Vorgang lief danach ordnungsgemäß durch.

Frage 1: Kann mir jemand die Fehlermeldung erklären?
Das Internet ist jetzt nicht wirklich hilfreich.

Frage 2: Wie kann ich den Bootvorgang unter 6.17.3 wieder fixen?
Im Netz wird z.B. geraten, in /etc/sysctl.d bzw in /etc/sysctl.conf die Zeile:

Code Select Expand

kernel.unprivileged_bpf_disabled=1

... einzufügen, aber ich bastle nich wirklich gerne an Systemdateien rum, ohne zu wissen, was ich tue.
Ausserdem gehe ich davon aus, dass diese Datei von beiden Kernels angesprochen wird und unter dem älteren läuft das System.

Ich vermute, dass meine Verkettung von Autoremove und dem Reboot das Problem verursacht hat.

Update 2025-10-25, 08:12h

Lösung in: https://forum.siduction.org/index.php?topic=9812.msg78055#msg78055

[graviton]

Ich kann Dir zwar nicht helfen, aber meine beiden Systeme haben nach dem heutigen update kein Problem mit dem neuen Kernel.

(I can't help you, but after today's update, my systems have no problems with the new kernel.)

graviton

[unklarer]

Wie @graviton habe ich j etzt hier drei Rechner mit dem Kernel aktualisiert. Keiner zeigt das Verhalten des TE.

Vielleicht doch mal mit su und mit autopurge arbeiten...   

[devil]

Ich denke nicht, dass die Warnung und das Einfrieren ursächlich zusammenhängen. Die Warnung dient lediglich der Information, weist jedoch auf ein reales Risiko durch spekulative Ausführung hin, was aber auf Privatrechnern keine Rolle spielt. Die Zeile

Code Select Expand

sudo sysctl kernel.unprivileged_bpf_disabled=1 richtet keinen Schaden an.
Warum der Rechner nun einfriert, kann ich dir natürlich nicht sagen.

[towo]

Ohne eine Ausgabe von

inxi -Fz

wird da auch niemand viel dazu sagen können, da wir ja keine Glaskugel haben und die Hardware nicht kennen.

[Isegrimm666]

Ohne eine Ausgabe von

inxi -Fz

wird da auch niemand viel dazu sagen können, da wir ja keine Glaskugel haben und die Hardware nicht kennen.

Würde ich ja gerne tun ... aber vielleicht habe ich mich unklar ausgedrückt:

• Ich starte den Rechner
• Grub erscheint, ich wähle den aktuellen Kernel (6.17.3-1-siduction-amd64)
• Grub verschwindet, die im Eingangspost gezeigte Fehlermeldung erscheint
• - Freeze -

Es erscheint kein prompt ... Linux ist noch nicht komplett gestartet, ein Umschalten auf eine 2. Konsole funktioniert dann natürlich auch nicht.

Wähle ich den vorherigen Kernel in Grub aus ...

• Ich starte den Rechner
• Grub erscheint, ich wähle den vorherigen Kernel (6.17.2-1-siduction-amd64)
• Grub verschwindet, Linux bootet einwandfrei
• - System ist da -

... kann ich auch die angefragte Abfrage machen. Ich weiß nur nicht, ob die - mit dem Kernel 6.17.2 - das gewünschte Ergebnis bringt:

Code Select Expand


System:
  Kernel: 6.17.2-1-siduction-amd64 arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 6.3.6 Distro: siduction 2023.1.1 giants - kde -
    (202309091853)
Machine:
  Type: Laptop System: Acer product: Nitro AN515-58 v: V1.06
    serial: <superuser required>
  Mobo: ADL model: Jimny_ADH v: V1.06 serial: <superuser required>
    UEFI: Insyde v: 1.06 date: 04/20/2022
Battery:
  ID-1: BAT1 charge: 46.6 Wh (100%) condition: 46.6/57.5 Wh (81%)
CPU:
  Info: 14-core (6-mt/8-st) model: 12th Gen Intel Core i7-12700H bits: 64
    type: MST AMCP cache: L2: 11.5 MiB
  Speed (MHz): avg: 821 min/max: 400/4600:4700:3500 cores: 1: 821 2: 821
    3: 821 4: 821 5: 821 6: 821 7: 821 8: 821 9: 821 10: 821 11: 821 12: 821
    13: 821 14: 821 15: 821 16: 821 17: 821 18: 821 19: 821 20: 821
Graphics:
  Device-1: Intel Alder Lake-P GT2 [Iris Xe Graphics] driver: i915 v: kernel
  Device-2: NVIDIA GA104 [Geforce RTX 3070 Ti Laptop GPU] driver: nvidia
    v: 550.163.01
  Device-3: Chicony ACER HD User Facing driver: uvcvideo type: USB
  Display: wayland server: X.org v: 1.21.1.18 with: Xwayland v: 24.1.8
    compositor: kwin_wayland driver: X: loaded: modesetting,nvidia
    unloaded: fbdev,nouveau,vesa dri: iris gpu: i915
    resolution: 2560x1440~60Hz
  API: EGL v: 1.5 drivers: iris,nvidia,swrast
    platforms: gbm,wayland,x11,surfaceless,device
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: intel mesa v: 25.2.4-1
    renderer: Mesa Intel Iris Xe Graphics (ADL GT2)
  API: Vulkan v: 1.4.321 drivers: intel,nvidia,llvmpipe surfaces: N/A
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
    de: kscreen-console,kscreen-doctor gpu: nvidia-smi wl: wayland-info
    x11: xdriinfo, xdpyinfo, xprop, xrandr
Audio:
  Device-1: Intel Alder Lake PCH-P High Definition Audio
    driver: sof-audio-pci-intel-tgl
  Device-2: NVIDIA GA104 High Definition Audio driver: snd_hda_intel
  Device-3: DSEA A/S Headset [PC 8] driver: hid-generic,snd-usb-audio,usbhid
    type: USB
  API: ALSA v: k6.17.2-1-siduction-amd64 status: kernel-api
  Server-1: PipeWire v: 1.4.9 status: active
Network:
  Device-1: Intel Alder Lake-P PCH CNVi WiFi driver: iwlwifi
  IF: wlan0 state: down mac: <filter>
  Device-2: Realtek Killer E2600 GbE driver: r8169
  IF: enp43s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
  IF-ID-1: virbr0 state: down mac: <filter>
Bluetooth:
  Device-1: Intel AX201 Bluetooth driver: btusb type: USB
  Report: hciconfig ID: hci0 rfk-id: 0 state: down
    bt-service: enabled,running rfk-block: hardware: no software: yes
    address: <filter>
RAID:
  Hardware-1: Intel Volume Management Device NVMe RAID Controller driver: vmd
Drives:
  Local Storage: total: 4.57 TiB used: 2.75 TiB (60.3%)
  ID-1: /dev/nvme0n1 vendor: Samsung model: MZVL21T0HCLR-00B07
    size: 953.87 GiB
  ID-2: /dev/sda vendor: Samsung model: SSD 870 QVO 2TB size: 1.82 TiB
  ID-3: /dev/sdb vendor: Samsung model: SSD 870 EVO 2TB size: 1.82 TiB
    type: USB
Partition:
  ID-1: / size: 477.4 GiB used: 391.72 GiB (82.1%) fs: ext4
    dev: /dev/nvme0n1p5
  ID-2: /boot/efi size: 96 MiB used: 27 MiB (28.1%) fs: vfat
    dev: /dev/nvme0n1p1
Swap:
  Alert: No swap data was found.
Sensors:
  System Temperatures: cpu: 39.0 C mobo: 34.0 C
  Fan Speeds (rpm): cpu: 1818 fan-2: 1829
Info:
  Memory: total: 32 GiB note: est. available: 31.07 GiB used: 4.44 GiB (14.3%)
  Processes: 407 Uptime: 11m Shell: Bash inxi: 3.3.39


Frage:
Würde es etwas bringen ...

• zu warten, bis der nächste Kernel verfügbar ist, ...
• ein upgrade wie im Eingangspost beschrieben durchzuführen, ...
• den Rechner ordnungsgemäß runter zu fahren ...
• neuzustarten
• und wenn der neue Kernel einwandfrei bootet, den 6.17.3 mit kernel-remover zu entfernen?

[Teriarch]

Kannst Du vor dem Starten des 6.17.3-1 Kernels in die Linux Kernel Befehlszeile von Grub
(Du gelangst dahin mit Eingabe "e" im Auswahlmenue von Grub)
am Ende "break=init" eingeben, bevor Du den Kernel mit ctrl-x startest? Dann wirst Du nach
dem Kernelstart unmittelbar in eine shell der Initial Ramdisk abgesetzt, bevor überhaupt etwas
anderes passiert. Wenn udev den Timeout produziert, dann sollte das gelingen, da udev zu
diesem Zeitpunkt noch nicht gestartet ist. Anschließend kannst Du Dich mit weiteren Breakpoints
("break=rootmount", etc.) bis zum Anfang des Endes vorarbeiten.

[Isegrimm666]

Sorry für die verspätete Antwort, aber ich kam aus einigen Gründen erst heute dazu.

@Teriarch:

Hab ich versucht. Ich hab bin im Grub-Bildschirm mit "e" in die Parameter gewechselt, habe am Ende "break=init" eingegeben und mit "STRG-x" dem Bootvorgang gestartet.

Nichts.

Keine Shell, keine Breakpoints.

Dann habe ich den alten Kernel (6.17.2-1) nach einem Reboot gestartet, ... das System startete einwandfrei und wieder ein

Code Select Expand

doas apt update && doas apt --solver 3.0 full-upgrade

... gemacht, da mittlerweile der 6.17.4-1 raus ist.

Auch beim 6.17.4-1 geht es nach der Fehlermeldung nicht weiter.

Daraufhin habe ich das System erneut mit dem 6.17.2-1 gestartet und mit dem 'kernel-remover' den 6.17.3-1 entfernt, weil ich dachte, dass sich dadurch wieder einiges hinruckelt.

Auch danach startete das System nicht mit dem 6.17.4-1 ... alles ist beim alten ... der 6.17.2-1 ist der einzige, der das System startet.

[Teriarch]

Lass' uns den Kernel und die initial Ramdisk vergleichen:

$ md5sum /boot/vmlinuz-6.17.4-1-siduction-amd64
2820801aab026e2793cda892f7e4e5b0  /boot/vmlinuz-6.17.4-1-siduction-amd64

$ ls -la /boot/initrd.img-6.17.4-1-siduction-amd64
-rw-r--r-- 1 root root 205704320 20. Okt 00:44 /boot/initrd.img-6.17.4-1-siduction-amd64

Deine initrd sollte sich natürlich unterscheiden. Falls sich keine sensitiven Daten darin befinden,
kannst Du sie nach <https://wormhole.app> hochladen, und ich versuche den Fehler hier
nachzustellen (Vergiss nicht den Link und die Kernel Bootparameter in grub.cfg).

[Teriarch]

> ["break=init"]... Dann wirst Du nach dem Kernelstart unmittelbar in eine shell der Initial Ramdisk abgesetzt,
> bevor überhaupt etwas anderes passiert. Wenn udev den Timeout produziert, dann sollte
> das gelingen, da udev zu diesem Zeitpunkt noch nicht gestartet ist.

Ich hab' nochmal nachgeschaut. Die richtige Kerneloption ist "break=top". "break=init" setzt Dich unmittelbar
vor dem chroot ins real root fs ab, und das ist zu spät, da hier udevd schon läuft. Mit "break=top" solltest Du
eine shell bekommen, und das System sollte noch nicht einfrieren. Von da aus kann man dann weitersuchen...

[zefu]

hatte das identische Problem auf einem DELL Optiplex 7020. Nach dem Update auf Kernel 6.17.5-1-siduction-amd64 bootet er wieder problemlos

[Isegrimm666]

hatte das identische Problem auf einem DELL Optiplex 7020. Nach dem Update auf Kernel 6.17.5-1-siduction-amd64 bootet er wieder problemlos

Guten Morgen ...

Kann ich bestätigen. Mit dem eben installierten Kernel 6.17.5-1-siduction-amd64 bootet das System wieder einwandfrei.

Danke an alle, die mir geholfen haben ...