Stammtisch 2024-09-06: Unterschied zwischen den Versionen
Zeile 36: | Zeile 36: | ||
Dieser, den Fehler offensichtlich aufdeckenden Abfrage, gingen noch viele andere voraus, wie zum Beispiel: <code>sudo '''dmesg | grep -i kvm'''</code>, <code>sudo '''dmesg | grep -i vm'''</code>, <code>sudo '''lsmod | grep -i kvm'''</code> (und weitere), die aber in diesem Fall nicht sonderlich hilfreich waren ... | Dieser, den Fehler offensichtlich aufdeckenden Abfrage, gingen noch viele andere voraus, wie zum Beispiel: <code>sudo '''dmesg | grep -i kvm'''</code>, <code>sudo '''dmesg | grep -i vm'''</code>, <code>sudo '''lsmod | grep -i kvm'''</code> (und weitere), die aber in diesem Fall nicht sonderlich hilfreich waren ... | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Holgers (Tower-)PC hat ein Motherboard mit AMD, wie diese Abfrage mit dem Befehl ''inxi'' zeigt: | Holgers (Tower-)PC hat ein Motherboard mit AMD, wie diese Abfrage mit dem Befehl ''inxi'' zeigt: | ||
Zeile 83: | Zeile 57: | ||
* Die virtuelle Maschinenverwaltung – Holger hat sich (wieder) zwei Betriebssysteme, nämlich openSUSE ''Slowroll'' und Linux Mint mit Debianunterbau (''LMDE6''), installiert – läuft jetzt (wieder) wie geschmiert. | * Die virtuelle Maschinenverwaltung – Holger hat sich (wieder) zwei Betriebssysteme, nämlich openSUSE ''Slowroll'' und Linux Mint mit Debianunterbau (''LMDE6''), installiert – läuft jetzt (wieder) wie geschmiert. | ||
− | * Jedoch gibt obige Abfrage noch aus, dass der Pfad <code>'''/dev/kvm'''</code> nicht geöffnet werden kann; da es aber eine Journalabfrage ist und kein neuerer Fehler bezüglich <code>'''kvm_amd: SVM not supported by CPU 4'''</code> kommt (die Fehler sind nach Datum und Uhrzeit von unten nach oben nach dem jüngsten Erscheinen sortiert), ist zumindest ein Problem gelöst. | + | * Jedoch gibt obige Abfrage immer noch aus, dass der Pfad <code>'''/dev/kvm'''</code> nicht geöffnet werden kann; da es aber eine Journalabfrage ist und kein neuerer Fehler bezüglich <code>'''kvm_amd: SVM not supported by CPU 4'''</code> kommt (die Fehler sind nach Datum und Uhrzeit von unten nach oben nach dem jüngsten Erscheinen sortiert), ist zumindest ein Problem gelöst. |
* Warum der Pfad <code>'''/dev/kvm'''</code> noch immer nicht geöffnet werden kann, und ob das nach einem Distributionsupdate per | * Warum der Pfad <code>'''/dev/kvm'''</code> noch immer nicht geöffnet werden kann, und ob das nach einem Distributionsupdate per | ||
Zeile 89: | Zeile 63: | ||
und anschließendem Neustart noch immer besteht, muss Holger noch abklären. | und anschließendem Neustart noch immer besteht, muss Holger noch abklären. | ||
+ | |||
+ | ---- | ||
+ | |||
+ | ===== NACHTRAG zum Nachtrag ===== | ||
'''Erklärung zu den letzten beiden Punkten:''' | '''Erklärung zu den letzten beiden Punkten:''' | ||
− | Die obige Frage zeigt Holgers | + | Die obige Frage zeigt Holgers gestriges Unverständnis des genutzten Befehls; speziell bezüglich der verwendeten Optionen. |
− | Wie gleich unten dargestellt, sind diese ''journalctl-Abfragen'' ja mit Datum und Uhrzeit gekennzeichnet (Optionen nun etwas verändert, um nicht ''nur'' die Fehler anzuzeigen; die umgekehrte Ausgabe-Reihenfolge des Journals wurde beibehalten): | + | |
+ | Die Optionen ('''-r''' und '''-p''') im oben verwendeten Befehl '''# journalctl -r -p 3 | grep kvm'''</code> bedeuten laut Manual von ''journalctl'': | ||
+ | |||
+ | <$> benutzer:~> '''man journalctl''' (Seite 1 des Manuals mit Enter bestätigen) | ||
+ | |||
+ | ... | ||
+ | |||
+ | '''-r, --reverse''' | ||
+ | Invertiert die Ausgabe, so dass die neusten Einträge zuerst dargestellt werden. | ||
+ | |||
+ | ... | ||
+ | |||
+ | '''-p, --priority=''' | ||
+ | Filtert die Ausgabe nach Nachrichtenprioritäten oder Prioritätsbereichen. | ||
+ | Akzeptiert entweder eine einzelne numerische oder textuelle Protokollstufe | ||
+ | '''(d.h. zwischen 0/»emerg« und 7/»debug«)''' oder einen Bereich von | ||
+ | numerischen/textuellen Protokollstufen in der Form VON..BIS. Die | ||
+ | Protokollstufen sind die normalen Syslog-Protokollstufen, wie sie in syslog(3) | ||
+ | dokumentiert sind, d.h. »emerg« (0), »alert« (1), »crit« (2), '''»err« (3),''' | ||
+ | »warning« (4), »notice« (5), »info« (6), »debug« (7). Falls eine einzelne | ||
+ | Protokollstufe angegeben ist, werden alle Nachrichten mit dieser Protokollstufe | ||
+ | oder einer niedrigeren (daher wichtigeren) Protokollstufe angezeigt. Falls ein | ||
+ | Bereich angegeben ist, werden alle Nachrichten innerhalb des Bereichs | ||
+ | angezeigt, einschließlich des Start- und des Endwertes des Bereichs. Dies wird | ||
+ | »PRIORITY=«-Treffer für die angegebenen Prioritäten hinzufügen. | ||
+ | |||
+ | Wenn Holger das richtig versteht, zeigt obige Abfrage <code>'''# journalctl -r -p 3 | grep kvm'''</code> damit an: | ||
+ | # die Ausgabe der Abfrage ''journalctl'' bezüglich den "KVM"-Paketen, jedoch | ||
+ | # mit Filterung der Ausgabe ''nur von Fehlern'' (Ziffer '''3''' = '''err''') bezüglich der Abfrage nach dem "grep" und | ||
+ | # zuerst die neuen, danach ältere Warnmeldungen (also umgekehrte Reihenfolge des Auftretens) | ||
+ | |||
+ | Wie gleich unten dargestellt, sind diese ''journalctl-Abfragen'' ja mit Datum und Uhrzeit gekennzeichnet (Optionen nun etwas verändert, um nicht ''nur'' die Fehler anzuzeigen; die umgekehrte Ausgabe-Reihenfolge des Journals ("invertiert") wurde beibehalten): | ||
<$> benutzer::~> '''sudo journalctl -r | grep kvm''' | <$> benutzer::~> '''sudo journalctl -r | grep kvm''' | ||
[sudo] Passwort für holger: | [sudo] Passwort für holger: | ||
− | Hier sehen wir zunächst die Ausgabe (ohne Fehler, aber mit Funktionsbestätigung) vom 6. September, von 23:22:25 Uhr an; das war nach der Änderung der BIOS-Einstellungen und dem darauffolgenden Neustart: | + | Hier sehen wir zunächst die mit umgekehrtem Datum- / Zeitstempel versehene Ausgabe (ohne Fehler, aber mit Funktionsbestätigung) vom 6. September, von 23:22:25 Uhr an; das war ''nach'' der Änderung der BIOS-Einstellungen und dem darauffolgenden Neustart: |
<pre style="color: green">Sep 07 19:04:26 aelbler kernel: kvm_amd: Virtual GIF supported | <pre style="color: green">Sep 07 19:04:26 aelbler kernel: kvm_amd: Virtual GIF supported | ||
Sep 07 19:04:26 aelbler kernel: kvm_amd: Virtual VMLOAD VMSAVE supported | Sep 07 19:04:26 aelbler kernel: kvm_amd: Virtual VMLOAD VMSAVE supported |
Version vom 7. September 2024, 18:56 Uhr
06.09.2024 - 20:00 Uhr, Online-Stammtisch auf https://bbb.ch-open.ch/rooms/ulf-nm2-y26/join
wöchentlicher Online-Stammtisch
Auf dem Stammtisch Mai 2020 beschlossener wöchentlicher Stammtisch jeden Freitag ab 20:00 Uhr anstelle des monatlichen Stammtisches im realen Leben.
Anwesende
- Holger
- Ulf
- Ulf
- Plocki
- Rainer
Themen
Virtualisierung mit Qemu/KVM nicht möglich
Seit Monaten hat Holger schon Probleme mit seiner Virtualisierungssoftware; mit (sinngemäßem) Inhalt der Fehlermeldung:
KVM ist entweder nicht installiert, oder die Module werden nicht geladen.
Das wirkt sich dann so aus, dass die installierten virtuellen Maschinen extrem langsam laufen (mehrere Minuten Wartezeit bis zum Einloggen oder bis Anwendungen reagieren). Das war früher nicht so.
Ulf und auch Plocki unterstützen Holger per Bildschirmteilung bei der Fehlersuche per Konsole. Mit dieser Abfrage kommt Licht ins Dunkle:
<#> benutzer:/home/holger # journalctl -r -p 3 | grep kvm Sep 06 20:47:52 benutzer virtqemud[5415]: Kann /dev/kvm nicht öffnen: Datei oder Verzeichnis nicht gefunden Sep 06 20:45:31 benutzer virtqemud[1857]: Kann /dev/kvm nicht öffnen: Datei oder Verzeichnis nicht gefunden Sep 06 20:42:13 benutzer virtqemud[75903]: Kann /dev/kvm nicht öffnen: Datei oder Verzeichnis nicht gefunden Sep 06 20:42:05 benutzer virtqemud[75903]: Kann /dev/kvm nicht öffnen: Datei oder Verzeichnis nicht gefunden Sep 06 20:30:47 benutzer kernel: kvm_amd: SVM not supported by CPU 4
Dieser, den Fehler offensichtlich aufdeckenden Abfrage, gingen noch viele andere voraus, wie zum Beispiel: sudo dmesg | grep -i kvm
, sudo dmesg | grep -i vm
, sudo lsmod | grep -i kvm
(und weitere), die aber in diesem Fall nicht sonderlich hilfreich waren ...
Holgers (Tower-)PC hat ein Motherboard mit AMD, wie diese Abfrage mit dem Befehl inxi zeigt:
<$> benutzer:~> inxi CPU: 6-core AMD Ryzen 5 5600G with Radeon Graphics (-MT MCP-) speed/min/max: 1539/400/4464 MHz Kernel: 6.10.7-1-default x86_64 Up: 2h 30m Mem: 5.52/31.14 GiB (17.7%) Storage: 5.69 TiB (26.6% used) Procs: 405 Shell: Bash inxi: 3.3.35 benutzer:~>
Es scheint so zu sein, dass sich in den BIOS-Einstellungen etwas verstellt hat (eventuell durch ein Kernelupdate?): ASUS-BIOS. Vorstehender Link scheint die Lösung zu bieten. Holger wird das später ausprobieren und hier noch dokumentieren.
NACHTRAG Virtualisierung Qemu/KVM nicht möglich
- Tatsächlich war in Holgers BIOS unter dem Reiter "Advanced / CPU Configuration" der "SVM-Mode" deaktiviert. Nachdem Holger diesen aktiviert (enabled) und die Änderung mit dem Shortcut F10 im BIOS übernommen hat, startet er den Rechner neu.
- Danach startet er seine Anwendung VM (Virtuelle Maschinenverwaltung) und er hat (innerhalb der grafischen Benutzeroberfläche der virtuellen Maschine) keine Fehlermeldung mehr.
- Die virtuelle Maschinenverwaltung – Holger hat sich (wieder) zwei Betriebssysteme, nämlich openSUSE Slowroll und Linux Mint mit Debianunterbau (LMDE6), installiert – läuft jetzt (wieder) wie geschmiert.
- Jedoch gibt obige Abfrage immer noch aus, dass der Pfad
/dev/kvm
nicht geöffnet werden kann; da es aber eine Journalabfrage ist und kein neuerer Fehler bezüglichkvm_amd: SVM not supported by CPU 4
kommt (die Fehler sind nach Datum und Uhrzeit von unten nach oben nach dem jüngsten Erscheinen sortiert), ist zumindest ein Problem gelöst.
- Warum der Pfad
/dev/kvm
noch immer nicht geöffnet werden kann, und ob das nach einem Distributionsupdate per
<$> benutzer: :~> sudo zypper dup
und anschließendem Neustart noch immer besteht, muss Holger noch abklären.
NACHTRAG zum Nachtrag
Erklärung zu den letzten beiden Punkten: Die obige Frage zeigt Holgers gestriges Unverständnis des genutzten Befehls; speziell bezüglich der verwendeten Optionen.
Die Optionen (-r und -p) im oben verwendeten Befehl # journalctl -r -p 3 | grep kvm bedeuten laut Manual von journalctl:
<$> benutzer:~> man journalctl (Seite 1 des Manuals mit Enter bestätigen) ... -r, --reverse Invertiert die Ausgabe, so dass die neusten Einträge zuerst dargestellt werden. ... -p, --priority= Filtert die Ausgabe nach Nachrichtenprioritäten oder Prioritätsbereichen. Akzeptiert entweder eine einzelne numerische oder textuelle Protokollstufe (d.h. zwischen 0/»emerg« und 7/»debug«) oder einen Bereich von numerischen/textuellen Protokollstufen in der Form VON..BIS. Die Protokollstufen sind die normalen Syslog-Protokollstufen, wie sie in syslog(3) dokumentiert sind, d.h. »emerg« (0), »alert« (1), »crit« (2), »err« (3), »warning« (4), »notice« (5), »info« (6), »debug« (7). Falls eine einzelne Protokollstufe angegeben ist, werden alle Nachrichten mit dieser Protokollstufe oder einer niedrigeren (daher wichtigeren) Protokollstufe angezeigt. Falls ein Bereich angegeben ist, werden alle Nachrichten innerhalb des Bereichs angezeigt, einschließlich des Start- und des Endwertes des Bereichs. Dies wird »PRIORITY=«-Treffer für die angegebenen Prioritäten hinzufügen.
Wenn Holger das richtig versteht, zeigt obige Abfrage # journalctl -r -p 3 | grep kvm
damit an:
- die Ausgabe der Abfrage journalctl bezüglich den "KVM"-Paketen, jedoch
- mit Filterung der Ausgabe nur von Fehlern (Ziffer 3 = err) bezüglich der Abfrage nach dem "grep" und
- zuerst die neuen, danach ältere Warnmeldungen (also umgekehrte Reihenfolge des Auftretens)
Wie gleich unten dargestellt, sind diese journalctl-Abfragen ja mit Datum und Uhrzeit gekennzeichnet (Optionen nun etwas verändert, um nicht nur die Fehler anzuzeigen; die umgekehrte Ausgabe-Reihenfolge des Journals ("invertiert") wurde beibehalten):
<$> benutzer::~> sudo journalctl -r | grep kvm [sudo] Passwort für holger:
Hier sehen wir zunächst die mit umgekehrtem Datum- / Zeitstempel versehene Ausgabe (ohne Fehler, aber mit Funktionsbestätigung) vom 6. September, von 23:22:25 Uhr an; das war nach der Änderung der BIOS-Einstellungen und dem darauffolgenden Neustart:
Sep 07 19:04:26 aelbler kernel: kvm_amd: Virtual GIF supported Sep 07 19:04:26 aelbler kernel: kvm_amd: Virtual VMLOAD VMSAVE supported Sep 07 19:04:26 aelbler kernel: kvm_amd: LBR virtualization supported Sep 07 19:04:26 aelbler kernel: kvm_amd: Nested Paging enabled Sep 07 19:04:26 aelbler kernel: kvm_amd: Nested Virtualization enabled Sep 07 19:04:26 aelbler kernel: kvm_amd: TSC scaling supported Sep 07 00:23:35 aelbler sudo[14401]: holger : TTY=pts/2 ; PWD=/home/holger ; USER=root ; COMMAND=/usr/bin/ls /sys/module/kvm Sep 07 00:23:16 aelbler sudo[14391]: holger : (command continued) /sys/module/i2c_piix4 /sys/module/i8042 /sys/module/ima /sys/module/ intel_idle /sys/module/intel_rapl_common /sys/module/intel_rapl_msr /sys/module/ip_tables /sys/module/ipv6 /sys/module/iwlmvm /sys/module/iwlwifi /sys/module/jbd2 /sys/module/k10temp /sys/module/kdb /sys/module/kernel /sys/module/keyboard /sys/module/kfence /sys/module/kgdboc /sys/module/kvm /sys/module/kvm_amd /sys/module/libahci /sys/module/libarc4 /sys/module/libata /sys/module/libcrc32c /sys/module/libphy /sys/module/llc /sys/module/loop /sys/module/mac80211 /sys/module/mbcache /sys/module/mc /sys/module/mdio_devres /sys/module/memory_hotplug /sys/module/microcode /sys/module/module /sys/module/mousedev /sys/module/msr /sys/module/netpoll /sys/module/nf_conntrack /sys/module/nf_defrag_ipv4 /sys/module/nf_defrag_ipv6 /sys/module/nf_nat /sys/module/nfnetlink /sys/module/nf_reject_ipv4 /sys/module/nf_tables /sys/module/nft_chain_nat Sep 06 23:47:55 aelbler kernel: kvm: SMP vm created on host with unstable TSC; guest TSC will not be reliable Sep 06 23:22:25 aelbler kernel: kvm_amd: Virtual GIF supported Sep 06 23:22:25 aelbler kernel: kvm_amd: Virtual VMLOAD VMSAVE supported Sep 06 23:22:25 aelbler kernel: kvm_amd: LBR virtualization supported Sep 06 23:22:25 aelbler kernel: kvm_amd: Nested Paging enabled Sep 06 23:22:25 aelbler kernel: kvm_amd: Nested Virtualization enabled Sep 06 23:22:25 aelbler kernel: kvm_amd: TSC scaling supported
...
Und hier sehen wir die gestrigen (und auch schon seit Monaten vorliegenden Fehler) vor Änderung der BIOS-Einstellungen, bis um 20:45:31 Uhr:
Sep 06 20:47:52 aelbler virtqemud[5415]: Kann /dev/kvm nicht öffnen: Datei oder Verzeichnis nicht gefunden Sep 06 20:45:31 aelbler virtqemud[1857]: Kann /dev/kvm nicht öffnen: Datei oder Verzeichnis nicht gefunden Sep 06 20:42:13 aelbler virtqemud[75903]: Kann /dev/kvm nicht öffnen: Datei oder Verzeichnis nicht gefunden Sep 06 20:42:05 aelbler virtqemud[75903]: Kann /dev/kvm nicht öffnen: Datei oder Verzeichnis nicht gefunden Sep 06 20:32:16 aelbler sudo[75224]: holger : TTY=pts/3 ; PWD=/home/holger ; USER=root ; COMMAND=/usr/sbin/lsmod kvm Sep 06 20:30:47 aelbler kernel: kvm_amd: SVM not supported by CPU 4
Anwendungsbeispiel der Spracherkennungssoftware Whisper
Plocki fragt, warum wir heute Whisper noch einmal behandeln.
- Bertram bittet um Klärung, ob sein vor kurzem erstelltes Video so veröffentlicht werden kann. Er ist sich noch unsicher, ob es unter Ubuntu und Mint so nachvollzogen werden kann.
- Plocki merkt an, dass je nach zugrundeliegendem Betriebssystem / Distribution es sehr schwierig ist, für verschiedene mögliche Betriebssystembenutzer die Installation von Whisper zu erklären. Sogar auf der Projektseite von Git ist die Anleitung (je nach Betriebssystem) nicht nachvollziehbar.
- Auch erzählt Plocki von seiner ehrenamtlichen liftuktraine.org Arbeit in der Ukraine, wo Whisper schon sehr praktisch verwendet wird. Er hat ein kleines Team sehr gescheiter Leute, die ihn technisch unterstützen. Der Verein betreibt ein Portal, in dem Videos hochgeladen werden. So sollen die Hilfeleistungen durch die Empfänger dokumentiert werden (sonst könnte vieles "verschwinden" / Korruption) und diese Videos werden für die Spender öffentlich gemacht. Die Videos werden ins vereinseigene Portal hochgeladen und danach erstellt die Spracherkennungssoftware Whisper aus dem Video mit ukrainischem Original-Audio-Ton ein Video mit englischen Untertiteln. Super!
Bug bei Betrams Betriebssystem LMDE6
- Bertram hat auf seinem Linux Mint (Debian-Unterbau) seit einem Update Probleme. Obwohl sein Funknetzwerk deaktiviert ist, hat er im Rahmen seines Laptopbildschirms eine leuchtende Diode in Form eines "Funkturms". Er teilt den Bildschirm und nach einem Klick auf das Internetsymbol seiner Taskleiste sehen wir, dass das Funknetzwerk ausgeschaltet ist. Dennoch leuchtet die (für uns unsichtbare) Diode im Bildschirmrahmen von Bertrams Laptop.
- Ulf meint, am besten wäre es mal, zu warten, ob ein weiteres Kernelupdate diesen Fehler – der ja vorher nie auftrat – wieder behebt. Es ist nicht nur so, dass die Diode des Funknetzwerks dauerhaft leuchtet, obwohl sie laut Mint deaktiviert ist, sondern er muss nun nach jedem Hochfahren des Rechners auch noch die Bluetooth-Funktion deaktivieren, obwohl dies zuvor nur aktiv war, wenn er sie manuell aktivierte.
- Ulf und Plocki vermuten, dass es sich hier um einen Bug handelt und den sollte man idealerweise melden, damit er in einem weiteren Update behoben wird und auch andere Nutzer, die das eventuell auch bemängeln (aber nicht melden) auch davon Nutzen ziehen.
- Plocki gibt noch den Tipp, dass es sich eventuell im BIOS deaktivieren ließe (Holzhammermethode); dann ist es aber fraglich, ob er in zwölf Monaten noch weiß, was er da verstellt hat. Und andere haben keinen Nutzen, weil der Bug nicht beseitigt wird.
- Ulf weist darauf hin, dass unter Plasma KDE bei unerwartetem Absturz einer KDE-Anwendung ein Pop-Up aufgeht, in dem Systeminformationen und Fehlerberichte schon hinterlegt sind und den man um zusätzliche Infos (was man gerade gemacht hat, etc.) hinterlegen kann und dann absendet. Bei Bugs wie bei Bertram funktioniert das natürlich nicht, weil diese Fehler erst mal entdeckt werden müssen und sein Bug ja auch keine technischen Fehler produziert.
- Holger ermutigt Bertram dazu, sich doch erst einmal ins Forum von Linux-Mint zu begeben und nach seinem Fehler zu suchen. Sollte er dort noch unbekannt sein, kann man ihn auch da melden; ansonsten wird sich da sicherlich jemand des Bugs annehmen.
Zurück zur Übersicht