- Ubuntu 8.04.1 (Hardy Heron).
- Dell XPS M1530.
Через ядро линукса
Для гибернейта достаточно использовать встроенные средства Ubuntu: pm-utils и прочие скрипты. При нажатии кнопки питания Gnome опрашивает через DBus события PowerManager.CanSuspend & PowerManager.CanHibernate (видимо, чтоб включить или заморозить соответствующие кнопки). Когда юзер нажимает кнопку, посылается событие PowerManager.Suspend/Hibernate. Вероятнее всего, они попадают в скрипт /usr/lib/hal/system/linux/…-power-suspend.sh (или …-hibernate.sh). Оттуда вызывается pm-utils (команды pm-suspend, pm-hibernate; лежат в папке /usr/sbin). Они как раз и разруливают способы заморозки: либо через s2disk/s2mem/s2both при их наличии, либо через механизмы ядра при отсутвии. Поэтому важно чтобы пакет uswsusp не был установлен вообще, если хотим пользоваться механизмами ядра.
Заморозка (suspend & hibernate), в принципе, работают сами по себе. Для восстановления (resume) системы нужно прописать некоторые конфиги, забытие по умолчанию. В частности, в /boot/grub/menu.lst добавить к пункту по умолчанию сразу после root=UUID=xyz…xyz параметр resume=UUID=уид_свап_раздела. UUID свап-раздела можно получить командой vol_id /dev/sda5 (если свап на разделе sda5). Ещё писали что нужно убедиться что этот же разлел указана в /etc/initramfs-tools/conf.d/resume (строка RESUME=UUID=уид_свапраздела); но он там сам появляется. Если придётся вписывать — то нужно запустить update-initramfs.
Сложности, по слухам, возникают из-за драйвера nvidia (не путать с nv; nvidia — это проприетарный драйвер от производителя). Для решения этих проблем рекомендуется в /etc/defaults/acpi-support заменить значения:
MODULES="nvidia" # (спорно; я его внёс и в WHITELIST, так что не влияет). SAVE_VBE_STATE=false POST_VIDEO=false USE_DPMS=false DISABLE_DMA=true
И в файле /etc/X11/xorg.conf в секцию с видеокартой (которая имеет driver «nvidia») вписать:
option "NvAGP" "1"
А в файле /etc/modprobe.d/blacklist добавить
blacklist agpgart
Фактически, судя по экспериментам, ничего из этого не влияет на результат; или, по крайней мере, acpi-support точно. Более того, оно скорее всего даже не учитывается. Надо провести более точные эксперименты, и выяснить, что реально нужно, а что – нет.
А вот реальная проблема — это белый экран после восстановления, причём только после второго или третьего и всех последующих восстановлений (после первого обычно всё ок). Причина — в баге не то compiz, не то gnome-screensaver. Говорят, compiz-core из proposed решает проблему (не проверял). Я просто отключил запрос пароля при выходе из суспенда: gconf-editor, и там включить галочку /apps/gnome-power-manager/lock/use_screensaver_settings, а в настройках скринсейвера (через меню «Система-Параметры») отключить запрос пароля. Так или иначе, даже когда попадаешь в этот белый экран, можно ввести пароль и рабочий стол разблокируется.
Через uswsusp (s2disk & s2both)
Использовать s2disk & s2both из пакета uswsusp нежелательно, потому что оно иногда падает в корку в процессе сохранения (вот конфуз!). При этом можно вернуться в графическую среду и продолжить работу. Но управление питанием уже будет сбоить, потому что в какое-то промежуточное состояние система уже перешла.
Кроме того, ради каких-то переделок из пакета убрали s2mem, в итоге суспенд работает через мезанизм ядра, а гибернейт — через s2disk. Что вообще нелогично.
Ещё баг — пакет ставит файлы в /sbin, а система их ищет в /usr/sbin. Надо создать симлинки чтобы всё работало с ними:
ln -s /sbin/s2disk /usr/sbin/ ln -s /sbin/s2both /usr/sbin/ ln -s /sbin/resume /usr/sbin/
Чтобы заменить дефолтное поведение гибернейта, который сохраняет только на диск, на сохранение на диск+память, нужно в /etc/pm/config.d/ создать файл, например, force2both.sh, и туда вписать S2DISK_BIN=»/usr/sbin/s2both» (это симлинк; можно вписать и /sbin/s2both, но другие файлы оно всё равно будет искать в /usr/sbin, так что симлинки нужны).