# systemd-analyze critical-chain graphical.target @34.627s └─lightdm.service @34.581s +45ms └─systemd-user-sessions.service @31.086s +14ms └─network.target @31.081s └─NetworkManager.service @30.957s +122ms └─network.service @30.872s +84ms └─livecd-save-nfs.service @302ms +30.567s └─systemd-journald.socket @291ms └─system.slice @282ms └─-.slice @282ms Пытается "вручную" поднять интерфейс [1], в котором нет шнурка. [1] зачем - не ясно, NetworkManager прекрасно с этим справляется
Вообще, идея этого сервиса состоит в том, что при загрузке livecd по nfs важно обеспечить непрерывность доступности сетевого соединения от начальной загрузки и до самого конца. Если NetworkManager начнёт переустанавливать это соединение, он выбьет из под себя файловую систему. Но вообще странно, он должен пытаться осторожно потрогать только уже поднятый интерфейс, если он пытается сделать это с опущенным интерфейсом -- где-то ошибка, но неочевидно где.
Не показывает ли на вашем оборудовнии, случайно, интерфейс без провода "state UP"?
(In reply to Anton V. Boyarshinov from comment #2) > Не показывает ли на вашем оборудовнии, случайно, интерфейс без провода > "state UP"? Таки да: > Пытается "вручную" поднять интерфейс [1], в котором нет шнурка.
(In reply to Anton V. Boyarshinov from comment #1) > Вообще, идея этого сервиса состоит в том, что при загрузке livecd по nfs > важно обеспечить непрерывность доступности сетевого соединения от начальной > загрузки и до самого конца. Во-первых, сетевые загрузки бывают по http и ftp, и для них непрерывная доступность сети не нужна (на самом деле, после скачивания stage2 сеть вовсе не требуется) Во-вторых, не ясно, чем dhclient лучше (или хуже) NetworkManager. Что тот, что другой настраивают сетевой интерфейс по dhcp (и при этом может даже IP адрес поменяться). Я бы понял - вообще не трогать сетевой интерфейс, с которого загрузились.
(In reply to Anton V. Boyarshinov from comment #1) > Но вообще странно, он должен пытаться осторожно потрогать только уже > поднятый интерфейс, если он пытается сделать это с опущенным интерфейсом -- > где-то ошибка, но неочевидно где. Да вот здесь же: http://git.altlinux.org/gears/l/livecd-save-nfs.git?p=livecd-save-nfs.git;a=blob;f=livecd-save-nfs/livecd-save-nfs;h=c4e220cefca94f33abd97cd1c0d1bc9435b153b0;hb=b65c2dcac5543be066a680d6390bb5f31edec043#l20 # ip -o link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000\ link/ether 00:26:58:42:93:79 brd ff:ff:ff:ff:ff:ff 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000\ link/ether 00:26:58:42:93:7a brd ff:ff:ff:ff:ff:ff В строке eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000\ link/ether 00:26:58:42:93:7a brd ff:ff:ff:ff:ff:ff совпадает ',UP>', но на самом-то деле 'state DOWN'. Правильно так: $ cat /sys/class/net/eth1/operstate down
(In reply to Anton V. Boyarshinov from comment #1) > Вообще, идея этого сервиса состоит в том, что при загрузке livecd по nfs > важно обеспечить непрерывность доступности сетевого соединения от начальной > загрузки и до самого конца. И ещё неясно - зачем нужно *синхронно* получать адрес. Сделали конфиг, запустили dhcpcd в фоне, и вышли.
#284328 BUILDING #1 [locked] [test-only] sisyphus livecd-save-nfs.git=0.4.2-alt1
livecd-save-nfs-0.4.2-alt1 -> sisyphus: Wed Sep 01 2021 Alexey Sheplyakov <asheplyakov@altlinux> 0.4.2-alt1 - Ignore interfaces which are down or have no carrier (closes: #40800) - Immediately fork dhcpcd into the background (related: #40800) - Act only when booted via NFS or CIFS (related: #40800)
