pppoe и nvidia: очерёдность запуска и другие тонкие моменты

Ситуация "до" (всё работает):
  1. Имею pppoe подключение, которым занимается следующий юнит (запускается при старте системы):
    [Unit]
    Description=PPP link to %I
    Before=network.target
    [Service]
    ExecStartPre=/usr/sbin/ip link set dev enp3s0 up
    ExecStart=/usr/sbin/pppd call %I nodetach
    [Install]
    WantedBy=multi-user.target

Ситуация "во время" (все сломалось):
  1. Втыкаю видюху nvidia, интерфейс локалки меняется с enp2s0 на enp3s0
  2. Правлю юнит и конфиг подключения (peers/provider)
  3. Во время перезагрузки ppp не поднимается
  4. Через systemctl status выясняю, что система спотыкается на ExecStartPre, и по заставке nvidia, которая появляется уже после провала ppp, понимаю, что интерфейс ещё не успел создаться, а юнит его уже пытается поднять
  5. Через systemd-analyze plot выясняю, что существует некий sys-devices-pci0000:00-0000:00:1c.4-0000:03:00.0-net-enp3s0.device, который, видимо, сигнализирует о том, что systemd таки увидел сетевуху

Ситуация "после" (подставил костыль):
  1. Меняю заголовок юнита на:
    [Unit]
    Description=PPP link to %I
    Requires=sys-devices-pci0000:00-0000:00:1c.4-0000:03:00.0-net-enp3s0.device
    After=sys-devices-pci0000:00-0000:00:1c.4-0000:03:00.0-net-enp3s0.device
    Before=network.target
  2. Всё работает.

Теперь вопрос. Нет ли более простого пути? Может быть есть возможность хотя бы название юнита-девайса выяснить иначе?
И бонусный вопрос: почему в журнале выхлоп ppp пишется 2 раза?
Простой путь, конечно есть :)
Посылаем в баню такие "постоянные" имена интерфейсов, которые, как выяснилось, не совсем постоянные, и либо переходим на "ядерные" дефолтные, либо назначаем свои по MAC-адресу, к примеру.
Что касается очерёдности создания устройств и подъёма сети, то я и безо всяких такого рода глюков давно понял, что лучше не заставлять их конкурировать между собой, всё равно диск один, и модули (устройств и сети) от этого быстрее не загрузятся. Так что systemd-udev-settle.service я прописал в basic.target.wants/

Насчёт двух раз – как это выглядит? Каждое сообщение удваивается? Или...?
Посылаем в баню такие "постоянные" имена интерфейсов, которые, как выяснилось, не совсем постоянные, и либо переходим на "ядерные" дефолтные, либо назначаем свои по MAC-адресу, к примеру.
Думал об этом, но это как-то слишком уж просто :) Кстати, может быть я глупость скажу, но не из-за того ли меняется номер, что управление берёт на себя видюха? Вот звук там точно есть (хотя нет аудио-выходов), может и с сетью так? Не запутается ли systemd или ядро, или кто-то ещё в интерфейсах?

Так что systemd-udev-settle.service я прописал в basic.target.wants/
"Всё найти, потом думать дальше"... Спасибо, интересный момент, надо будет об этом почитать.

Насчёт двух раз – как это выглядит?
Обратите внимание на время:
июн 11 02:35:02 arch pppd[241]: Plugin rp-pppoe.so loaded.
июн 11 02:35:02 arch pppd[241]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.5
июн 11 02:35:02 arch pppd[241]: pppd 2.4.5 started by root, uid 0
июн 11 02:35:07 arch pppd[241]: PPP session is 60097
июн 11 02:35:08 arch pppd[241]: Connected to _____ via interface enp3s0
июн 11 02:35:08 arch pppd[241]: Using interface ppp0
июн 11 02:35:11 arch pppd[241]: Connect: ppp0 <--> enp3s0
июн 11 02:35:12 arch pppd[241]: CHAP authentication succeeded
июн 11 02:35:12 arch pppd[241]: peer from calling number _____ authorized
июн 11 02:35:12 arch pppd[241]: Cannot determine ethernet address for proxy ARP
июн 11 02:35:12 arch pppd[241]: local  IP address _____
июн 11 02:35:12 arch pppd[241]: remote IP address _____
июн 11 02:35:12 arch pppd[241]: Plugin rp-pppoe.so loaded.
июн 11 02:35:12 arch pppd[241]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.5
июн 11 02:35:12 arch pppd[241]: PPP session is 60097
июн 11 02:35:12 arch pppd[241]: Connected to _____ via interface enp3s0
июн 11 02:35:12 arch pppd[241]: Using interface ppp0
июн 11 02:35:12 arch pppd[241]: Connect: ppp0 <--> enp3s0
июн 11 02:35:12 arch pppd[241]: CHAP authentication succeeded
июн 11 02:35:12 arch pppd[241]: peer from calling number _____ authorized
июн 11 02:35:12 arch pppd[241]: Cannot determine ethernet address for proxy ARP
июн 11 02:35:12 arch pppd[241]: local  IP address _____
июн 11 02:35:12 arch pppd[241]: remote IP address _____
Видюха это железка, она не может "брать на себя управление". Номер это адрес на шине, к которой, очевидно, подключается и видюха. Номер меняется либо из-за совпадения, либо просто из-за изменения очерёдности.
Чтобы имя интерфейса не менялось – просто привяжите его к какому-нибудь другому параметру, независимому от шины.

