Wznowienie hibernacji kończy się niepowodzeniem w jądrze Linuksa 4.9.0, Debian 9

Niedawno zaktualizowałem swoje jądro z 3.16.4 (Debian jessie) do 4.9.0 (Debian stretch). Wszystko było w porządku, dopóki nie spróbowałem „Hibernować” (zawiesić na dysk).

Kiedy używam opcji Hibernacja w LXDE, wydaje się hibernować. Słyszę tykanie wrzeciona dysku i zapisywanie danych. Ale problemy pojawiają się po wznowieniu hibernacji. Jądro pomyślnie przywraca obraz z zamiany, ale następnie zawiesza się i uruchamia ponownie, tracąc całą pracę. Nigdzie nie mogłem znaleźć odpowiedzi w Internecie. Ludzie po prostu rozwiązują niektóre błędy związane z nie ustawieniem /etc/initramfs-tools/conf.d/resume lub ustawieniem parametrów jądra lub błędnym wpisem w / etc / fstab. Mam te poprawne. Popraw UUID w /etc/initramfs-tools/conf.d/resume, popraw fstab i nie ustawiaj wznawiania parametrów jądra.

• Przeniosłem partycję wymiany poza partycję rozszerzoną na podstawową. Identyfikator UUID został zapisany i zastosowany do nowej zamiany.

• System osiąga „Przywracanie obrazu 100%”, a następnie „Zawieszanie konsoli”, a następnie wyłącza się i uruchamia normalnie, z utratą całej pracy.

• Próbowałem czystej instalacji, ale bez powodzenia.

• Zdarza się tylko na i386 (32-bit x86), amd64 (64-bit x86) nie cierpi.

Układ tabeli partycji dysku:

NAME   FSTYPE LABEL    UUID                                 MOUNTPOINT
sda                                                         
├─sda1 ext4   HDD      <ROOT-UUID> /
└─sda2 swap   HDD-SWAP <SW-UUID> [SWAP]
sr0

Sda2 był logiczny (rezyduje w środku rozszerzony) przed aktualizacją.

Fstab:

UUID=<ROOT-UUID> / ext4 errors=remount-ro 0 1
UUID=<SW-UUID> none swap sw 0 0

/etc/initramfs-tools/conf.d/resume

RESUME=UUID=<SW-UUID>

Cmdline jądra

BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-686-pae root=UUID=<ROOT-UUID> ro quiet

Informacje o systemie:

Computer: Compaq CQ60-120ec
Swap Size: 3.5GiB
Processor: AMD Athlon X2 64 QL-66
GPU: Nvidia Geforce 8200M G
Memory: 2G DDR2 667MHz
Desktop Environment: LXDE
Debian Version: 9 (stretch)
Kernel version: 4.9.0-3
Graphics Driver: nvidia legacy 304xxx

(Wiem, że procesor jest 64-bitowy, ale oryginalnie był dostarczany z 32-bitowym systemem operacyjnym, więc myślałem, że był 32-bitowy, dopóki nie zbadałem / proc / cpuinfo)

Problem wynika z konfliktu między hibernacją a kASLR na x86-32 . Można to rozwiązać poprzez wyłączenie kASLR z opcją uruchamiania jądra nokaslr . Nie dotyczy to x86-64 .

W przypadku Grub można to zrobić, edytując / etc / default / grub i dodając nokaslr do opcji rozruchu, np .: GRUB_CMDLINE_LINUX_DEFAULT = "cichy nokaslr "

Następnie uruchom update-grub, aby zaktualizować konfigurację i uruchom ponownie, aby spróbować.

Miałem dokładnie ten sam problem i wydaje się, że problem dotyczy tylko jądra PAE. To samo jądro bez PAE działa bez problemów.

Obejściem tego problemu było zainstalowanie linux-image-686 i odinstalowanie linux-image-686-pae i linux-image-4.9.0-4-686-pae. Dokładna wersja jądra może z czasem ulec zmianie z powodu aktualizacji, ale w zasadzie obecnie działające jądro PAE musi zostać zastąpione jądrem bez PAE.

W rzeczywistości nie ma to nic wspólnego ze wsparciem procesora przez PAE, ponieważ mój procesor obsługuje PAE zgodnie z / proc / cpuinfo. Ale PAE i tak nie ma większego zastosowania na starych notebookach.

Nie ma to również nic wspólnego z PAE jądra 4.9, podobnie jak w przypadku jądra 4.13 PAE z backportów Debiana.

Prawdopodobnie /etc/uswsusp.confchce zmienionego wpisu dla „wznowienia urządzenia”, jeśli nie zostanie ono użyte, myabe po prostu spróbuje grepować stary UUID we wszystkich plikach, /etcaby znaleźć miejsce, w którym konieczna jest zmiana. Również update-initramfsbyłoby konieczne, powiedziałbym.

Otrzymywałem ten sam błąd. Ponowna instalacja przy użyciu najnowszej wersji netinst iso, tj. Debian-9.1.0-amd64-netinst.iso go rozwiązał. Błąd wydaje się być naprawiony (przynajmniej dla tej architektury).

Usunąłem uswsusp, a hibernacja znów działa jak urok. BTW Myślę, że tak było już przed Jessie, kiedy korzystałem ze sterownika nvidia, przetestowałem za pomocą uswsusp i musiałem go usunąć, aby hibernacja działała.

