Guten Morgen ...
Ich habe gerade ein:
doas apt update && doas apt --solver 3.0 full-upgrade durchgeführt.
Nach einem ...
doas apt autoremove && doas /sbin/reboot now... startete der Rechner mit folgender Fehlermeldung:
Quote[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:
QuoteTimed 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:
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:12hLösung in: https://forum.siduction.org/index.php?topic=9812.msg78055#msg78055 (https://forum.siduction.org/index.php?topic=9812.msg78055#msg78055)
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
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... 8)
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
sudo sysctl kernel.unprivileged_bpf_disabled=1 richtet keinen Schaden an.
Warum der Rechner nun einfriert, kann ich dir natürlich nicht sagen.
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.
Quote from: towo on 2025/10/16, 14:12:12
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:
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?
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.
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
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.
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).
> ["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...
hatte das identische Problem auf einem DELL Optiplex 7020. Nach dem Update auf Kernel 6.17.5-1-siduction-amd64 bootet er wieder problemlos
Quote from: zefu on 2025/10/24, 13:32:02
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 ... :)