Сбой возобновления гибернации на ядре Linux 4.9.0, Debian 9

9

Я недавно обновил свое ядро ​​с 3.16.4 (Debian jessie) до 4.9.0 (Debian stretch). Все было хорошо, пока я не попытался "Hibernate" (приостановить на диск).

Когда я использую опцию Hibernate в LXDE, она появляется в спящем режиме. Я слышу тиканье диска и запись данных. Но проблема возникает при выходе из спящего режима. Ядро успешно восстанавливает образ из свопинга, но затем зависает и перезагружается, и вся эта работа теряется. Я не мог найти ответ нигде в Интернете. Люди просто решают некоторые ошибки, связанные с тем, что они не устанавливают /etc/initramfs-tools/conf.d/resume, или устанавливают параметры ядра, или неправильно вводят в / etc / fstab. У меня есть это правильно. Исправьте UUID в /etc/initramfs-tools/conf.d/resume, исправьте fstab и не устанавливайте параметр возобновления ядра.

  • Я переместил раздел подкачки за пределы расширенного раздела на основной. UUID был сохранен и применен к новому свопу.

  • Система достигает «Восстановление образа на 100%», а затем «Приостановка консолей», затем она выключается и загружается нормально, при этом вся работа теряется.

  • Пробовал чистую установку, но без удачи.

  • Бывает только на i386 (32-битная x86), amd64 (64-битная x86) не страдает.

Таблица разделов диска:

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

Перед обновлением sda2 был логичен (постоянно находится внутри).

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

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

Системная информация:

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

(Я знаю, что процессор 64-битный, но изначально он шел с 32-битной ОС, поэтому я думал, что он 32-битный, пока я не изучил / proc / cpuinfo)

Enginecrafter77
источник

Ответы:

4

Проблема связана с конфликтом между hibernate и kASLR на x86-32 . Это можно решить, отключив kASLR с помощью опции загрузки ядра nokaslr . x86-64 не влияет.

Для Grub это можно сделать, отредактировав / etc / default / grub и добавив nokaslr в параметры загрузки, например: GRUB_CMDLINE_LINUX_DEFAULT = "quiet nokaslr "

Затем запустите update-grub, чтобы обновить конфигурацию, и перезагрузите компьютер, чтобы попробовать.


У меня была точно такая же проблема, и кажется, что эта проблема затрагивает только ядро ​​PAE. Это же ядро ​​без PAE работает без проблем.

Обходным решением для меня было установить linux-image-686 и удалить linux-image-686-pae и linux-image-4.9.0-4-686-pae. Точная версия ядра может со временем измениться из-за обновлений, но в основном работающее в настоящее время ядро ​​PAE необходимо заменить ядром без PAE.

На самом деле это не имеет ничего общего с поддержкой процессоров PAE, так как мой процессор поддерживает PAE в соответствии с / proc / cpuinfo. Но PAE в любом случае не очень полезен на старых ноутбуках.

Это также не имеет ничего общего с PAE ядра 4.9, так как такая же проблема возникает с ядром 4.13 PAE из бэкпортов Debian.

И я
источник
Этот превосходный ответ заслуживает гораздо больше взлетов, но я могу дать только один.
peterh - Восстановить Монику
Да, спасибо, я думал, что на этом сайте нет экспертов. (Un) К счастью, я решил, что версия amd64 работает без проблем, поэтому я подумал, что они перестали поддерживать версию 686, но я не знал, что существует версия 686 без PAE. Я надеюсь, что Debian это исправит, иначе люди будут жаловаться.
Enginecrafter77
3

Вероятно, /etc/uswsusp.confхочет изменить запись для «устройства возобновления», если это не используется, myabe просто попытайтесь найти ваш старый UUID во всех файлах, /etcчтобы найти место, где требуется изменение. Также update-initramfsбыло бы необходимо, я бы сказал.

Jaleks
источник
Ничего из этого не помогло, попытался установить uswsusp и проверить правильность файла, но не повезло. И никакие файлы конфигурации в / etc не содержат мой старый UUID.
Enginecrafter77
2

Я получаю ту же ошибку. Переустановка с последней версией netinst iso, то есть debian-9.1.0-amd64-netinst.iso, разобрала. Ошибка, кажется, была исправлена ​​(по крайней мере, для этой архитектуры).

VCC
источник
Да, я согласен, это исправлено в amd64 (то есть x64), но ошибка все еще существует в i386 (псевдоним 686 или x86)
Enginecrafter77
1

Я удалил uswsusp и гибернация снова работает как шарм. Кстати, я думаю, что это было до Джесси, когда я использовал драйвер nvidia, я тестировал с помощью uswsusp и мне пришлось удалить его, чтобы заставить работать спящий режим.

Alain
источник
У меня не установлен uswsusp при тестировании 32-битного компьютера, но гибернация по-прежнему не работает.
Enginecrafter77
Очень плохо. Вы пробовали удалить драйвер nvidia и использовать nouveau?
Ален
Да, я попробовал полностью чистую установку Debian 9 (32-битную), но проблема все еще остается. Это также происходит на компьютере с графикой Intel, поэтому я думаю, что это не имеет ничего общего с графическим процессором.
Enginecrafter77
1

