Посмотри, может, что найдешь.

Игнорировать. Ловлю его на своём Toshiba L350 ещё со времён Lenny, никаких проблем.

Такая же штука

У меня есть подозрение, что из за этого бага, у меня проблемы с гибернацией (все вроде работает, а при включении происходит начальная загрузка).

А в dmesg вообще видны сообщения про PM и попытку разгибернейтнуться?

Что в /etc/initramfs-tools/conf.d/resume?

Здравствуйте, AITap.

в /etc/initramfs-tools/conf.d/resume лежит следующее: RESUME=UUID=2263bc85-f968-4713-acbe-2979f3a97615

Это - UUID swop-пространства.

Кстати, у меня не был установлен софт - hubernate. Сегодня взял винт с ubuntu, скопировал файлы из директорий (/etc/pm/sleep.d, /usr/lib/pm-utils/sleep.d, /root/archve/etc/default/acpi-support) - вообще перестал выключаться. (кстати, написаны они одним человеком просто в ubuntu они более поздние и немного переделан код, но смысл остался тот же).

Продолжение: Переустановил hal,acpi и установил laptop-mode-tools и hibernate, - начал отключаться, но включается - все равно как заново без сохранения памяти. Удалил обратно laptop-mode-tools и hibernate, - после последнего (как мне кажется) перестал уходить в гибернацию, хотя прога не стояла в начале и комп засыпал. Пока не могу понять негоже ему надо. В убунте гибернация работала нормально.

Здравствуйте.

в /etc/initramfs-tools/conf.d/resume лежит следующее: RESUME=UUID=2263bc85-f968-4713-acbe-2979f3a97615
Это - UUID swop-пространства.

Это правильно.

Кстати, у меня не был установлен софт - hubernate.

Как Вы это определили? Для гибернации достаточно записать строку «disk» в виртуальный файл в /sys/, а восстановлением заведует маленькая программа в initramfs (/usr/lib/klibc/bin/resume), которая ставится с пакетом klibc-utils и наверняка у Вас есть.

Сегодня взял винт с ubuntu, скопировал файлы из директорий (/etc/pm/sleep.d, /usr/lib/pm-utils/sleep.d, /root/archve/etc/default/acpi-support) - вообще перестал выключаться. (кстати, написаны они одним человеком просто в ubuntu они более поздние и немного переделан код, но смысл остался тот же).

Откатите свои изменения и поставьте пакет pm-utils из репозитория.

Вы пробовали читать dmesg в поисках строк вида «PM: Hibernation image not present or could not be loaded.» после гибернации? Вы пробовали гибернироваться и/или «просыпаться», загрузившись с параметрами ядра loglevel=9 debug no_console_suspend?

Как Вы это определили?

- apt-get install -s hibernate (прказал, что пакет не установлен).

Для гибернации достаточно записать строку «disk» в виртуальный файл в /sys/,

- не понял куда (в какой файл) нужно записать строку «disk»?

а восстановлением заведует маленькая программа в initramfs (/usr/lib/klibc/bin/resume), которая ставится с пакетом klibc-utils и наверняка у Вас есть.

- /usr/lib/klibc/bin/resume - бинарный файл, initramfs - там нет. Но есть в /dev/.initramfs/ - там у меня пусто. apt-get написал, что klibc-utils установлен вручную.

Откатите свои изменения и поставьте пакет pm-utils из репозитория.

- сделал

Вы пробовали читать dmesg в поисках строк вида «PM: Hibernation image not present or could not be loaded.» после гибернации?

- нашел вот такие строки: [ 1.139643] PM: Resume from disk failed. [ 20.505469] apm: BIOS not found.

Вы пробовали гибернироваться и/или «просыпаться», загрузившись с параметрами ядра loglevel=9 debug no_console_suspend?

- можно поподробнее как это сделать?

Спасибо.

Как Вы это определили?

- apt-get install -s hibernate (прказал, что пакет не установлен).

Для гибернации обычно используется пакет pm-utils.

Для гибернации достаточно записать строку «disk» в виртуальный файл в /sys/,

