Failed to mount swapfile

    Servus Zusammen,


    heute Nachmittag hatte ich eine unschöne Überraschung. Mein Rootserver RS1000 ist ausgefallen mit der Fehlermeldung "Failed to mound swapfile":
    Bildschirmfoto 2023-08-18 um 16.16.53.png


    Ich habe versucht mit der "Tastatur anzeigen" und dem Root Passwort Wartung vorzunehmen, doch "Anmeldung schlägt fehl".

    Im Rettungsmodus, ist von einer SWAP File nichts zu sehen "swapoff -a" bewirkt nichts.
    Neuinstallation ist die letzte Notlösung, aber möchte ich vorerst aufgrund des hohen Aufwands vermeiden.


    Darunter waren auch die Tipps vom Netcup Support. Jedoch bin ich noch zu keiner Lösung gekommen.
    Hatte schon mal jemand so ein Problem? Hat jemand eine Idee zur Lösung?

    Mit freundlichen Grüßen
    Erik Kiessig

  • Zur hilfreichsten Antwort springen

    Danke, nur ich komme gar nicht mehr zur /etc/fstab. Über SSH kommt port 22: Connection refused, beim Bildschirm funktioniert wie ich beschrieben habe das Root Passwort auch nicht und im Rettungsmodus sieht die /etc/fstab so aus (nichts von einer swapfile zusehen):

    # /etc/fstab - static file system information

    #

    # This file was deployed via grml-live's

    # ${GRML_FAI_CONFIG}/config/scripts/GRMLBASE/30-fstab script, using

    # ${GRML_FAI_CONFIG}/config/files/etc/fstab/GRMLBASE

    #

    # <filesystem> <mountpoint> <type> <options> <dump> <pass>

    proc /proc proc rw,nosuid,nodev,noexec 0 0

    none /proc/bus/usb usbfs defaults,noauto 0 0

    sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0

    devpts /dev/pts devpts noauto,mode=0622 0 0

    /dev/fd0 /media/floppy auto user,noauto,exec 0 0

    /dev/external /media/external auto user,noauto,exec,rw,uid=grml,gid=grml 0 0

    /dev/external1 /media/external1 auto user,noauto,exec,rw,uid=grml,gid=grml 0 0

    /dev/cdrom /media/cdrom auto user,noauto,exec,ro 0 0

    /dev/dvd /media/dvd auto user,noauto,exec,ro 0 0

    # some other examples:

    # /dev/hda1 /Grml ext3 dev,suid,user,noauto 0 2

    # //1.2.3.4/pub /smb/pub smbfs defaults,user,noauto,uid=grml,gid=grml 0 0

    # linux:/pub /beer nfs defaults 0 0

    # tmpfs /tmp tmpfs size=300M 0 0

    # none /proc/bus/usb usbfs defaults,nodev,noexec,nosuid,noauto,devgid=1001,devmode=664 0 0

    # 192.168.1.101:/backups /media/nfs nfs defaults,user,wsize=8192,rsize=8192 0 0

    #

    # Warning! Please do *not* change any lines below because they are auto-generated by.

    # If you want to disable rebuildfstab set CONFIG_FSTAB='no' in /etc/grml/autoconfig!

    # See 'man grml-udev-rebuildfstab' for more details about the following entries.

    overlay / overlay rw 0 0

    tmpfs /tmp tmpfs nosuid,nodev 0 0

    # Added by GRML /dev/sda3

    /dev/sda3 /media/sda3 ext4 noauto,user,dev,suid,exec 0 0 # /dev/sda3

    # Added by GRML /dev/sda2

    /dev/sda2 /media/sda2 ext4 noauto,user,dev,suid,exec 0 0 # /dev/sda2

    Im Rettungssystem musst Du zuerst Deine Partition mounten, auf der Dein eigenes /etc Verzeichnis vorhanden ist. Das Rettungssystem bootet nicht von Deinem RootFS, das ist ein Grml-Image.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Gefällt mir 1 Danke 1
    • Hilfreichste Antwort
    Zitat von erik

    ...und im Rettungsmodus sieht die /etc/fstab so aus (nichts von einer swapfile zusehen)...

    Im Rettungsmodus siehst du ja zunächst mal die fstab des Rettungssystems.

    Du musst zunächst die Partition deines eigenen Betriebssystem mounten und "chrooten" um an deiner eigenen fstab Änderungen vornehmen zu können.

    (Gibt es einen wiki-Artikel dazu)


    Ha, Killerbees war schneller. :)

    Vielen Dank für die Tipps, konnte nun die Swapfile deaktivieren. Hat jemand nen Tipp/Link, wie ich die Swapfile dann richtig anlegen kann, dass so ein Fehler nicht nochmal auftritt?

  • erik

    Hat einen Beitrag als hilfreichste Antwort ausgewählt.

  • erik

    Hat einen Beitrag als hilfreichste Antwort ausgewählt.

  • erik

    Hat einen Beitrag als hilfreichste Antwort ausgewählt.

    Wie hast du es denn beim ersten Versuch gemacht? Hat es überhaupt schon mal funktioniert`?

    Zitat von erik

    Vielen Dank für die Tipps, konnte nun die Swapfile deaktivieren. Hat jemand nen Tipp/Link, wie ich die Swapfile dann richtig anlegen kann, dass so ein Fehler nicht nochmal auftritt?

    Z.B. hier: Swap space anlegen. Ich weiss nicht, welche Distribution und Version du installiert hast, aber dort gibt es Anleitungen für verschiedene Distributionen. Und die Swappiness-Einstellung wird auch konform mit gängiger Meinung einfach mal vorsichtshalber auf 10 gesetzt ;) .

    Zitat von Olivetti

    krasse anleitung.


    btw. swappiness geht ja mittlerweile sogar bis 11 äh 200.

    Ja, habe ich da auch gelesen und jetzt mal an einem Server verifiziert. Auf 190 konnte ich es setzen (mittels sudo sysctl vm.swappiness=190), bei 210 hat er gemeckert. Wie lange ist das schon so? Die allermeisten, auch relativ neue Anleitungen im Netz gehen vom Maximalwert 100 aus.


    Da der Server (4C,8GB, Debian 11) eh ziemlich gelangweilt ist derzeit, obwohl ich ihm zum Test noch eine meiner Nextclouds zusätzlich "aufgebürdet" habe, haben Werte von 10,60 und 190 (natürlich) absolut gar keinen Unterschied gemacht. Im Swapfile finden sich irgendwelche 227 MB und die sind schon Tagen da drin ohne Änderung. Auch der Wert von 10 hat nicht dazu geführt, dass die wieder ins RAM geladen wurden. Ebensowenig wurde mehr ausgelagert mit dem Wert 190. Es gab eben keine Veranlassung, irgendwas auszulagern und offenbar wurden die irgendwann ausgelagerten Pages seit Tagen nicht gebraucht. Um dem Ding mal etwas zusätzliche Auslastung zu geben, habe ich dann noch YABS laufen lassen, mit dem (erwartungsgemäßen) Ergebnis, dass der Swap auch hier unverändert blieb und der Geekbench 6 Test (etwas überraschend) sogar nochmal etwas besser ausfiel als im Auslieferzustand vom 25.06., damals 1248/3935, heute 1457/4665.


    Insgesamt also: Wenn nichts geswappt werden muss, dann wird auch nichts geswappt, offenbar egal welcher Wert von vm.swappiness eingestellt ist. Insofern, wenn genug RAM vorhanden ist, dann ist es völlig egal, was da eingestellt ist. Was ja auch genau so sein sollte und deshalb keine große Überraschung ist. Und wenn nicht genug RAM vorhanden ist, dann wird man mit dem Swap auf Dauer nichts retten können, höchstens ein paar kurzzeitige Spitzen etwas abfedern. Hier mag dann das System, je nach eingestelltem Wert und Art der Überlastung, besser oder schlechter auf die Überlastung reagieren.

    Zitat von tab

    Wie lange ist das schon so?

    Laut Git seit Kernelversion 5.8, also August 2020: https://github.com/torvalds/li…0bb32e7319a6d164cb8c70ae2


    Oder um es anders zu formulieren: Seit Debian 11 (Bullseye) bzw. Ubuntu 20.04 (Focal Fossa) :)


    Ich kannte dieses 200er Feature vor dieser Forendiskussion allerdings auch noch nicht…

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    2 Mal editiert, zuletzt von KB19 ()

    Zitat von tab

    Wie lange ist das schon so? Die allermeisten, auch relativ neue Anleitungen im Netz gehen vom Maximalwert 100 aus.

    Dokumentiert seit 04.06.2020 (laut kernel/sysctl.c) also schätzungsweise kernel 5.6.
    Ja, weil eine Nase von der anderen Nase abschreibt und sie bisher vermutlich mit schnellstmöglichem swap nix am Hut hatten.


    Du hättest bei deinen Tests den swap jeweils vorher manuell leeren müssen, aber das ist in der Regel schon schwierig zu testen, um belastbare Aussagen zu bekommen.


    btw. wer kennt noch das absurde SoftRAM für Windows, das gefühlt 95% aller Windowsnutzer installiert hatten?!

    »Hauptsache BogoMIPS!«

    Fleischfresser

    4 Mal editiert, zuletzt von Olivetti () aus folgendem Grund: Jaaa, hab mich wieder mal von der Killerbiene abledern lassen, harhar.

    Muss ich mir mal genauer anschauen im Sourcecode. Ich vermute aber, dass sich dadurch hinter den Kulissen nicht viel verändert hat. Außer, dass mit Werten über 100 es jetzt auch möglich ist das Auslagern von Pages aus dem RAM in den Swapspace gegenüber dem manchmal notwendigen Schreiben von gecacheten Dateien zurück auf die Platte/SSD sogar zu bevorzugen, was mit Werten bis 100 davor nicht möglich war. Man ist also lediglich flexibler geworden durch die Änderung. Der Defaultwert von 60 (und alle anderen Werte <=100) bewirkt nach dieser Änderung also das selbe wie davor. Also 60 bleibt 60 und 10 bleibt 10 ;) .

    Sozusagen nötiger Tribut an RAM-Swaps:

    Zitat

    For in-memory swap, like zram or zswap, as well as hybrid setups that have swap on faster devices than the filesystem, values beyond 100 can be considered. For example, if the random IO against the swap device is on average 2x faster than IO from the filesystem, swappiness should be 133 (x + 2x = 200, 2x = 133.33).

    [aus obigem kernel.org-link]

    »Hauptsache BogoMIPS!«

    Fleischfresser

    Zitat von Olivetti

    btw. wer kennt noch das absurde SoftRAM für Windows, das gefühlt 95% aller Windowsnutzer installiert hatten?!

    Nö. Aber DoubleDisk, DriveSpace für die Platte und EMS386. Und irgendwas russisches das Ramkompression gemacht hat, was aber nie den Weg zu mir gefunden hat. Eine komprimierte Ramdisk ist ja an sich keine schlechte Idee, wenn das System darunter stabil genug ist.