(no subject)
Wednesday, March 4th, 2009 23:41![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kastanedaПару дней назад переустанавливал систему на ноутбуке. Во-первых, переразбил винт по-другому; во-вторых, сменил платформу на 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 можно назвать простой и понятной системой. Зато теперь всё работает как часы.
Конечно, самым сложным было настроить 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 можно назвать простой и понятной системой. Зато теперь всё работает как часы.