Stammtisch 2024-09-06: Unterschied zwischen den Versionen

Aus lugvswiki
Zur Navigation springenZur Suche springen
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 ...
 
Die Optionen ('''-r''' und '''-p''') in obigem Befehl 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 damit an:
 
# die Ausgabe der Abfrage ''journalctl'', jedoch
 
# mit Filterung 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)
 
  
 
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 &ndash; Holger hat sich (wieder) zwei Betriebssysteme, nämlich openSUSE ''Slowroll'' und Linux Mint mit Debianunterbau (''LMDE6''), installiert &ndash; läuft jetzt (wieder) wie geschmiert.
 
* Die virtuelle Maschinenverwaltung &ndash; Holger hat sich (wieder) zwei Betriebssysteme, nämlich openSUSE ''Slowroll'' und Linux Mint mit Debianunterbau (''LMDE6''), installiert &ndash; 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 gestrige Unverständnis des genutzten Befehls; speziell bezüglich der verwendeten Optionen.
+
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üglich kvm_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:

  1. die Ausgabe der Abfrage journalctl bezüglich den "KVM"-Paketen, jedoch
  2. mit Filterung der Ausgabe nur von Fehlern (Ziffer 3 = err) bezüglich der Abfrage nach dem "grep" und
  3. 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