it-swarm.com.de

"Verwaiste Inoden löschen" und Statusverlust im Ruhezustand wird fortgesetzt

Ich habe einen neuen 16.04 LTS installiert. Ich habe einige Probleme mit dem Anzeigefehler des Wifi-Applets (nach dem Fortsetzen von Suspend) und mit dem Fortsetzen des Ruhezustands festgestellt. Ich habe den Ruhezustand im Menü mit der gezeigten Methode aktiviert hier . Jetzt funktioniert der Ruhezustand nicht mehr mit Unterbrechungen. Manchmal funktioniert es einwandfrei, manchmal wird im Lebenslauf ein Text angezeigt, der etwas über das "Löschen verwaister Inodes" aussagt, und das System wird einfach neu gestartet, ohne den vorherigen Speicherstatus.

Hier einige Infos:

$ Sudo blkid
/dev/sda1: LABEL="System Reserved" UUID="50921EE4921ECE7A" TYPE="ntfs" PARTUUID="dda192f8-01"
/dev/sda2: LABEL="Primary Disk" UUID="765E305F5E3019F7" TYPE="ntfs" PARTUUID="dda192f8-02"
/dev/sda3: LABEL="Secondary Disk" UUID="E2D42C6AD42C42E1" TYPE="ntfs" PARTUUID="dda192f8-03"
/dev/sda5: UUID="dbaad068-46da-4637-9c45-5c32c20d3cfe" TYPE="swsuspend" PARTUUID="dda192f8-05"
/dev/sda6: UUID="31385b29-f351-4a10-9dcf-c92efd58334b" TYPE="swap" PARTUUID="dda192f8-06"
/dev/sda7: UUID="1f734f56-7328-4029-88a0-fa995426d4d2" TYPE="ext4" PARTUUID="dda192f8-07"

$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=31385b29-f351-4a10-9dcf-c92efd58334b
2
thethakuri

Nun, ich bin überrascht, dass dies niemand vorgeschlagen hat, da ich dieses Problem schon seit einiger Zeit habe. Die Antwort schien direkt in mein Gesicht zu starren. Anscheinend war meine Swap-Partition ungefähr so ​​groß wie mein Speicher. Außerdem habe ich den Link zur UUID meiner Swap-Partition in meiner Grub-Datei nicht hinzugefügt. Nachdem die Größe der Swap-Partition auf das Doppelte des Arbeitsspeichers erhöht und die UUID in die Grub-Datei eingefügt wurde, funktioniert der Ruhezustand in den letzten Tagen normal. Der Lebenslauf aus dem Ruhezustand dauert zwar etwas länger, aber ich beschwere mich nicht.

Sie müssen sicherstellen, dass Ihre Swap-Partition in den folgenden Dateien definiert ist:

  • /etc/initramfs-tools/conf.d/resume
  • /etc/default/grub

UPDATE

Durch die Verwendung der Low-Level-Benutzeroberfläche uswsusp als Standardmechanismus für den Ruhezustand konnte ich meine Wiederaufnahmezeit drastisch auf unter eine Minute verkürzen !!!

Sudo apt-get install uswsusp

Erstelle die Datei /etc/pm/config.d/00sleep_module und füge folgende Zeile hinzu:

  • SLEEP_MODULE="uswsusp"
1
thethakuri

Ich habe nur genau das gleiche Problem "behoben" und werde daher hier meine Lösung anbieten, auch wenn Ihr Problem anders ist.