Что касается времени, вы пробовали
journalctl -b -o short-monotonic
?
Может я не так выразился, но ведь звуком-то она может управлять? Почему бы не управлять и сетью?

# journalctl -o short-monotonic -u ppp@provider
-- Reboot --
[   18.674226] arch pppd[245]: Plugin rp-pppoe.so loaded.
[   18.722926] arch pppd[245]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.5
[   18.723032] arch pppd[245]: pppd 2.4.5 started by root, uid 0
[   18.723194] arch pppd[245]: PPP session is 4820
[   18.723291] arch pppd[245]: Connected to _____ via interface enp3s0
[   18.723400] arch pppd[245]: Using interface ppp0
[   18.723497] arch pppd[245]: Connect: ppp0 <--> enp3s0
[   18.723593] arch pppd[245]: CHAP authentication succeeded
[   18.723686] arch pppd[245]: peer from calling number _____ authorized
[   18.846929] arch pppd[245]: Cannot determine ethernet address for proxy ARP
[   18.847223] arch pppd[245]: local  IP address _____
[   18.847366] arch pppd[245]: remote IP address _____
[   18.921884] arch pppd[245]: Plugin rp-pppoe.so loaded.
[   18.935575] arch pppd[245]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.5
[   18.935776] arch pppd[245]: PPP session is 4820
[   18.935905] arch pppd[245]: Connected to _____ via interface enp3s0
[   18.936028] arch pppd[245]: Using interface ppp0
[   18.936149] arch pppd[245]: Connect: ppp0 <--> enp3s0
[   18.936270] arch pppd[245]: CHAP authentication succeeded
[   18.936392] arch pppd[245]: peer from calling number _____ authorized
[   18.936513] arch pppd[245]: Cannot determine ethernet address for proxy ARP
[   18.936634] arch pppd[245]: local  IP address _____
[   18.936778] arch pppd[245]: remote IP address _____
Ну вот, теперь видно, что время разное.

но ведь звуком-то она может управлять
Что вы называете "управлять звуком"? У видеокарты есть своё аудиоустройство? При втыкании видеокарты оно грузится первым и становится дефолтным?
Так это не видеокарта "управляет", это модули в таком порядке грузятся. И вы наверняка знаете, как настраивается порядок аудиоустройств через конфиги modprobe.
Разумеется, видеокарта ничем не управляет – управляют только программы – ядро, modprobe, udev, systemd и т.д.
Ну вот, теперь видно, что время разное.
Есть предположения, почему так? И только ли у меня одного это появляется?

Что вы называете "управлять звуком"?
"Управлять" на моём кривом диалекте = обрабатывать, выводить, предоставлять железные мощности под обработку. Т.е. не на программном уровне, а на железном. До втыкания видюхи изображением "управляло" графическое ядро в процессоре, после - видюха.

Касательно звука, я имею в виду, что после подключения видюхи в alsamixer появляется ещё одна звуковая карта, хотя на самой видюхе нет аудиовыхода. Это, и смена номера сетевого интерфейса позволяют (мне) предположить, что видюха предоставляет не только звуковую, но ещё и сетевую карту. С другой стороны, новый сетевой интерфейс не появляется, так что скорее всего я не прав.
Если аудиоустройство появляется, значит оно есть на видеокарте. Выход может быть не припаян, или даже не разведён на плате, он устройство есть. Кроме того, это может быть цифровой выход, через какой-нибудь HDMI.

Имя сетевого интерфейса присваивается правилом udev, которое сочиняет его, в вашем случае, из адреса устройства на шине. На этой же шине есть и другие устройства, не имеющие никакого отношения к сети, и некоторые из них находятся на видеокарте.

P.S.
Посмотрел доки:
http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20
Ваше именование сетевых устройств действительно берётся из адреса на шине PCI(e) , в чём вы можете убедиться через lspci
$ udevadm test-builtin net_id /sys/class/net/eth0 2>&1 |grep PATH
ID_NET_NAME_PATH=enp2s0
$ lspci|grep -i ethernet
02:00.0 Ethernet controller: Qualcomm Atheros AR8151 v2.0 Gigabit Ethernet (rev c0)
$ udevadm test-builtin net_id /sys/class/net/eth0 2>&1 |grep PATH
ID_NET_NAME_PATH=enp0s7
$ lspci|grep -i ethernet
00:07.0 Bridge: NVIDIA Corporation MCP61 Ethernet (rev a2)
Хм. Значит сетевухи на видеокарте у меня таки нет, но есть звук, ибо:
[ls@arch ~]$ lspci | grep -i qualcomm
03:00.0 Ethernet controller: Qualcomm Atheros AR8151 v2.0 Gigabit Ethernet (rev c0)
[ls@arch ~]$ lspci | grep -i nvidia
01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GK107 HDMI Audio Controller (rev a1)

А у вас откуда сетевуха nvidia появилась? Или это с другой машины (они ведь вроде не только графику, но и другую начинку когда-то делали)?

И ещё про basic.target я что-то не нагуглю ничего вразумительного. Вы каким-то образом юнит systemd-udev-settle.service поменяли или как?
Хм. Значит сетевухи на видеокарте у меня таки нет
Судя по именованию- удев(системд) считает -- есть
Ситуация "до" (всё работает):
Ну было - 3г модемы ромом определяло. Правилось соответствующим вендоридом для соответсвующего контроллера модема. И то- это из-за сохраняющегося параметра в свистке

Они заполонили
 
Зарегистрироваться или войдите чтобы оставить сообщение.