Если у вас есть раздел подкачки (с правильным размером) и если вы редактируете "/etc/initramfs-tools/conf.d/resume" с результатом "#blkid", и i386 не будет корректно работать в спящем режиме, это ошибка в Debian i386 4.9 ядро! Обновите ядро ​​до версии выше 4.9 или откатитесь до 3.16 ядра.

Лопи Дани
источник
0

Пожалуйста, извините за общий характер этого ответа. Я видел подобные вопросы по всей сети и решил написать один ответ для всех. Я столкнулся с той же проблемой, что и при обновлении Debian-Jessie на Hp2510. Я переключился на Ubuntu-рабочий стол и нашел его там тоже. Впоследствии я провел тестирование на Ubuntu и Hp2510, поэтому оно может не полностью соответствовать вашей ситуации.

Некоторые старые компьютеры с новыми системами Linux испытывают проблемы с загрузкой. Они могут вообще не загружаться или для загрузки может потребоваться до трех минут. По совпадению, они либо не переходят в спящий режим, либо переходят в спящий и дежурный режим настолько долго, что эта возможность оказывается бесполезной. Часто это происходит не потому, что старые компьютеры просто работают медленно, а из-за изменений, внесенных в ядро ​​Linux версии 4.8, что вызывает проблему с очень распространенным набором микросхем Intel, который включает вывод видео. Начиная с этого ядра, любой компьютер с этим чипсетом будет испытывать проблемы с загрузкой, если только аргумент командной строки Linux"video=SVIDEO-1:d"включено в GRUB_CMDLINE_LINUX. Это значительно сократит время загрузки как 64-разрядных, так и 32-разрядных, но исправит проблемы гибернации только для 64-разрядных. После этого ни одна 32-битная система не поддерживает спящий режим. Кроме того, время загрузки для всех версий ядра 4.8 и 4.9 плохое (кроме 4.8.rc1-7). Это наконец решено в 4.10. Следует просто избегать использования ядер 4.8 и 4.9 (они все равно устарели).

Если вы хотите самое быстрое время загрузки, используйте ядро ​​до 4.8. Я бы использовал Ubuntu-desktop 15.04 с обновленным ядром до 4.7.10. Это единственный способ получить спящий режим в 32-х системах. 64-разрядная система загружается на 7% медленнее, чем 32-разрядная, но все же быстрее, чем любая более поздняя версия. Если вам нужна поддерживаемая в настоящее время 32-разрядная система и вы хотите отказаться от режима гибернации, используйте любую версию, выпущенную или обновленную до ядра 4.10 или новее. Любая 64-битная версия работает после 4.8 с исправлением видео, но для лучшей производительности избегайте 4.8 и 4.9.

Чтобы добавить исправление видео сделать sudo nano /etc/default/grub. После закрытия нано сделать sudo update-grub. Если GRUB_CMDLINE_LINUX_DEFAULT, который вставляется после GRUB_CMDLINE_LINUX, не будет пустым, "video=SVIDEO-1:d"не будет последним аргументом командной строки Linux , который, по мнению некоторых, необходим. Это на самом деле может быть где угодно.

Вы всегда можете вызвать hibernate с помощью команды pm-hibernate в терминале (или tty), но чтобы иметь доступную опцию GUI, вам нужно создать или добавить в файл политики /etc/polkit-1/localauthority/50-local.d/ com.ubuntu.enable-hibernate.pkla(очевидно, специфичный для дистрибутива) следующий текст:

[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
Дэвид Маккракен
источник
0

Иногда проблема не в grub или UUID. Это также происходит, когда у вас недостаточно места для хранения. Там не останется места для записи, поэтому возобновление из спящего режима будет зависать.

Когда вы получите эту ошибку, вы можете нажать alt+ f2/f3/f7или ctrl+alt+ f2/f3/f7открыть терминал. Войдите в свою учетную запись или root с помощью терминала.

Затем выполните команду, sudo df -hчтобы проверить объем памяти. В моем случае у меня не было свободного места, /dev/sda1поэтому проверьте свободное место на дисках в списке.

Если вам не хватает места, попробуйте удалить некоторые файлы, чтобы получить достаточно много места.

После этого вы можете нажать alt+f1или ctrl+alt+f1и дождаться появления логина или набратьreboot in the terminal to reboot

Дэвид Карики
источник
Что ж, спасибо за вашу попытку, но эта проблема уже решена. Проблема с ядром 4.9.0 i386 + PAE. Позже я обнаружил, что мой ПК может запускать 64-битное программное обеспечение (хотя ПК всегда работал 32-битным со дня, когда я его получил), и 64-битное ядро ​​решило проблему.
Enginecrafter77
Хорошо, пожалуйста.
Дэвид Кариуки