systemd готов к ноутбукам если уметь его побороть

Судя по ТСу, там ноут 1986 года с ЭЛТ-дисплеем

УМВР по дефолту.

Дистрибутив-то какой?

Нет, такой: https://www.dns-shop.ru/product/4a548cc6a6e83330/14-netbuk-irbis-nb43-belyj/c... .

Irbis

Нутыпонел.

Mageia 7 beta 3. Такое же поведение systemd на этом ноутбуке было и в 8-м Debian'е.

Знаем такое говно.

Это не systemd не готов. Это Irbis не готов делать нормальное железо.

Да, железо не очень. Но, и Слака работает из коробки, и systemd, оказывается, можно заставить работать на этом железе.

systemd-logind почему-то начинает считать, что я, якобы, постоянно схлопываю ноутбук, и сразу же начинает суспендиться

подтверждаю такое поведение в debian/fedora - очень, блин, бесит!

Так я и не говорю, что systemd не готов. Я пишу, что готов если знать что делать.

Со звуком проблем нет? У меня на похожей модели звук не работал, пока я вручную не скопировал конфиги алсы из какого-то форка на гитхабе.

Да, есть проблемы со звуком. Раньше и родной WiFi отсутствовал. Сейчас Магейя нашла WiFi. Пока ещё не пробовал устанавливать через него соединение.

Жаль, значит так и не починили в апстриме за полгода. Я уже не помню, откуда брал.

По каким-то причинам systemd считает, что у юнита xdm периодически заканчивается таймаут. И systemd внезапно перезапускает xdm. Пришлось подправить юнит прописав туда бесконечный таймаут.

Это баг в xdm. Я думал, его давно поправили.

См. тут https://bbs.archlinux.org/viewtopic.php?id=237592

Как переехал на ноутбуке с ubuntu 14.04 на 16.04 (где systemd во все поля, оставил его из соображений «надо всё-таки привыкать, ибо мейнстрим»), подобных проблем не наблюдал ни разу.

В апстриме, по ходу, не исправили, поскольку речь о свежем xdm'е 1.1.12, который вышел месяц назад. По ссылке речь о версии 1.1.11.

свежем xdm

Звучит как «свежая Пугачёва»

Насколько я знаю, над иксами сейчас не то чтобы много людей работают. Скорее всего, им просто насрать.

Ну, в целом-то всё работает.

systemd-logind почему-то начинает считать, что я, якобы, постоянно схлопываю ноутбук <…> Замаскировал таргеты

По каким-то причинам systemd считает, что у юнита xdm периодически заканчивается таймаут. <…> Пришлось подправить юнит прописав туда бесконечный таймаут.

Решение уровня saahriktu. Ты любую технологию превратишь в гору костылей.

А как по-Вашему правильнее?

Замаскировать таргеты, кстати, написано в Wiki Debian'а, откуда я копипастил команды:

For systems which should never attempt any type of suspension, these targets can be disabled at the systemd level with the following:

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

https://wiki.debian.org/Suspend

Стоп. Так этож отечественный ноутбук! Где там Чубайс, почему молчал всё это время?

Mageia 7 beta 3.

Сказало, что будет ставиться полтора часа в виртуалке. o_O

Мне инсталлятор тоже писал, что будет ставить 45 минут. А потом взял и шустро всё поставил.

Поставилась и даже работает. Надо будет жене дать потыкать.

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

Костыли для запуска на кривом железе, ух ты...

А как по-Вашему правильнее?

$ cat /etc/systemd/logind.conf
[Login]
<...>
HandleLidSwitch=ignore
<...>

Замаскировать таргеты, кстати, написано в Wiki Debian’а

For systems which should never attempt any type of suspension, …

Написано-то написано, только статья, из которой ты копипастил, решает другую задачу.

А потом эти люди прибегут на ЛОР жаловаться в ключе «сустемде сломало мне саспенд, какой плохой негодный поцтеринг!!1».

Ну так мне этот suspend и не нужен. Поэтому дополнительные меры тут вполне к месту. Те, кому он нужен, могут и не маскировать таргеты, никто же не против. Про systemd-logind я также писал в стартовом посте:

и поправил ему конфиг, чтобы игнорировал

сустемде сломало мне саспенд

