Bug 45273

Добрый день!

Пожалуйста, дополнительно предоставьте следующую информацию:

1. Операционная система, версия, на которой воспроизвелась ошибка (желательно официально вышедшие, пока предполагаю, что у Вас ALT Workstation K 10.1).
2. Выводы следующих команд:

        $ uname -a
        $ cat /etc/os-release
        $ apt-repo

3. Описание шагов для воспроизведения ошибки, желательно с указанием того, какая сетевая подсистема указана для каждого интерфейса. Это можно сделать так: Меню приложений → Центр управления системой → Сеть → Ethernet-интерфейсы → выбрать сетевой интерфейс → нажать Дополнительно, посмотреть пункт Сетевая подсистема.

(Ответ для Evgeny Shesteperov на комментарий #1)
> Добрый день!
> 
> Пожалуйста, дополнительно предоставьте следующую информацию:
> 
> 1. Операционная система, версия, на которой воспроизвелась ошибка
> (желательно официально вышедшие, пока предполагаю, что у Вас ALT Workstation
> K 10.1).
> 2. Выводы следующих команд:
> 
>         $ uname -a
>         $ cat /etc/os-release
>         $ apt-repo
> 
> 3. Описание шагов для воспроизведения ошибки, желательно с указанием того,
> какая сетевая подсистема указана для каждого интерфейса. Это можно сделать
> так: Меню приложений → Центр управления системой → Сеть →
> Ethernet-интерфейсы → выбрать сетевой интерфейс → нажать Дополнительно,
> посмотреть пункт Сетевая подсистема.

[root@ASB09 ~]# uname -a
Linux ASB09 5.15.72-un-def-alt1 #1 SMP PREEMPT Mon Oct 10 16:11:20 UTC 2022 x86_64 GNU/Linux
[root@ASB09 ~]# cat /etc/os-release
NAME="ALT"
VERSION="10.1"
ID=altlinux
VERSION_ID=10.1
PRETTY_NAME="ALT Workstation K 10.1  (Sorbaronia Mitschurinii)"
ANSI_COLOR="1;33"
CPE_NAME="cpe:/o:alt:kworkstation:10.1"
BUILD_ID="ALT 10.1"
HOME_URL="https://www.basealt.ru/"
BUG_REPORT_URL="https://bugs.altlinux.org/"
DOCUMENTATION_URL="https://docs.altlinux.org/"
SUPPORT_URL="https://support.basealt.ru/"
[root@ASB09 ~]# apt-repo
rpm [p10] http://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/x86_64 classic gostcrypto
rpm [p10] http://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/x86_64-i586 classic
rpm [p10] http://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/noarch classic

(Ответ для Evgeny Shesteperov на комментарий #1)
> Добрый день!
> 
> Пожалуйста, дополнительно предоставьте следующую информацию:
> 
> > 3. Описание шагов для воспроизведения ошибки, желательно с указанием того,
> какая сетевая подсистема указана для каждого интерфейса. Это можно сделать
> так: Меню приложений → Центр управления системой → Сеть →
> Ethernet-интерфейсы → выбрать сетевой интерфейс → нажать Дополнительно,
> посмотреть пункт Сетевая подсистема.

Проблема динамически меняются порты местами, система всегда выбирает иной адаптер на котором нет провода и нет интернета.
Действия не включать сетевой интерфейс при загрузке характеризуется одинаковым поведением для всех.

Таких ситуаций не должно повторяться с etc и networkmanager. Также должно быть свободное переключение интерфейса.

Заметил есть подключаться автоматически с приоритетом 
может это оно решение проблемы?
Только в alterator этого нет

(Ответ для kessys на комментарий #4)
> Заметил есть подключаться автоматически с приоритетом 
> может это оно решение проблемы?
> Только в alterator этого нет

1. Покажите, пожалуйста, вывод команд:

    # ip link show
    # lspci | grep -i 'net'

2. Вывод для каждого интерфейса (один PCi, один родной): Меню приложений → Центр управления системой (# acc) → Сеть → Ethernet-интерфейсы → выбрать сетевой интерфейс → нажать Дополнительно, посмотреть пункт Сетевая подсистема.

(Ответ для Evgeny Shesteperov на комментарий #5)
> (Ответ для kessys на комментарий #4)
> > Заметил есть подключаться автоматически с приоритетом 
> > может это оно решение проблемы?
> > Только в alterator этого нет
> 
> 1. Покажите, пожалуйста, вывод команд:
> 
>     # ip link show
>     # lspci | grep -i 'net'
> 
> 2. Вывод для каждого интерфейса (один PCi, один родной): Меню приложений →
> Центр управления системой (# acc) → Сеть → Ethernet-интерфейсы → выбрать
> сетевой интерфейс → нажать Дополнительно, посмотреть пункт Сетевая
> подсистема.

 
[alt@beta210 ~]$ ip link show
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> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:0e:2e:45:12:5f brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 2c:41:38:87:ae:08 brd ff:ff:ff:ff:ff:ff
4: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether ce:af:2d:48:dc:ff brd ff:ff:ff:ff:ff:ff permaddr 28:87:ba:a4:41:85
[alt@beta210 ~]$ lspci | grep -i 'net'
10:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188EE Wireless Network Adapter (rev 01)
1e:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5723 Gigabit Ethernet PCIe (rev 10)
30:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10)

2. Когда они имеют etcnet параметр, то ничего кроме настроек нет

Также если одному поставить поведение неконтролируемый, то он находится в выкл состоянии и не бегает не меняется местами, но это не дело.

(Ответ для kessys на комментарий #7)
> Также если одному поставить поведение неконтролируемый, то он находится в
> выкл состоянии и не бегает не меняется местами, но это не дело.

Что за поведение "неконтролируемый"? Позвольте выражаться точнее.

(Ответ для Evgeny Shesteperov на комментарий #8)
> (Ответ для kessys на комментарий #7)
> > Также если одному поставить поведение неконтролируемый, то он находится в
> > выкл состоянии и не бегает не меняется местами, но это не дело.
> 
> Что за поведение "неконтролируемый"? Позвольте выражаться точнее.

В настройках в alterator сеть
Вроде дополнительно - и далее выбор etcnet, networkmanager(etcnet), networkmanager(native), неконтролируемый

(In reply to kessys from comment #6)

> 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode

Сейчас нельзя использовать имена вида ethX: https://bugzilla.altlinux.org/29280
И там ссылка в последнем комментании про то, что это теперь не баг, а фича.

https://bugzilla.altlinux.org/29280
Вешать это на alt k10 и продавать юр лицам, как-то не прикольно

(Ответ для Sergey Y. Afonin на комментарий #10)
> (In reply to kessys from comment #6)
> 
> > 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
> > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode
> 
> Сейчас нельзя использовать имена вида ethX:
> https://bugzilla.altlinux.org/29280
> И там ссылка в последнем комментании про то, что это теперь не баг, а фича.

Они поставляются из коробки в alt k10 и соответственно на пк с 1 сетевой картой проблем типо нет, а вот если ноут или ещё что, вот тут начинается.

(In reply to kessys from comment #11)

> https://bugzilla.altlinux.org/29280
> Вешать это на alt k10 и продавать юр лицам, как-то не прикольно

Я давно предлагал использовать имена etherX по умолчанию. А переименовывать посредством правил из соответствующим образом настроенного пакета udev-rule-generator-net: bug 32167

Или, если кому нравится, для формирования link-файлов правила написать.

(In reply to Sergey Y. Afonin from comment #13)
> (In reply to kessys from comment #11)
> 
> > https://bugzilla.altlinux.org/29280
> > Вешать это на alt k10 и продавать юр лицам, как-то не прикольно
> 
> Я давно предлагал использовать имена etherX по умолчанию. А переименовывать
> посредством правил из соответствующим образом настроенного пакета
> udev-rule-generator-net: bug 32167
> 
> Или, если кому нравится, для формирования link-файлов правила написать.

Если что, это для релиз-менеджеров дистрибутивов комментарий.

(In reply to kessys from comment #12)

> Они поставляются из коробки в alt k10 и соответственно на пк с 1 сетевой
> картой проблем типо нет, а вот если ноут или ещё что, вот тут начинается.

А ноут почему? Там же WiFi именуется обычно wlan? С ноутом прыгать не должно.

(In reply to Sergey Y. Afonin from comment #10)

> > 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
> > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode
> 
> Сейчас нельзя использовать имена вида ethX:
> https://bugzilla.altlinux.org/29280
> И там ссылка в последнем комментании про то, что это теперь не баг, а фича.

Заодно напишу, что enp* использовать тоже не хорошо. Даже если не смотреть на читабельность, они тоже не отличаются постоянством. Формирование имён может завистеть от особенностей ядра (https://bugzilla.altlinux.org/28955#c33), либо от состава установленного оборудования, то есть именование может нарушить доустановка/изъятие любого PCI устройства, не только сетевой карты.

(Ответ для Sergey Y. Afonin на комментарий #15)
> (In reply to kessys from comment #12)
> 
> > Они поставляются из коробки в alt k10 и соответственно на пк с 1 сетевой
> > картой проблем типо нет, а вот если ноут или ещё что, вот тут начинается.
> 
> А ноут почему? Там же WiFi именуется обычно wlan? С ноутом прыгать не должно.

На локальном пользовании проблем нет, а вот при домене могут быть

(In reply to kessys from comment #17)

> На локальном пользовании проблем нет, а вот при домене могут быть

Все переименования интерфейсов происходят задолго до старта не то, что Самбы, а сети вообще. В общем проблема c eth0/eth1/и т.д. есть, она вполне понятна, да и путь решения давно есть, но никакие домены тут точно не при чём.

(Ответ для Sergey Y. Afonin на комментарий #18)
> (In reply to kessys from comment #17)
> 
> > На локальном пользовании проблем нет, а вот при домене могут быть
> 
> Все переименования интерфейсов происходят задолго до старта не то, что
> Самбы, а сети вообще. В общем проблема c eth0/eth1/и т.д. есть, она вполне
> понятна, да и путь решения давно есть, но никакие домены тут точно не при
> чём.
Вот как вой

(Ответ для Sergey Y. Afonin на комментарий #18)
> (In reply to kessys from comment #17)
> 
> > На локальном пользовании проблем нет, а вот при домене могут быть
> 
> Все переименования интерфейсов происходят задолго до старта не то, что
> Самбы, а сети вообще. В общем проблема c eth0/eth1/и т.д. есть, она вполне
> понятна, да и путь решения давно есть, но никакие домены тут точно не при
> чём.
Вот как войти под доменным пользователем, если udev поменял местами 2 сетевых интерфейса, а при логине этого не увидишь. И хорошо если пк рядом, а если далеко?

(In reply to kessys from comment #20)

> > Все переименования интерфейсов происходят задолго до старта не то, что
> > Самбы, а сети вообще. В общем проблема c eth0/eth1/и т.д. есть, она вполне
> > понятна, да и путь решения давно есть, но никакие домены тут точно не при
> > чём.

> Вот как войти под доменным пользователем, если udev поменял местами 2
> сетевых интерфейса, а при логине этого не увидишь. И хорошо если пк рядом, а
> если далеко?

Очевидно следует устранить проблему с переименованием интерфейсов (например, как я в комментарии 13 написал), чтобы сеть вообще работала. А потом уже решать прикладные задачи.

Версия

-   etcnet-0.9.29-alt1

Дистрибутивы

-   ALT KWorkstation 10.1, обновленный до текущего Sisyphus.

Предусловия

Виртуальная машина на Proxmox Virtual Environment с одним сетевым
интерфейсом (eth0).

Шаги воспроизведения (первый вариант)

1.  Добавить к виртуальной машине ещё два сетевых интерфейса (eth1,
    eth2). Дополнительно: IP все интерфейсы получают по DHCP.

    # ip link show

    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 fq_codel state UP mode DEFAULT group default qlen 1000
        link/ether 2a:4f:b8:9b:04:63 brd ff:ff:ff:ff:ff:ff
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
        link/ether 46:9c:b5:35:f3:c0 brd ff:ff:ff:ff:ff:ff
    4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
        link/ether a6:00:8f:3b:70:78 brd ff:ff:ff:ff:ff:ff

2.  Выключить виртуальную машину:

    # poweroff

3.  Удалить второй сетевой интерфейс (eth1). В веб-интерфейсе
    отображается как net1.
4.  Включить виртуальную машину
5.  Проверить имена сетевых интерфейсов:

    # ip link show

Ожидаемый результат примерно такой:

    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 fq_codel state UP mode DEFAULT group default qlen 1000
        link/ether 2a:4f:b8:9b:04:63 brd ff:ff:ff:ff:ff:ff
    3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
        link/ether a6:00:8f:3b:70:78 brd ff:ff:ff:ff:ff:ff

Фактический результат:

    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 fq_codel state UP mode DEFAULT group default qlen 1000
        link/ether 2a:4f:b8:9b:04:63 brd ff:ff:ff:ff:ff:ff
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
        link/ether a6:00:8f:3b:70:78 brd ff:ff:ff:ff:ff:ff

Дополнительно: в ALT Server 10.1 не воспроизводится.

Шаги воспроизведения (второй вариант)

Тут намного нагляднее, так как используется статика.

1.  Добавить к виртуальной машине ещё два сетевых интерфейса (eth1,
    eth2).
2.  Включить виртуальную машину.
3.  Через модуль альтератора Ethernet-интерфейсы изменить сетевую
    подсистему на Etcnet для каждого модуля (# acc → Ethernet-интерфейсы
    → Дополнительно → Сетевая подсистема → Etcnet) и настроить
    статический IP, шлюз, домены поиска и так далее.
4.  Проверить IP-адреса и имена сетевых интерфейсов. Сравнить с
    настройками из etcnet:

    # ip -c a show eth1
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
        link/ether 22:df:2a:90:d4:f9 brd ff:ff:ff:ff:ff:ff
        inet 10.YY.XX.7/21 brd 10.88.15.255 scope global eth1
           valid_lft forever preferred_lft forever
        inet6 fe80::20df:2aff:fe90:d4f9/64 scope link 
           valid_lft forever preferred_lft forever

    # ip -c a show eth2
    4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
        link/ether aa:87:7e:f8:e0:19 brd ff:ff:ff:ff:ff:ff
        inet 10.YY.XX.233/21 brd 10.88.15.255 scope global eth2
           valid_lft forever preferred_lft forever
        inet6 fe80::a887:7eff:fef8:e019/64 scope link 
           valid_lft forever preferred_lft forever

    # cat /etc/net/ifaces/eth1/ipv4address
    10.YY.XX.7/21

    # cat /etc/net/ifaces/eth2/ipv4address
    10.YY.XX.233/21

5.  Выключить виртуальную машину:

    # poweroff

6.  Удалить второй сетевой интерфейс (eth1). В веб-интерфейсе
    отображается как net1.
7.  Включить виртуальную машину.
8.  Проверить имена сетевых интерфейсов и сравнить с настройками из
    etcnet:

    # ip -c a show eth1
    # ip -c a show eth2
    # cat /etc/net/ifaces/eth1/ipv4address
    # cat /etc/net/ifaces/eth2/ipv4address

Ожидаемый результат: eth1 нет, остался eth2 и настроен корректно.

Фактический результат: eth2 нет, eth1 теперь настроен как eth2:

    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
        link/ether aa:87:7e:f8:e0:19 brd ff:ff:ff:ff:ff:ff
        inet 10.YY.XX.7/21 brd 10.88.15.255 scope global eth1
           valid_lft forever preferred_lft forever
        inet6 2a0c:88c0:2:2000:a887:7eff:fef8:e019/64 scope global dynamic mngtmpaddr 
           valid_lft 86387sec preferred_lft 14387sec
        inet6 fe80::a887:7eff:fef8:e019/64 scope link 
           valid_lft forever preferred_lft forever
    # cat /etc/net/ifaces/eth1/ipv4address
    10.YY.XX.7/21

То есть в результате данных действий ещё и теряется корректно
настроенный интерфейс.

Дополнительно: в ALT Server 10.1 не воспроизводится.

Воспроизводится в P10 в KWorkstation.

etcnet тут вообще не при чём. 
У него есть функция изменения имени сетевого интерфейса, но сетью в рабочей станции рулит NetworkManager.

Сейчас доступно только одно решение - отключить переименование интерфейсов на уровне etcnet и оставить те имена, которые генерятся через systemd.

Для случаев, когда смена имён критична - рисовать правила с другими именами (напзывать интерфейсы собственными именами), которые будут зависеть от MAC адресов сетевых плат.

(Ответ для Anton Farygin на комментарий #23)
> etcnet тут вообще не при чём. 
> У него есть функция изменения имени сетевого интерфейса, но сетью в рабочей
> станции рулит NetworkManager.
> 
> Сейчас доступно только одно решение - отключить переименование интерфейсов
> на уровне etcnet и оставить те имена, которые генерятся через systemd.
> 
> Для случаев, когда смена имён критична - рисовать правила с другими именами
> (напзывать интерфейсы собственными именами), которые будут зависеть от MAC
> адресов сетевых плат.

С собственным именем по MAC та же песня, они тоже бегают динамически. 
Также https://bugzilla.altlinux.org/46048 с собственно именем не маппируются группы, да протестили что все хорошо, но это на чистой зоне имён, мы же уже полноценно работаем с готовыми настройками устоявшимся более 3 лет.

К отключить правила и сделать через systemd можно пожалуйста инструкцию.

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

если отключить правила, то имена как раз будут прыгать - т.е. обязательно нужно правило.
А про mac я не понял - у вас меняются мак-адреса у адаптеров ?

(Ответ для Anton Farygin на комментарий #25)
> если отключить правила, то имена как раз будут прыгать - т.е. обязательно
> нужно правило.
> А про mac я не понял - у вас меняются мак-адреса у адаптеров ?

Про mac.
Я делал переименование интерфейсов согласно правилу в котором используется mac:
su-
udevadm info -a -p /sys/class/net/eth0 | grep address
скопировать ATTR{address}=="X:X:X:X:X:X" в 2 следующие строки 
echo -e 'SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="X:X:X:X:X:X", KERNEL=="eth*", NAME="lan0"' | tee -a /etc/udev/rules.d/79-net-name.rules
echo -e 'SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="X:X:X:X:X:X", KERNEL=="eth*", NAME="lan0"' | tee -a /etc/udev/rules.d/10-network.rules

Ситуация не поменялась, проблема осталась с динамическим хождением.

Для создания ситуации достаточно иметь два eth интерфейса физического вида, никаких правок в настройки работы не производится кроме статики IPv4 настроек для работы с доменным именем.

> Component: etcnet → udev-rule-generator-net

С udev-rule-generator-net всё в порядке, надо просто раскомментировать в /etc/sysconfig/udev-rule-generator строку ETHERDEFAULT=ether. Да и остальное тоже можно раскомментировать, после чего удалить/переименовать /etc/udev/rules.d/70-persistent-net.rules, перезагрузиться и проверить/скорректировать соответствие имён в /etc/net/ifaces, Это для уже установленной системы.

По умолчанию это не сделано вот почему:
https://lists.altlinux.org/pipermail/devel/2020-November/212264.html

(In reply to kessys from comment #26)

> Для создания ситуации достаточно иметь два eth интерфейса физического вида,
> никаких правок в настройки работы не производится кроме статики IPv4
> настроек для работы с доменным именем.

У меня в эксплуатации несколько десятков машин с более, чем двумя ethernet (есть и с десятком). С правилами udev c ETHERDEFAULT=ether ничего никуда не прыгает.

(In reply to Evgeny Shesteperov from comment #22)

> Component: alterator → etcnet

Баг, всё же, должен висеть на том компоненте, который пугается имени, отличного от etherX. Я могу отправить в Сизиф udev-rule-generator-net, где ether будет по умолчанию. Делать?

(In reply to Sergey Y. Afonin from comment #29)

> Баг, всё же, должен висеть на том компоненте, который пугается имени,
> отличного от etherX.

Отличного от ethX то есть.

(Ответ для Sergey Y. Afonin на комментарий #29)
> (In reply to Evgeny Shesteperov from comment #22)
> 
> > Component: alterator → etcnet
> 
> Баг, всё же, должен висеть на том компоненте, который пугается имени,
> отличного от etherX. Я могу отправить в Сизиф udev-rule-generator-net, где
> ether будет по умолчанию. Делать?

Я не против. Вообще udev-rule-generator-net не использую и другим не советую. Везде выкинули, а в kworkstation почему-то нет.

> Вообще udev-rule-generator-net не использую и другим не советую.

Ну не плодить же кучу link-файлов? Правила udev - это удобно.

(Ответ для Sergey Y. Afonin на комментарий #32)
> > Вообще udev-rule-generator-net не использую и другим не советую.
> 
> Ну не плодить же кучу link-файлов? Правила udev - это удобно.

Так, если не мешать udev, то они переименовываются в хитрые названия при помощи 75-net-description.rules, 80-net-setup-link.rules, /lib/systemd/network/99-default.link и не меняются годами.

и это иногда не работает. Редко, правда, случаются рейсы в переименовании.

(In reply to Антон Мидюков from comment #33)

> Так, если не мешать udev, то они переименовываются в хитрые названия при
> помощи 75-net-description.rules, 80-net-setup-link.rules,
> /lib/systemd/network/99-default.link и не меняются годами.

Которые enp*? Они могут меняться при определённых условиях, я уже тут упоминал. Это может быть изменение схемы именования в ядре (https://bugzilla.altlinux.org/28955#c33), либо изменение аппаратной конфигурации (добавление/удаление PCI устройств).

(Ответ для Антон Мидюков на комментарий #31)
> Я не против. Вообще udev-rule-generator-net не использую и другим не
> советую. Везде выкинули, а в kworkstation почему-то нет.
Так-то и я не против. Многим уже неактуально, т.к. пользуются NetworkManager.
Выкидываю?

(Ответ для Sergey V Turchin на комментарий #36)
> (Ответ для Антон Мидюков на комментарий #31)
> > Я не против. Вообще udev-rule-generator-net не использую и другим не
> > советую. Везде выкинули, а в kworkstation почему-то нет.
> Так-то и я не против. Многим уже неактуально, т.к. пользуются NetworkManager.
> Выкидываю?

Можно сгенерировать пакет, я могу потестировать

(Ответ для kessys на комментарий #37)
> Можно сгенерировать пакет, я могу потестировать
Удалите udev-rule-generator-net и тестируйте.

сделал 
apt-get remove udev-rule-generator-net
На машине в домене сделал, перезагрузил пк
Под пользователем вошёл.
Выключил пк вставил wi-fi адаптер
Под пользователя зайти не могу - пишет "не удалось войти в систему"

> Удалите udev-rule-generator-net и тестируйте.

В любом случае это не баг udev-rule-generator-net

(Ответ для Sergey Y. Afonin на комментарий #40)
> это не баг udev-rule-generator-net
Хорошо бы указать, почему.

(In reply to Sergey V Turchin from comment #41)

> Хорошо бы указать, почему.

Я же написал в комментарии 27, что имя задаётся в конфиге, и имя не должно быть ethX. При формировании дистрибутива же можно умолчания конфига менять? Попытка же сделать нормально работающий вариант etherX в 1.1-alt1 привела к проблемам, в друих приложениях (ссылка тут тоже есть, я лично не видел), потму умолчание вернул к ethX в 1.2-alt1.

(Ответ для Sergey Y. Afonin на комментарий #42)
> (In reply to Sergey V Turchin from comment #41)
> 
> > Хорошо бы указать, почему.
> 
> Я же написал в комментарии 27, что имя задаётся в конфиге, и имя не должно
> быть ethX. При формировании дистрибутива же можно умолчания конфига менять?
> Попытка же сделать нормально работающий вариант etherX в 1.1-alt1 привела к
> проблемам, в друих приложениях (ссылка тут тоже есть, я лично не видел),
> потму умолчание вернул к ethX в 1.2-alt1.

Можно. Да, это будет лучше всего сделать в mkimage-profiles. Так не будет рассинхрона, и можно будет сразу проверять эффект.

(Ответ для Sergey Y. Afonin на комментарий #42)
> (In reply to Sergey V Turchin from comment #41)
> 
> > Хорошо бы указать, почему.
> 
> Я же написал в комментарии 27, что имя задаётся в конфиге, и имя не должно
> быть ethX. При формировании дистрибутива же можно умолчания конфига менять?
> Попытка же сделать нормально работающий вариант etherX в 1.1-alt1 привела к
> проблемам, в друих приложениях (ссылка тут тоже есть, я лично не видел),
> потму умолчание вернул к ethX в 1.2-alt1.

У меня udev-rule-generator-net не работает. Собираю img на Сизифе, в который устанавливается udev-rule-generator-net. Строчка ETHERDEFAULT=ether в /etc/sysconfig/udev-rule-generator раскоментируется при сборке.
Запускаю в qemu. Сетевой интерфейс называется eth0. Правило /udev/rules.d/70-persistent-net.rules не создаётся. Что я делаю не так, как заставить работать?

(Ответ для Sergey Y. Afonin на комментарий #42)
> > Хорошо бы указать, почему.
> Я же написал в комментарии 27
Да, я пытаюсь понять, есть ли какая-то польза от невыкидывания udev-rule-generator-net из дистрибутива.

Ок, тогда убираю из Раб.станции К.
https://git.altlinux.org/people/zerg/packages/?p=mkimage-profiles-kworkstation.git;a=commitdiff;h=05aec5fcaf8b57c7c9c5ff1d72d000ae412c96eb

(In reply to Sergey V Turchin from comment #45)
> (Ответ для Sergey Y. Afonin на комментарий #42)

> > Я же написал в комментарии 27

> Да, я пытаюсь понять, есть ли какая-то польза от невыкидывания
> udev-rule-generator-net из дистрибутива.

1. Для случая с одной сетевой картой не важно.

2. Для 2 и более сетевых карт, если ничего больше не делать, проще убрать пакет. Тогда интерфейсы станут иметь вид (на сколько я понимаю) enp* и будут псевдопостоянными, меняясть только при нескольктих условиях (ранее озвучены)

3. Чтобы 2 и более интерфейса имели по настоящему постоянные имена, пакет следует оставить, но базовое имя интерфейса следует сменить с eth на, например, ether в конфиге пакета.

Нет все правильно лучше убрать udev, дабы не иметь проблему с 2 интерфейсами и не заниматься их переименованиями.
Дальше по ходу разберёмся.
Всё спасибо.

(In reply to kessys from comment #47)

> Нет все правильно лучше убрать udev,

Чего убрать!? :-)

> и не заниматься их переименованиями.

Не переименовывать невозможно. Ядро именует интерфейсы как ethX в случайном порядке (иногда это можно решить за счёт драйвера, либо порядка их загрузки, если сетевые карты разные). Дальше только то или иное переименование.

(In reply to Sergey Y. Afonin from comment #48)

> Ядро именует интерфейсы как ethX в случайном порядке

И, до кучи, именно в этом проблема с этими именами: udev зачем-то отучили переименовывать через задействованное имя. Ссылки на эту тему тут уже были.

(Ответ для Sergey Y. Afonin на комментарий #46)
Для меня подходят только п1 и п2, а п3 пользователи заниматься не будут, т.е. исключаю из дистрибутива К.

(Ответ для Sergey Y. Afonin на комментарий #46)
> 1. Для случая с одной сетевой картой не важно.
А он точно не переименовывается?

> > 1. Для случая с одной сетевой картой не важно.
> А он точно не переименовывается?
Всё норм. Просто, не уследил, что у меня при установке генератора нет, а в системе уже есть, поэтому переименовывается.

(In reply to Sergey Y. Afonin from comment #27)

> > Component: etcnet → udev-rule-generator-net
> 
> С udev-rule-generator-net всё в порядке, надо просто раскомментировать в
> /etc/sysconfig/udev-rule-generator строку ETHERDEFAULT=ether.

Начиная с udev-rule-generator-net 1.5-alt1 умолчание снова изменено на ether, но попадёт это уже, вероятно, только в p11.

(Ответ для Sergey Y. Afonin на комментарий #53)
> (In reply to Sergey Y. Afonin from comment #27)
> 
> > > Component: etcnet → udev-rule-generator-net
> > 
> > С udev-rule-generator-net всё в порядке, надо просто раскомментировать в
> > /etc/sysconfig/udev-rule-generator строку ETHERDEFAULT=ether.
> 
> Начиная с udev-rule-generator-net 1.5-alt1 умолчание снова изменено на
> ether, но попадёт это уже, вероятно, только в p11.

А можно запилить в р10?
мне тут переход пока не нужен.
К тому же ещё бетэ RC ждём если не ошибаюсь.

(In reply to kessys from comment #54)

> > Начиная с udev-rule-generator-net 1.5-alt1 умолчание снова изменено на
> > ether, но попадёт это уже, вероятно, только в p11.
> 
> А можно запилить в р10?

А что мешает поменять умолчание в /etc/sysconfig/udev-rule-generator без обновления пакета? Ну и это (хоть обновление пакета, хоть изменение конфига) не повлияет на уже сгенерированный /etc/udev/rules.d/70-persistent-net.rules, если он есть.

(Ответ для Sergey Y. Afonin на комментарий #55)
> (In reply to kessys from comment #54)
> 
> > > Начиная с udev-rule-generator-net 1.5-alt1 умолчание снова изменено на
> > > ether, но попадёт это уже, вероятно, только в p11.
> > 
> > А можно запилить в р10?
> 
> А что мешает поменять умолчание в /etc/sysconfig/udev-rule-generator без
> обновления пакета? Ну и это (хоть обновление пакета, хоть изменение конфига)
> не повлияет на уже сгенерированный
> /etc/udev/rules.d/70-persistent-net.rules, если он есть.
То есть пакет который удалили, вернулся снова?
Делать настройку для настройки на много много пк, по-моему не удобно да и к тому же тащить
это все действие неприятно.
Мне на название всё равно, я его нигде не использую, а вот чтобы ничего не бегало местами важно.

(Ответ для kessys на комментарий #56)
> (Ответ для Sergey Y. Afonin на комментарий #55)
> > (In reply to kessys from comment #54)
> > 
> > > > Начиная с udev-rule-generator-net 1.5-alt1 умолчание снова изменено на
> > > > ether, но попадёт это уже, вероятно, только в p11.
> > > 
> > > А можно запилить в р10?
> > 
> > А что мешает поменять умолчание в /etc/sysconfig/udev-rule-generator без
> > обновления пакета? Ну и это (хоть обновление пакета, хоть изменение конфига)
> > не повлияет на уже сгенерированный
> > /etc/udev/rules.d/70-persistent-net.rules, если он есть.
> То есть пакет который удалили, вернулся снова?
> Делать настройку для настройки на много много пк, по-моему не удобно да и к
> тому же тащить
> это все действие неприятно.
> Мне на название всё равно, я его нигде не использую, а вот чтобы ничего не
> бегало местами важно.

Хотя нет мне на название не всё равно. Сейчас в RC https://forum.altlinux.org/index.php?topic=47666.msg382555#msg382555 уже при установке другое название. но в системе осталось тоже.
Заявку писал вроде сменили но на след RC
И городить 3 названия сетевых интерфейсов в 10.1 10.2 11.0 вроде как точно не прикольно.

(In reply to kessys from comment #56)

> То есть пакет который удалили, вернулся снова?

Вы "дистрибутив" и "репозиторий" различаете?

При установе KWorkstation, как написал в Comment 45 Сергей, пакет ставиться больше не будет. Но если Вы его поставилиm, кто же его у Вас удалит? Из репозитория его никто удалять не собирается пока. И ещё раз напоминаю, пакет разово создаёт файл с привязкой имён. Боьше этот файл сам не меняется ни при каких условиях, кроме как при добавлении/замене сетевой карты.

(Ответ для Sergey Y. Afonin на комментарий #58)
> (In reply to kessys from comment #56)
> 
> > То есть пакет который удалили, вернулся снова?
> 
> Вы "дистрибутив" и "репозиторий" различаете?
> 
> При установе KWorkstation, как написал в Comment 45 Сергей, пакет ставиться
> больше не будет. Но если Вы его поставилиm, кто же его у Вас удалит? Из
> репозитория его никто удалять не собирается пока. И ещё раз напоминаю, пакет
> разово создаёт файл с привязкой имён. Боьше этот файл сам не меняется ни при
> каких условиях, кроме как при добавлении/замене сетевой карты.

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

(In reply to kessys from comment #59)

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

Даже не знаю, что сказать, кроме "тогда страдайте".

Кто Вам мешает в файле /etc/udev/rules.d/70-persistent-net.rules в этих установленных системах поправить имена интерфейсов и сделать соответствующие изменения в настройках etcnet, network manager, или что Вы там используете?