- не понял куда (в какой файл) нужно записать строку «disk»?

/sys/power/state
Запись «disk» в этот файл заставит ядро заморозить все процессы, выделить память на устройстве подкачки и переместить страницы памяти туда, после чего выключиться.
Программы вроде hibernate-script и pm-utils позволяют облегчить этот процесс, удаляя модули и останавливая процессы, которые могут нарушить засыпание, а после просыпания возвращая их обратно.

Я сказал об этом просто для наглядности, поясняя, что поддержка hibernate встроена в ядро, а не ставится отдельным пакетом. Можете не проверять, работает ли гибернация таким способом: судя по ошибке, проблемы начинаются при просыпании (см. ниже).

- нашел вот такие строки:
[ 1.139643] PM: Resume from disk failed.

А что выше этой строчки? Она не появляется при обычном включении (без предшествующей гибернации)?

Вы пробовали гибернироваться и/или «просыпаться», загрузившись с параметрами ядра loglevel=9 debug no_console_suspend?

- можно поподробнее как это сделать?

В меню загрузчика (GRUB2) на пункте меню Debian нужно нажать «e», найти строку, которая начинается с «linux», удалить оттуда вхождения «quiet» и «splash» (если есть) и добавить: loglevel=9 debug no_console_suspend
После чего нажать F10 или Ctrl+X для однократного запуска с этими параметрами.

Кстати, можно попробовать пойти по простому пути и поставить из бекпортов новое ядро (подключение: см. раздел «Instructions»; установка: sudo aptitude -t squeeze-backports full-upgrade ~i~n^linux-). Возможно, в новом ядре улучшена поддержка железа, проблема которой приводит к невозможности «проснуться».

/sys/power/state

Запись «disk» в этот файл заставит ядро заморозить все процессы, выделить память на устройстве подкачки и переместить страницы памяти туда, после чего выключиться.

- В файле /sys/power/state строка «mem disk», а в файле resume строка «0:0» - это нормально?

А что выше этой строчки? Она не появляется при обычном включении (без предшествующей гибернации)?

Я файл dmesg целиком к сожалению отправить форус не дает, могу скинуть на мыло.

[    1.131673] Linux agpgart interface v0.103
[    1.131786] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    1.132127] PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:MOUE] at 0x60,0x64 irq 1,12
[    1.135844] i8042.c: Detected active multiplexing controller, rev 1.1.
[    1.138433] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.138439] serio: i8042 AUX0 port at 0x60,0x64 irq 12
[    1.138441] serio: i8042 AUX1 port at 0x60,0x64 irq 12
[    1.138444] serio: i8042 AUX2 port at 0x60,0x64 irq 12
[    1.138446] serio: i8042 AUX3 port at 0x60,0x64 irq 12
[    1.138488] mice: PS/2 mouse device common for all mice
[    1.138534] rtc_cmos 00:03: RTC can wake from S4
[    1.138559] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
[    1.138588] rtc0: alarms up to one month, 242 bytes nvram, hpet irqs
[    1.138598] cpuidle: using governor ladder
[    1.138599] cpuidle: using governor menu
[    1.138603] No iBFT detected.
[    1.138871] TCP cubic registered
[    1.138985] NET: Registered protocol family 10
[    1.139579] Mobile IPv6
[    1.139581] NET: Registered protocol family 17
[    1.139593] Using IPI No-Shortcut mode
[    1.139643] PM: Resume from disk failed.
[    1.139655] registered taskstats version 1
[    1.140139] rtc_cmos 00:03: setting system clock to 2013-01-14 15:18:27 UTC (1358176707)

Вы пробовали гибернироваться и/или «просыпаться», загрузившись с параметрами ядра loglevel=9 debug no_console_suspend?

- можно поподробнее как это сделать?

- я сейчас этим займусь

а в файле resume строка «0:0» - это нормально?

Покажите результат выполнения команды ls -l $(readlink -e /dev/disk/by-uuid/2263bc85-f968-4713-acbe-2979f3a97615)
По идее, числа в /sys/power/resume должны совпадать с номерами устройства, с которого нужно проснуться.

