Bug 34466 - Живые дистрибутивы не выключаются, будучи загруженными по сети
Summary: Живые дистрибутивы не выключаются, будучи загруженными по сети
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: livecd-save-nfs (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Anton V. Boyarshinov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-18 19:09 MSK by Arseny Maslennikov
Modified: 2018-02-11 01:23 MSK (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arseny Maslennikov 2018-01-18 19:09:38 MSK
Выключение системы, загруженной по сети повисает.

При остановке сервиса etcnet (не понимаю, зачем он в большинстве _живых_ дистрибутивов, которые должны просто работать в любой, особенно динамической сетевой обстановке, но всё же) все сетевые интерфейсы, включая тот(те), по которому доступна rootfs, падают; это происходит слишком рано.

Если руками прописать DISABLED=yes в /etc/net/ifaces/$IF/options, баг не воспроизводится.

Если удалить из системы etcnet и попытаться выключить систему, баг не воспроизводится. :)

Надо решить, что делать в этом случае.
Сейчас livecd-save-nfs всем-всем-всем существующим сетевым конфигураторам (и networkd тоже, да) говорит: не трогать интерфейс!
Как выяснилось, etcnet всё равно не в курсе.

Product: sisyphus, потому что ветке sisyphus в gear-репе 4 года.
Comment 1 Arseny Maslennikov 2018-01-18 23:10:18 MSK
(In reply to comment #0)
> Сейчас livecd-save-nfs всем-всем-всем существующим сетевым конфигураторам (и
> networkd тоже, да) говорит: не трогать интерфейс!

Я оговорился: livecd-save-nfs знает только про NM и etcnet, а должен (если придерживаться такого подхода) про все (потенциально) используемые в дистрибутивах. Например, про networkd он не знает.

Надо было написать: сейчас livecd-save-nfs указывает всем существующим сетевым конфигураторам (которых знает) не трогать интерфейс(ы?), с которых производилась загрузка системы, и обслуживает их сам.

Как выяснилось, после "исправления" https://bugzilla.altlinux.org/show_bug.cgi?id=28499 etcnet не в курсе дел.
Comment 2 Arseny Maslennikov 2018-02-11 01:23:36 MSK
Наконец руки дошли.

Далее здесь буду обозначать интерфейс, через который можно добраться
до rootfs и который должен оставаться активным до system halt, именем `netboot0'.
(Кстати, кто сказал, что он:
 - не может меняться во время работы системы (при условии доступности rootfs по старому адресу), например, сетевой кабель переподсоединили;
 - их не может быть несколько? пример такого сразу на ум не приходит, к сожалению.
Это почва для дальнейших размышлений)

Могу предложить три способа решения проблемы:

1) Пусть, как ныне, etcnet контролирует интерфейс netboot0, но тогда нужно:
- либо научить etcnet стопиться прямо перед размонтированием корня (на двух инитах);
- либо научить etcnet понятию "критического сетевого соединения, которое не надо опускать без прямого требования администратора". Это как DISABLED=yes, но `ifdown netboot0` должна срабатывать.
Здесь нужно много думать, тестировать и поддерживать это потом.

2) Избавить netboot0 от влияния etcnet: DISABLED=yes.
Дальше можно пойти несколькими путями:
2.1) либо настраивать интерфейс через networkd (CriticalConnection=yes, только на системах с systemd, мопед не мой, я лишь слышал звон в странице руководства)
2.2) либо (видимо, предпочтительный вариант) мы себе сами настройщик сети [1]: dhcpcd --request -p netboot0

[1] http://git.altlinux.org/people/arseny/packages/livecd-save-nfs.git?p=livecd-save-nfs.git;a=shortlog;h=refs/heads/etcnet-disabled-yes

В будни потестирую эти коммиты вживую.