Jeśli masz partycję wymiany (o prawidłowym rozmiarze) i edytujesz „/etc/initramfs-tools/conf.d/resume” z wynikiem „#blkid”, a i386 nie hibernuje poprawnie, to błąd w Debianie i386 4.9 jądro! Zaktualizuj jądro do wersji większej niż 4.9 lub przywróć jądro do wersji 3.16.

Proszę wybaczyć ogólny charakter tej odpowiedzi. W Internecie widziałem podobne pytania i postanowiłem napisać jedną odpowiedź dla wszystkich. Napotkałem ten sam problem, kiedy aktualizowałeś Debian-Jessie na Hp2510. Przełączyłem się na Ubuntu-desktop i też go tam znalazłem. Następnie przeprowadziłem testy na Ubuntu i Hp2510, więc może nie mieć pełnego zastosowania do twojej sytuacji.

Niektóre starsze komputery zaktualizowane o nowe systemy Linux mają problemy z uruchomieniem. Mogą się wcale nie uruchamiać lub uruchamianie może potrwać nawet trzy minuty. Przypadkowo albo nie hibernują, albo tak długo hibernują i dehibernują, że zdolność jest bezużyteczna. Często nie dzieje się tak dlatego, że stare komputery są po prostu wolne, ale z powodu zmiany wprowadzonej w jądrze Linuksa 4.8, powodując problem z bardzo popularnym mikroukładem Intela, który obejmuje wyjście svideo. Począwszy od tego jądra, każdy komputer z tym chipsetem będzie miał problemy z uruchomieniem, chyba że argument wiersza poleceń Linuksa"video=SVIDEO-1:d"jest zawarty w GRUB_CMDLINE_LINUX. Znacząco skróci to zarówno 64-bitowy, jak i 32-bitowy czas rozruchu, ale naprawia problemy z hibernacją tylko dla 64-bitowych. Po tym punkcie żaden system 32-bitowy nie obsługuje hibernacji. Ponadto czasy rozruchu dla wszystkich wersji jądra 4.8 i 4.9 są złe (oprócz 4.8.rc1-7). Ostatecznie rozwiązano to w 4.10. Należy unikać jąder 4.8 i 4.9 (i tak są one przestarzałe).

Jeśli chcesz uzyskać najszybszy czas uruchamiania, użyj jądra starszego niż 4.8. Chciałbym użyć Ubuntu-desktop 15.04 z jądrem zaktualizowanym do 4.7.10. Jest to jedyny sposób na uzyskanie hibernacji w systemie 32. System 64-bitowy uruchamia się o 7% wolniej niż 32-bitowy, ale wciąż jest szybszy niż jakakolwiek późniejsza wersja. Jeśli chcesz mieć obecnie obsługiwany system 32-bitowy i chcesz zrezygnować z hibernacji, użyj tych, które zostały wydane lub zaktualizowane do jądra 4.10 lub nowszego. Każda wersja 64-bitowa działa z poprawką wideo po wersji 4.8, ale dla najlepszej wydajności należy unikać wersji 4.8 i 4.9.

Aby dodać poprawkę wideo, wykonaj sudo nano /etc/default/grub. Po zamknięciu nano do sudo update-grub. O ile GRUB_CMDLINE_LINUX_DEFAULT, wstawiony po GRUB_CMDLINE_LINUX, nie będzie pusty, "video=SVIDEO-1:d"nie będzie ostatnim argumentem wiersza poleceń Linuksa, który zdaniem niektórych osób jest konieczny. W rzeczywistości może być wszędzie.

Zawsze możesz wywołać hibernację za pomocą polecenia pm-hibernacja w terminalu (lub tty), ale aby mieć dostępną opcję GUI, musisz utworzyć lub dodać do pliku strategii /etc/polkit-1/localauthority/50-local.d/ com.ubuntu.enable-hibernate.pkla(oczywiście specyficzne dla dystrybucji) następujący tekst:

[Re-enable hibernate by default for login1]
    Identity=unix-user:*
    Action=org.freedesktop.login1.hibernate
    ResultActive=yes
[Re-enable hibernate for multiple users by default in logind]
    Identity=unix-user:*
    Action=org.freedesktop.login1.hibernate-multiple-sessions
    ResultActive=yes

Czasami problemem nie jest grub ani UUID. Dzieje się tak również wtedy, gdy brakuje miejsca. Nie będzie już miejsca do zapisu, dlatego wznowienie hibernacji zostanie zawieszone.

Gdy dojdziesz do tego błędu, możesz kliknąć alt+ f2/f3/f7lub ctrl+alt+ f2/f3/f7otworzyć terminal. Zaloguj się do swojego konta lub root za pomocą terminala.

Następnie uruchom polecenie, sudo df -haby sprawdzić miejsce w pamięci. W moim przypadku nie miałem na sobie miejsca, /dev/sda1więc sprawdź wolne miejsce na dyskach na liście.

Jeśli brakuje Ci miejsca, spróbuj usunąć niektóre pliki, aby uzyskać znaczną ilość miejsca.

Następnie możesz kliknąć alt+f1lub ctrl+alt+f1poczekać na pojawienie się lub wpisanie GUI logowaniareboot in the terminal to reboot