Ich habe zuerst die by-uuid -Probleme durchlaufen (als ich systemd entfernt habe, dachte ich, sysvinit könnte dazu führen, dass die Gerätereihenfolge durcheinander gerät, wie an anderer Stelle vorgeschlagen, und ein UUID-Verweis hätte das Problem lösen sollen. Zumindest dachte ich das.

Es schien eine oder zwei Wochen lang gut zu sein, dann ging es wieder los.

Danach erinnerte ich mich, welche Probleme ich mit Gentoo hatte, wo ich den resume=/dev/disk/by-uuid/{} explizit in grub.cfg setzen musste, sonst wurde es nicht fortgesetzt, egal was passierte. Dort hat es mein Problem behoben. Ich habe sogar dracut installiert, um meine initramfs zu verwalten. Es hat wieder eine Weile geklappt, dann nicht.

Dann habe ich verschiedene Dinge ausprobiert, wie das Herunterstufen des Kernels, das Installieren von bootlogd, aber nichts deutete auf etwas Besonderes hin.

Zu diesem Zeitpunkt fing ich an, nach mehr Hilfe zu suchen. Ich habe alle - nicht ganz lesbaren - Informationen erfasst hier bei kernel.org . Ich habe dies und das ausprobiert, ich erinnere mich nicht genau, was ich getan habe, aber hey.

Wieder hat es manchmal geklappt, dann wieder nicht.

Nun, da bin ich eigentlich paranoid geworden, habe nach versteckten Modulen im Kernel gesucht und mir Kaltstart-Angriffe vorgestellt. Dabei habe ich herausgefunden, dass jemand wahrscheinlich mein BIOS-Assword erhalten hat, den Ruhezustand wieder aufgenommen und dann den Computer zurückgesetzt und den Speicher gelöscht, von dem aus ich gebootet habe einige fremde Bildgebungssysteme. (Bitte beachten Sie, dass dies alles absolut nicht weit hergeholt ist, wie sich herausstellte - völlig unabhängig.)

In dieser Aufgabe - heute Abend - habe ich es geschafft, diese Seite zu finden: https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues . Von hier aus habe ich die Parameter unter 2.1 initcall_debug , 2.3 ignore_loglevel hinzugefügt. und 2.4 dynamisches Debug zu meiner grub.cfg als Kernel-Boot-Parameter.

Dann passierte es wieder.

Aber jetzt war ich aufmerksamer. Mir ist aufgefallen, dass meine "verwaisten Inode" -Stücke auf " Superblock - Die letzte Schreibzeit liegt in der Zukunft " zurückzuführen sind. Ich verbrachte einige Stunden damit, herauszufinden, was damals, etwa ein halbes Jahr zuvor, falsch war, wieder ohne Erfolg. Ich habe gerade angenommen, dass es mit dem Mangel an System und meiner Gewohnheit zusammenhängt, localtime als hwclock zu verwenden (aufgrund von gelegentlichem Dual-Boot mit W7), also muss es im Intervall von 6-10 Minuten (ungenaue Clock-Quelle) auf 2 stehen Stunden maximal (ich bin in GMT + 1 DST).

Junge, habe ich mich geirrt.

Es kam nun vor, dass das Bootlog mit dem Kernelparameter ignore_loglevel das GENAUE Datum enthielt, an dem sich meine Uhr zum Startzeitpunkt befand, sowie die Änderungszeit.

Meine Uhr war tatsächlich auf den 06. Juni 2013 eingestellt, was vermutlich das BIOS-Veröffentlichungsdatum oder etwas Ähnliches ist. Das ist eine Differenz von drei Jahren (97010350.488716 Sekunden) laut ntpdate).

Als solches habe ich endlich herausgefunden, dass meine CMOS Batterie kaputt ist . Es könnte aufgeladen sein - auch wenn es nicht wiederaufladbar ist - und wenn ich den Computer für längere Zeit eingeschaltet habe, hat es möglicherweise eine Ladung aufgenommen, die ausreicht, um ein bis zwei Tage zu überleben - oder es war nur die Temperatur , Wer weiß. (Dies ist nicht mein primärer Computer, daher wurden alle zwei Wochen einige Tage hintereinander keine Stromversorgung hergestellt.)

tl; dr :

Abgesehen davon empfehle ich entweder, den CMOS - Akku auszutauschen oder - wenn es sich um einen Laptop oder ähnliches handelt - den Akku auszutauschen

  1. (optional, wenn Sie die Standardinstallation von Xenial 16.04 verwenden, benötigen Sie diese nicht) Installieren und konfigurieren Sie bootlogd, damit Sie Ihr Bootlog in/var/log/boot finden. (Mit systemd führen Sie einfach journalctl -b aus, um das Bootlog abzurufen.)

  2. Bearbeiten Sie Ihre /boot/grub/grub.cfg -Datei und fügen Sie initcall_debug ignore_loglevel am Ende der ersten Zeile beginnend mit linux /boot/vmlinuz... unter der ersten Zeile beginnend mit menuentry ein.

  3. Jetzt neu starten. Dies ist sehr wichtig, damit Sie mit den neuen aktivierten Einstellungen in den Ruhezustand wechseln.

  4. Ruhezustand, lassen Sie das Gerät für eine beträchtliche Zeitspanne ausgeschaltet, z. B. mindestens Stunden, und fahren Sie dann fort.

  5. Führen Sie abschließend entweder journalctl -b > /var/log/boot aus, wenn Sie nicht daran gedacht haben, etwas mit dem Namen systemd entfernt und/oder etwas mit dem Namen upstart, openrc oder sysvinit installiert zu haben.

Für all diese Schritte müssen Sie als Root angemeldet sein. Es wird daher empfohlen, nach jedem Neustart mit einem Sudo -s -Befehl zu beginnen und so etwas wie Midnight Commander (apt install mc zu installieren. oder Software Center) und verwenden Sie diese (mc), um mit den Konfigurationen und Protokollen zu arbeiten.

Jetzt haben Sie ein Log in /var/log/boot, in dem Sie beim Booten nach Ereignissen suchen können, die der eigentlichen Ursache für "verwaiste Inodes" entsprechen. Wenn Sie Probleme mit der "Änderungszeit in der Zukunft" haben, die sich um viele Stunden oder mehr unterscheiden, ist Ihre CMOS/RTC-Batterie definitiv ebenfalls zum Scheitern verurteilt und muss ersetzt werden.

0
Victor