Я файл dmesg целиком к сожалению отправить форус не дает, могу скинуть на мыло.

Для этого существуют хостинги текстов («pastebin»), например, http://paste.org.ru/

Покажите результат выполнения команды ls -l $(readlink -e /dev/disk/by-uuid/2263bc85-f968-4713-acbe-2979f3a97615)

По идее, числа в /sys/power/resume должны совпадать с номерами устройства, с которого нужно проснуться.

root@stealth:/home/kogar# ls -l $(readlink -e /dev/disk/by-uuid/2263bc85-f968-4713-acbe-2979f3a97615) brw-rw---- 1 root disk 8, 5 Янв 14 19:18 /dev/sda5

root@stealth:/home/kogar# cat /etc/fstab # swap was on /dev/sda5 during installation UUID=2263bc85-f968-4713-acbe-2979f3a97615 none swap sw 0 0

Вот адрес лога: http://paste.org.ru/?ptojny

Попробуйте добавить (таким же способом) параметр ядра break=premount и в появившейся во время загрузки командной строке (вида "(initramfs)") ввести blkid. Команда напечатает несколько строк. Будет ли в её выводе раздел с TYPE=«swsusp»? Если да, будет ли он соответствовать разделу swap?

(Получившуюся командную строку можно закрыть нажатием Ctrl+D или командой exit, после этого загрузка продолжится)

Здравствуйте ALTap!

Попробуйте добавить (таким же способом) параметр ядра break=premount и в появившейся во время загрузки командной строке (вида "(initramfs)") ввести blkid. Команда напечатает несколько строк. Будет ли в её выводе раздел с TYPE=«swsusp»? Если да, будет ли он соответствовать разделу swap?

(Получившуюся командную строку можно закрыть нажатием Ctrl+D или командой exit, после этого загрузка продолжится)

- да раздел присутствует и соответствует, только, если это не опечатка, - TYPE был не «swsusp», а «swap».

Прошу прощения AITap

Да, чуть не забыл, сегодня ночью выключал комп, появилась строка отсчитывающая от 0 до 100, звучала примерно так:

копирование mem на disk, но загрузка все равно началась с нуля.

сейчас заметил, что при загрузке, вылезает строка красного цвета и написано в ней что то типа - «ошибка загрузки acpi-fakekeyd», точнее сказать сложно, потому что в логах этого найти не могу, но apt-get мне говорит, что пакет acpi-fakekey не установлен.

я уже посмотрел, похоже, все логи и ничего не нашел, кроме ошибок, которые, как мне кажется, на это повлиять не должны:

- ACPI: Invalid PBLK length [8]

TYPE был не «swsusp», а «swap»

И это было при включении после гибернации (не после обычного выключения)?

На всякий случай, «гибернация» - это выключение, как в этом случае:

Да, чуть не забыл, сегодня ночью выключал комп, появилась строка отсчитывающая от 0 до 100, звучала примерно так:
копирование mem на disk, но загрузка все равно началась с нуля.

Если всё так, то система почему-то записывает данные для гибернации не на swap-раздел, и это место не доступно, когда система включается. У Вас есть другие swap'ы (что в /proc/swaps)? Мне пока не удалось понять логику выбора устройства для гибернации (kernel/power/swap.c), тут может понадобиться помощь ядерщиков.

Если TYPE=«swap» нашлось после обычного выключения (не гибернации), это нормально. Повторите попытку после гибернации.

сейчас заметил, что при загрузке, вылезает строка красного цвета и написано в ней что то типа - «ошибка загрузки acpi-fakekeyd», точнее сказать сложно, потому что в логах этого найти не могу, но apt-get мне говорит, что пакет acpi-fakekey не установлен.
я уже посмотрел, похоже, все логи и ничего не нашел, кроме ошибок, которые, как мне кажется, на это повлиять не должны:
- ACPI: Invalid PBLK length [8]

Можно установить и включить bootlogd, если хотите иметь лог сообщений загрузки.

У Вас есть другие swap'ы?

- нет, только этот

Если TYPE=«swap» нашлось после обычного выключения (не гибернации), это нормально. Повторите попытку после гибернации.