Очевидно же, что маскировка таргетов его отключает.

Ну если ты это понимаешь — хорошо. Но в ОП написано, что ты решал другую задачу.

Нет, такой

Вышлите пожалуйста свою фоточку, хочу посмотреть кто покупает такое дно.

Ну, а чем он принципиально плох? Малым количеством памяти? Не всем нужно больше. Слабым процессором? Не всем нужно мощнее. По железу он гораздо мощнее Raspberry Pi.

Ну, а чем он принципиально плох?

• 1.Вот, я для тебя сделал сравнение
• 2. Говноматрица
• 3.Вай-вай = дно.
• Ну и на сладкое - eMMC накопитель и приблизительное время автономной работы 3 ч 30 мин + Вес 1.25 кг и обособленный блок питания.

1.Вот, я для тебя сделал сравнение

Не всем нужно мощнее.

2. Говноматрица

Не всем нужно лучше.

3.Вай-вай = дно

Не всем нужен WiFi. А на тот случай, если нужен, у меня есть внешний USB WiFi.

Ну и на сладкое - eMMC накопитель и приблизительное время автономной работы 3 ч 30 мин + Вес 1.25 кг и обособленный блок питания.

Не всем это критично.

Это всё мелочи. Вот неотключаемый 32-х битный UEFI - вот это заноза, да. Но с танцами через кучу флэшек туда можно протолкнуть любой дистрибутив.

А инсталлятор 7-й Магейи начиная с последней 3-ей беты уже поддерживает такое и без танцев. Просто записал на флэшку, просто загрузился и поставил мышкой. «Next», «Next» - и готово.

подтверждаю

Хз, чё за ноуты, у вас такие, УМВР

А как правильно решать эту проблему?

Тред не читай?

Это ж решение для суспенда или я не понял вопрос? Я то про таймаут спрашивал.

Зависит от проблемы. Я xdm не пользуюсь.

В любом случае, тут в треде мелькала ссылка на багрепорт с вердиктом “fixed in upstream”.

А, тогда ok. Я просто слегка опух с решения маскировкой по суспенду

В общем, тут можно:

1. научить systemd-logind игнорировать события;
2. запретить суспендиться на системном для systemd уровне;

Всего вариантов, соответственно, 4:

• systemd-logind не игнорирует события, systemd разрешено суспендиться;
• systemd-logind не игнорирует события, systemd запрещено суспендиться (в логи сыплются уведомления о событиях);
• systemd-logind игнорирует события, systemd разрешено суспендиться;
• systemd-logind игнорирует события, systemd запрещено суспендиться;

Я выбрал последний вариант, поскольку мне суспенд не нужен совсем. Но если юзеру нужно просто игнорировать события от захлопывания крышки, а сам суспенд, вызываемы другими методами, ему нужен, то ему нужно выбирать предпоследний вариант.

В любом случае, тут в треде мелькала ссылка на багрепорт с вердиктом “fixed in upstream”.

Выше не так было. Там была ссылка на древнюю тему на форуме Арча, где юзеры сами писали патчи. А до апстрима это ещё не дошло. В релизе месячной давности этот баг, как видно, всё ещё есть. И тут либо тащить тот патч с форума Арча, либо выставлять бесконечный таймаут в юните.

Да, действительно. Мне показалось.

выставлять бесконечный таймаут в юните

В любом случае, «решение» бесконечным таймаутом — глупость. Там нужно убрать Type=notify и выставить либо simple, либо forking в зависимости от поведения xdm.

Спасибо, попробую.

А у меня так работает:

[Unit]
Description=X-Window Display Manager
After=systemd-user-sessions.service

[Service]
ExecStart=/usr/bin/xdm -nodaemon -config /etc/X11/xdm/archlinux/xdm-config
Type=notify
NotifyAccess=all

[Install]
Alias=display-manager.service

xorg-xdm 1.1.12-1

Вот, вот. Софт обязательно нужно переписывать каждый год! Когда уже замена Wayland будет?

По каким-то причинам systemd считает, что у юнита xdm периодически заканчивается таймаут. И systemd внезапно перезапускает xdm.

Всё¸ больше в 7-й Магейе такого бага нет. Маинтейнеры пропатчили xdm: http://svnweb.mageia.org/packages?view=revision&revision=1399593 .