Ich habe kürzlich unter Leap 15.5 (ohne BTRFS) bei einer Fehlersuche einen zusätzlichen Kernel per Yast installiert und später deinstalliert. (Die vorher vorhandenen Kernel waren durch Einträge in /etc/zypp/zypp.conf geschützt)
Danach waren die beiden Symlinks in /boot noch falsch. Die habe ich repariert und die Kiste bootete danach augenscheinlich OK.
Gibt es evtl. noch irgendwas, was man reparieren muss?
Ich würde erstmal dafür sorgen, dass man das Log des Linux beim nächsten Boot noch lesen kann. Dazu muss in /etc/systemd/journald.conf was geändert werden:
Unter die Kommentarzeile #Storage=auto kommt eine Zeile Storage=persistent. Damit das Log nicht zu groß wird kommt unter #SystemMaxUse= z.B. die Zeile SystemMaxUse=200M.
Beim nächsten Boot nach dem Absturz kann man dann als root mit journalctl -b-1 das Log vom vorigen Lauf lesen. Vielleicht gibt es da ja irgendwelche Anhaltspunkte.
Dann gibt es noch sehr nebulöse Hinweise im Netz, dass nach längerer Laufzeit auftretende Probleme in virtuellen Maschinen weg gehen, wenn man der VM weniger als die Hälfte der Cores und weniger als die Hälfte des RAMs gibt. Das hat bei mir tatsächlich mal funktioniert bis eine neue Version das eigentliche Problem beseitigt hat. Das ist aber (wenn es denn funktioniert) nur ein Workaround und trägt nichts zur Fehlerbeseitigung bei.
Ich bin vor langer Zeit von kmail auf claws-mail umgestiegen und kann nur über die Lösung des Problems in claws reden. Aber in kmail geht es vermutlich ähnlich weil MH eines der Standardformate für lokale Mailspeicherung ist:
Legt man zusätzlich MH-Mailboxen an und kopiert die Mails der IMAP-Mailboxen dorthin, dann bekommt man ziemlich genau das von Dir gewünschte: Verzeichnisse, die die Struktur der Mailboxen und Untermailboxen wiederspiegeln mit einer Datei pro Mail.
...Pakete für den 46er sind im Yast jedenfalls nicht zu sehen....
Wenn Du im Yast bei "zurückgeholte installierte Pakete" den "kernel-default" anwählst (also nicht das Feld ganz links in der Zeile anklicken!) und dann unten auf den Reiter "Versionen" gehst, dann sollten dort die Versionen sichtbar sein (bei mir mehr als ein halbes Dutzend).
Dort kann man dann einzelne Versionen löschen/installieren.
Wenn man aber im oberen Feld löschen würde, dann würde man alle Versionen des Pakets löschen und das wäre fatal. Ich kann mir vorstellen, dass das bei Dachstein passiert ist und er das noch rechtzeitig gemerkt hat.
Eine gute Idee hab ich nicht mehr ... aber vielleicht einen Workaround:
Vielleicht hilft ein Upgrade der virtuellen Hardware...
Wenn man eine neue Vmware-Version benutzt dann ändert sich die virtuelle Hardware nicht. Wenn man also eine virtuelle Maschine mit der Workstation 14 angelegt hat und sie mit Workstation 17 ausführt, dann ist das immer noch die virtuelle Hardware von damals.
Die Hardware-Version wird vor dem Start der VM angezeigt. Stammt sie von der WS17, dann sollte da "20" stehen. Die Zahl steht auch in der vmx-Datei im Eintrag "virtualHW.version".
Man kann diesen Eintrag in der vmx-Datei mit einem Text-Editor im Host ändern. Beim nächsten Start des Gastes sieht das Gast-System dann die neue virtuelle Hardware. Erfahrungsgemäß hat das Gast-Betriebssystem keine Probleme mit etwas modernerer virtueller Hardware ... aber man sollte trotzdem sicherheitshalber die virtuelle Maschine vorher kopieren.
Evtl. hat die Workstation Pro dafür einen Menüpunkt, so dass man sich das Editieren der vmx-Datei sparen kann. Mein Workstation Player hat kein solches Menü.
Diesmal sieht es besser aus bei der Ausführung als User (/home/admin/... statt /root/... für das log). Das war also wohl nicht das Problem.
Welches supertuxkart ist das eigentlich? ("rpm -qi supertuxkart")
Im Hauptrepo gibt es supertuxkart-1.3-bp154.1.37
Im Gamesrepo gibt es /supertuxkart-1.4-lp154.79.2
Falls Du das 1.3 hast und das 1.4 ausprobieren willst: Im Yast zu den Repos
"Games" hinzufügen und dabei als URL
http://download.opensuse.org/repositories/games/15.4/
angeben. Danach kann man bei der Softwareauswahl im Reiter "Versionen" wechseln.
Beim Spiel als User ist was schwer durcheinander. Da taucht das Home-Verzeichnis von "root" auf und der User heißt "admin". Hast Du versucht, User und Administrator irgendwie miteinander zu koppeln? (Das wäre in Windows normal und ist in Linux ein absolutes NoGo.)
Kann ich diese Bezeichnungen mit den Festplattenpartitionen sda, sdb, etc. in Einklang bringen, also kontrollieren ob diese Zuordnung passt?
ll /dev/disk/by-uuid/Dann wird aber nicht auf meine Eingabe gewartet...
Da scheint das Timeout bei der Passworteingabe kaputt zu sein.
Vor einigen Jahren gab es mal in Suses so ein Problem. Es trat nur auf, wenn in der /etc/fstab im vierten Feld der betreffenden Zeile "nofail" stand und verschwand, wenn man "default" in dieses Feld eingetragen hat. Vielleicht hast Du Glück und es ist bei Dir auch so...
An diesem Timeout-Verhalten wurde aber irgendwann in letzter Zeit gearbeitet: früher kam immer der Emergency-Mode wenn man nicht rechtzeitig das Passwort getippt hat. Als ich es heute ausprobieren wollte hat er Rechner ohne Ende gewartet (auf einem "nur 15.4" - Laptop)
Oder man schreibt
cd `date --date='yesterday' +%Y%m%d`