- повторил, действительно, после гибернации TYPE=«swsuspend»

- при загрузке, после нажатия Ctrl+D, снова мелькнула красная надпись про - «acpi-fakekeyd», он у меня не установлен, может стоит поставить?

Можно установить и включить bootlogd, если хотите иметь лог сообщений загрузки.

- как его включить?

Да, чуть не забыл, сегодня ночью выключал комп, появилась строка отсчитывающая от 0 до 100, звучала примерно так:

копирование mem на disk, но загрузка все равно началась с нуля.

- я так понимаю, что этот счетчик показался потому,что я загружался в дебаге с loglevel=9, так как при засыпании я ьольше ничего не вижу.

...(что в /proc/swaps)?

- сам файл - 0 B. Но внутри:

Filename				Type		Size	Used	Priority
/dev/sda5                               partition	5858296	0	-1

как лечить?

чинить dsdt в acpi

- повторил, действительно, после гибернации TYPE=«swsuspend»

Тогда в такой же командной строке попробуйте ввести /bin/resume /dev/sda5 или echo «8:5» > /sys/power/resume. По идее, это заставит систему попытаться проснуться с устройства /dev/sda5.

У Вас есть другие swap'ы?

- нет, только этот

- повторил, действительно, после гибернации TYPE=«swsuspend»

Значит, гибернация выполняется на правильное устройство.

Можно установить и включить bootlogd, если хотите иметь лог сообщений загрузки.

- как его включить?

Открыть с правами суперпользователя текстовый файл /etc/default/bootlogd и заменить No на Yes (на самом деле - на любую не пустую комбинацию символов, которая не начинается на «n» или «N»). После этого в /var/log/boot при загрузке системы будут записаны сообщения, выводящиеся на экран.

- я так понимаю, что этот счетчик показался потому,что я загружался в дебаге с loglevel=9, так как при засыпании я ьольше ничего не вижу.

Именно.

Тогда в такой же командной строке попробуйте ввести /bin/resume /dev/sda5 или echo «8:5» > /sys/power/resume. По идее, это заставит систему попытаться проснуться с устройства /dev/sda5.

- первой командой (/bin/resume /dev/sda5), система действительно восстановилась. Хотя в «/bin/» нет файла «resume» не понятно что произошло?

- во втором случае (echo «8:5» > /sys/power/resume) что такое «8» в «8:5», и нужно ли ее писать в кавычках?

- по виду команда должна записать «8:5» в /sys/power/resume. У меня там пока «0:0».

Открыть с правами суперпользователя текстовый файл /etc/default/bootlogd и заменить No на Yes (на самом деле - на любую не пустую комбинацию символов, которая не начинается на «n» или «N»). После этого в /var/log/boot при загрузке системы будут записаны сообщения, выводящиеся на экран.

