Не вдалося відновити сплячку в ядрі Linux 4.9.0, Debian 9


9

Нещодавно я модернізував своє ядро ​​з 3.16.4 (Debian jessie) до 4.9.0 (розтягнення Debian). Все було добре, поки я не спробував "перезимувати" (призупинити диск).

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

  • Я перемістив розділ swap поза розширеним розділом до основного. UUID було збережено та застосовано до нового swap.

  • Система досягає "Відновлення зображення на 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)

Відповіді:


4

Проблема пов'язана з конфліктом між сплячим режимом та kASLR на x86-32 . Це можна вирішити, відключивши kASLR за допомогою параметра завантаження ядра nokaslr . x86-64 не впливає.

Для Grub це можна зробити, відредагувавши / etc / default / grub та додавши nokaslr до параметрів завантаження, наприклад: GRUB_CMDLINE_LINUX_DEFAULT = "тихий 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 все одно не дуже корисно для старих ноутбуків.

Це також не має нічого спільного з ядром 4.9 PAE, оскільки ця ж проблема трапляється з ядром 4.13 PAE з Debian backports.


Ця відмінна відповідь заслуговує на набагато більше злетів, але я можу дати лише один.
петерх

Так, дякую, я подумав, що цей сайт не є експертами. (Un) На щастя, я зрозумів, що версія amd64 працює без проблем, тому я подумав, що вони перестали підтримувати версію 686, але я не знав, що існує версія 686 без PAE. Я сподіваюся, що Debian це виправить, інакше люди скаржаться.
Enginecrafter77

3

Можливо, /etc/uswsusp.confхоче змінити запис для "відновити пристрій", якщо це не використовується, myabe просто спробує зібрати ваш старий UUID у всіх файлах, /etcщоб знайти місце, де потрібна зміна. Також update-initramfs, я б сказав, було б необхідне.


Нічого з цього не допомогло встановити uswsusp і перевірити, чи файл правильний, але не пощастило. І жоден файл конфігурації в / etc не містить мого старого UUID.
Enginecrafter77

2

Я отримував таку ж помилку. Перевстановлення з найсвіжішим netinst iso, тобто debian-9.1.0-amd64-netinst.iso, розібрало його. Здається, виправлено помилку (принаймні для цієї архітектури).


Так, я погоджуюся, він виправлений в amd64 (тобто x64), але помилка все ще є в i386 (псевдонім 686 або x86)
Enginecrafter77

1

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


У мене не встановлено uswsusp на тестуванні 32-розрядного комп'ютера, але сплячка все ще не працює.
Enginecrafter77

Дуже погано. Ви спробували видалити драйвер nvidia та скористатись nouveau?
Ален

Так, я спробував повністю очистити встановлення Debian 9 (32 біт), але проблема все ще існує. Це також трапляється на комп'ютері з графікою Intel, тому я думаю, що це не має нічого спільного з GPU.
Enginecrafter77

1

Якщо у вас є розділ swap (з правильним розміром) і ви редагуєте "/etc/initramfs-tools/conf.d/resume" з результатом "#blkid", і i386 не буде зимувати правильно, ніж помилка на Debians i386 4.9 ядро! Оновіть ядро ​​до версії, що перевищує 4,9, або поверніть до ядра 3,16.


0

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

Деякі старі комп'ютери, оновлені новими системами Linux, відчувають проблеми із завантаженням. Вони можуть взагалі не завантажуватися, або на завантаження може знадобитися три хвилини. Випадково вони або не впадають у сплячку, або знадобляться так довго, щоб перезимувати та дегібернувати, що ця можливість є марною. Часто це не тому, що старі комп'ютери просто повільні, а через зміни, внесені в ядро ​​4.8 Linux, спричиняючи проблеми з дуже поширеним чіпсетом 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, який деякі люди вважають необхідним. Це насправді може бути де завгодно.

Ви завжди можете викликати сплячку за допомогою команди pm-hibernate у терміналі (або tty), але щоб мати доступний варіант графічного інтерфейсу, вам потрібно створити або додати до файлу політики /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

Часом проблема полягає не в зловживанні або 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

Гаразд, ласкаво просимо.
Девід
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.