Пару дней назад переустанавливал систему на ноутбуке. Во-первых, переразбил винт по-другому; во-вторых, сменил платформу на x86_64 (для Skype и прочей 32-битной пропиетарной ереси есть chroot). Домашний каталог, конечно же, поднял из Subversion'а. И, в-третьих, вообще настроил всё как следует.

Конечно, самым сложным было настроить suspend-to-RAM. Система со всеми наворотами грузится у меня долго, при загрузке надо вводить кучу паролей (LUKS+LVM, не хвост собачий), к тому же я ежедневно таскаю ноутбук в рюкзаке — короче, без нормально работающего suspend'а не жизнь.

Ядро у меня 2.6.26 из Debian stable (Lenny). Ноут зовётся MSI MegaBook M670. Среди железа в нём есть wifi-адаптер, про который lspci говорит «RaLink RT2561/RT61 rev B». Методом научного тыка выясняется: если соответствующий модуль (rt61pci) не поднят, то система засыпает и просыпается нормально. Если же wifi запущен, то система не просыпается, тупо виснет. Казалось бы, тривиальное дело — добавить один модуль к списку blacklisted modules тех скриптов, которые занимаются suspend'ом и resume. Отправляюсь в /etc искать нужный конфиг или нужные скрипты… и вот тут-то начался survival horror.

/etc/hibernate/blacklisted-modules — не оно.
/etc/apm/suspend.d — не оно.
/etc/acpi/suspend.d — не оно.
/etc/uswsusp.conf — мимо.
/etc/powersave — гусары, молчать.

Я знаю, что есть разные способы отпpавить систему спать: s2ram -f, hibernate-ram, powersave -u. Оказывается, что KDEшнеый KPowersave вызывает последний из них (а мне именно реакция кед на lid close наиболее интересна). Ещё немного поколдовав, сообразив-таки заглянуть в /var/log, я таки нахожу действительно использующиеся скрипты suspend'а — вообще за пределами /etc!

/usr/lib/pm-utils/sleep.d — ну кто бы мог подумать!

Дальше выясняется, что свои пять копеек надо вносить в /etc/pm/sleep.d, в котором совершенно пусто и нету ни одного skeleton'а соответствующего конфига. Что ж, это явно не тот случай, когда Debian можно назвать простой и понятной системой. Зато теперь всё работает как часы.