- сделал, но лог не записался :(

может потомку, что я не перезагружал машину, а ушел в сон?

- первой командой (/bin/resume /dev/sda5), система действительно восстановилась. Хотя в «/bin/» нет файла «resume» не понятно что произошло?

Эта команда была введена, когда корнем системы был initramfs - содержимое файла /initrd.img. Этот файл собирается из разных частей системы; в частности, файл /bin/resume берётся из /usr/lib/klibc/bin/resume.
Попробуйте снова в командной строке initramfs ввести: grep . /conf/conf.d/*
Строка RESUME=uuid_раздела_swap будет на месте? Если нет, загрузитесь и введите sudo update-initramfs -u -k all, это пересоберёт initramfs с правильными параметрами, и проблема решится.
Если же эта строка будет на месте, это странно. Можно ещё проверить наличие нужных для просыпания скриптов командой: ls /scripts/*/resume

- во втором случае (echo «8:5» > /sys/power/resume) что такое «8» в «8:5», и нужно ли ее писать в кавычках?

8 и 5 - это так называемые major и minor number устройства. Получить их можно, введя ls -l /dev/файл_устройства, они будут указаны через запятую сразу после пользователя и группы-владельца файла.
Программа /bin/resume делает примерно то же самое: различными способами узнаёт, с какого устройства «просыпаться», получает эти номера и записывает их в /sys/power/resume.

- сделал, но лог не записался :(
может потомку, что я не перезагружал машину, а ушел в сон?

Если после этого удалось нормально «проснуться», нормальный процесс загрузки (включения) системы не был задействован, и записывать было нечего.

Попробуйте снова в командной строке initramfs ввести: grep . /conf/conf.d/*

Строка RESUME=uuid_раздела_swap будет на месте? Если нет, загрузитесь и введите sudo update-initramfs -u -k all, это пересоберёт initramfs с правильными параметрами, и проблема решится.

- команда «grep . /conf/conf.d/*» - ничего не выдала, посмотрел в директории - она пуста.

Запустил «update-initramfs -u -k all», и проблема исчезла.

AITap спасибо Вам за помощь.

Уважаемый ALTap, у меня еще возник вопрос относительно перезагрузки компьютера и выхода из сна.

А именно:

- когда я делаю перезагрузку, то на вид это похоже на смену сеанса, т.е. в терминале сначала бегут строки «выгрузки» и тут же сверху по ним строки загрузки. И складывается впечатление, что перезагрузка до конца не выполнена. По крайней мере когда я установил pulseaudio, то он не заработал при такой перезагрузке, пришлось «выключить» машину и включить заново.

- а при выходе из сна, наоборот, показывает выбор ядра и все как обычная загрузка, проавда, восстанавливает рабочее пространство до ухода в сон, благодаря Вашему содействию, - спасибо.

Так вот вопрос, каким образом можно настроить параметры перезагрузок? В гугле натыкаюсь на какую то фигню.

в терминале сначала бегут строки «выгрузки» и тут же сверху по ним строки загрузки.

Немного напоминает работу kexec. Вы могли случайно вытянуть kexec-tools по зависимостям, и те настроились на запуск ядра из самого ядра вместо аппаратной перезагрузки.
Если dpkg -l kexec-tools покажет, что пакет установлен, попробуйте запустить sudo dpkg-reconfigure kexec-tools и там отключить перезагрузку при помощи kexec.

Впрочем, это не должно влиять на «полноту» перезагрузки: операционная система при этом перезагружается полностью.

Если dpkg -l kexec-tools покажет, что пакет установлен

- установлен

попробуйте запустить sudo dpkg-reconfigure kexec-tools и там отключить перезагрузку при помощи kexec.

- он в режиме псевдографики спрашивает: «использовать ли пакет kexec-tools для обработки команд на перезагрузку», мне просто ответить - нет, и этого достаточно будет, или, может, пакет удалить?

Вроде поправилось, но восстановление после сна, все равно происходит через выбор ядра. Можно ли это изменить?

Загрузчик не обучен определять, после чего включается система: после обычного выключения, или после гибернации. Теоретически, это возможно, если указать GRUB2 раздел гибернации и скриптом проверять этот раздел на наличие определённой последовательности байт, но такого кода пока никто не написал.

А чем мешает выбор ядра, кроме потенциальной возможности выбрать не то ядро и потерять «несохранённые данные»? Ведь обычно никаких изменений в этом меню не нужно делать, достаточно запустить самое последнее из доступных?

В принципе, ничем не мешает, просто привык к этому когда сидел на Убунте. Сразу видно восстановление происходит или перезагрузка. Но дело привычки, привыкну и к этому. Буду продолжать настройку.

Спасибо Вам еще раз.

просто привык к этому когда сидел на Убунте. Сразу видно восстановление происходит или перезагрузка

Когда у меня была Ubuntu, я не пользовался гибернацией, но представляю, как ещё это можно сделать.

Можно написать hook для pm-tools, который при гибернации через grub-editenv записывает значение переменной timeout=0, а при восстановлении восстанавливает исходное значение.

Как это выглядело в Ubuntu? Что-то я не могу у них найти такого скрипта в пакете pm-utils.

Можно написать hook для pm-tools, который при гибернации через grub-editenv записывает значение переменной timeout=0, а при восстановлении восстанавливает исходное значение.

- звучит пугающе :)