Шаги ==== 1. Установить ALT Server/Workstation/Workstation K с подключённым Ethernet, в установщике оставить настройки сети по умолчанию (DHCP). 2. Обновить систему до актуального p11: # apt-get update && apt-get dist-upgrade -y && update-kernel -y && reboot 3. # ip l 4. # apt-get install -y udev-rule-generator-net 5. # reboot 6. # ip l 7. # reboot 8. # ip l Фактический результат ===================== 3. # ip l 2: enp13s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether <mac> brd ff:ff:ff:ff:ff:ff 3: wlp14s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether <mac> brd ff:ff:ff:ff:ff:ff permaddr <mac> 6. # ip l 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether <mac> brd ff:ff:ff:ff:ff:ff 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether <mac> brd ff:ff:ff:ff:ff:ff permaddr <mac> 8. # ip l 2: ether0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether <mac> brd ff:ff:ff:ff:ff:ff 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether <mac> brd ff:ff:ff:ff:ff:ff permaddr <mac> Ожидаемый результат =================== Название интерфейса должно оставаться eth0. Воспроизводимость ================= Воспроизводится на реальных машинах с сетевыми адаптерами (# inxi -N): [p11] ALT Server 11.0 x86_64 Network: Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet driver: r8169 Device-2: Realtek RTL8852AE 802.11ax PCIe Wireless Network Adapter driver: rtw89_8852ae [p11] ALT Workstation 11.0 x86_64 Network: Device-1: Intel Comet Lake PCH-LP CNVi WiFi driver: iwlwifi Device-2: Intel Ethernet I219-V driver: e1000e [p11] ALT Workstation K 11.0 x86_64 Network: Device-1: Realtek RTL8125 2.5GbE driver: r8169 Device-2: Intel Wi-Fi 6E AX210/AX1675 2x2 [Typhoon Peak] driver: iwlwifi Версия пакета: udev-rule-generator-net-1.6-alt2.noarch В sisyphus не проверялось.
А зачем этот пакет использовать?
Если где-то у нас написано, что этот пакет можно использовать, это срочно надо исправлять.
В Server по умолчанию etcnet, поэтому там ещё и (ожидаемо?) ломаются настройки сети после уже первой перезагрузки после установки этого пакета, поэтому согласен, что он неудобен. Где увидел, уберу. Кое-где ещё на wiki есть: https://www.altlinux.org/index.php?search=%22udev-rule-generator-net%22&title=Служебная%3AПоиск&profile=default&fulltext=1
> Название интерфейса меняется с eth0 на ether0 после повторной перезагрузки Именно так и задумано. А где название вообще eth0? ethN использовать, увы, недопустимо: таков актуальный udev, и уже давно.
(In reply to Антон Мидюков from comment #2) > Если где-то у нас написано, что этот пакет можно использовать, это срочно > надо исправлять. Нет, это не надо исправлять, это единственный адекватный способ назначить имена интерфейсов более, чем одной сетевой карте. Ну не россыпь же link-файлов использовать, которые ещё и не умеют ether. Я пошёл изменения откатывать на wiki.
(Ответ для Sergey Y. Afonin на комментарий #5) > (In reply to Антон Мидюков from comment #2) > > > Если где-то у нас написано, что этот пакет можно использовать, это срочно > > надо исправлять. > > Нет, это не надо исправлять, это единственный адекватный способ назначить > имена интерфейсов более, чем одной сетевой карте. Ну не россыпь же > link-файлов использовать, которые ещё и не умеют ether. Я пошёл изменения > откатывать на wiki. А я удалять из p11 тогда.
> Название интерфейса меняется с eth0 на ether0 В /etc/sysconfig/udev-rule-generator, который принадлежит пакету, есть такой текст: # udev can not rename an ethernet interface if the name is already # occupied. It's a good idea don't to use the "eth" name if you # have more than one network card: https://bugzilla.altlinux.org/32167 # Defailt: ether # # uncomment this if you need default eth # #ETHERDEFAULT=eth В первом сообщении Bug 32167 есть ссылка, которая поясняет, откуда у этого ноги растут.
(In reply to Антон Мидюков from comment #6) > А я удалять из p11 тогда. И делать p11 невозможным в эксплуатации?
Так-то в дистрибутивы тащить никто не заставляет, как и упоминать в официальной документации на docs.altlinux.org. Кроме того, про eth и ether не раз обсуждалось в devel@. Или Вы патч в udev вернули?
(Ответ для Sergey Y. Afonin на комментарий #8) > (In reply to Антон Мидюков from comment #6) > > > А я удалять из p11 тогда. > > И делать p11 невозможным в эксплуатации? 1. Нормально он эксплуатируется без udev-rule-generator-net. 2. На вики безапелляционно заявляется, что нужно ставить udev-rule-generator-net. Не жалеете вы пользователей от сообщества.
> 2. На вики безапелляционно заявляется, что нужно ставить udev-rule-generator-net. Не жалеете вы пользователей от сообщества. Есть проблема в именовании файлов. Я знаю её решение, оно там и описано. Дописать решение с link-файлами не возбраняется, но, во-первых, это тот же самый udev, во-вторых, на мой взгляд, куча файлов менее удобна, чем один. И синтаксис link-файлов не знаю.
(In reply to Sergey Y. Afonin from comment #11) > Есть проблема в именовании файлов. То есть etherne-интерфейсов конечно же. Если сетевых карт более одной и хочется единообразия, а не этого вот enp-бла-бла-бла
Вообще поразительно конечно. На вики оставлено описание проблемы и уброно решение. При этом про link-файлы в решении тоже упоминалось, а не говорилось, что udev-rule-generator-net - единственный путь. Верните решение и разверните вариант про link-файлы.
Позволю ещё напомнить: https://bugzilla.altlinux.org/47234#c4 Кто-нибудь уже сделал пакет, который link-файлы создаёт под шаблон etherN? В p11 есть, чтобы udev-rule-generator-net удалять, или на wiki описать? Или правила руками делать для десятка ethernet-адаптеров, если постоянные имена хочется, которые реально постоянные?
(Ответ для Sergey Y. Afonin на комментарий #14) > Позволю ещё напомнить: https://bugzilla.altlinux.org/47234#c4 > > Кто-нибудь уже сделал пакет, который link-файлы создаёт под шаблон etherN? В > p11 есть, чтобы udev-rule-generator-net удалять, или на wiki описать? Или > правила руками делать для десятка ethernet-адаптеров, если постоянные имена > хочется, которые реально постоянные? /etc/systemd/network/etherN.link [Match] MACAddress=<mac> [Link] Name=etherN
(In reply to Антон Мидюков from comment #15) > /etc/systemd/network/etherN.link > [Match] > MACAddress=<mac> > > [Link] > Name=etherN И что? 10 штук писать руками, вместо того, чтобы один раз генератор правил поставить и поправить номера по порядку? Отличное решение.
(In reply to Sergey Y. Afonin from comment #16) > > /etc/systemd/network/etherN.link > > [Match] > > MACAddress=<mac> > > > > [Link] > > Name=etherN > > И что? 10 штук писать руками, вместо того, чтобы один раз генератор правил > поставить и поправить номера по порядку? Отличное решение. Ещё и сами файлы переименовывать. Кратное увеличение количества операций вместо правки одного единственного 70-persistent-net.rules.
Created attachment 18916 [details] 12 бортовых ethernet Просто для понимания, сколько бывает интерфейсов ethernet иногда. Справа там ещё два слота пустых, PCIe 8x, можно ещё пару четырёхпортовок добавить.
(Ответ для Sergey Y. Afonin на комментарий #18) > Создано вложение 18916 [details] [подробности] > 12 бортовых ethernet То есть 13. 14-ый - IPMI.
А какие имена даёт им udev?
Это с отредактированным persistent-net.rules: # ethlist 0000:b8:00.0 ether0 (i40e) : Link detected: yes Speed: 10000Mb/s Duplex: Full 0000:b8:00.1 ether1 (i40e) : Link detected: yes Speed: 10000Mb/s Duplex: Full 0000:b8:00.2 ether2 (i40e) : Link detected: no Speed: Unknown! Duplex: Unknown! 0000:b8:00.3 ether3 (i40e) : Link detected: no Speed: Unknown! Duplex: Unknown! 0000:06:00.0 ether4 (igb) : Link detected: yes Speed: 100Mb/s Duplex: Full 0000:06:00.1 ether5 (igb) : Link detected: yes Speed: 1000Mb/s Duplex: Full 0000:06:00.2 ether6 (igb) : Link detected: yes Speed: 100Mb/s Duplex: Full 0000:06:00.3 ether7 (igb) : Link detected: yes Speed: 1000Mb/s Duplex: Full 0000:07:00.0 ether8 (igb) : Link detected: yes Speed: 1000Mb/s Duplex: Full 0000:07:00.1 ether9 (igb) : Link detected: yes Speed: 1000Mb/s Duplex: Full 0000:07:00.2 ether10 (igb) : Link detected: yes Speed: 100Mb/s Duplex: Full 0000:07:00.3 ether11 (igb) : Link detected: yes Speed: 100Mb/s Duplex: Full 0000:05:00.0 ether12 (igb) : Link detected: yes Speed: 1000Mb/s Duplex: Full Если без udev-rule-generator-net, будут enp*, какие - сейчас не скажу, сервер в рабоие 24/7. При установке udev-rule-generator-net 10GbE уходят в конец по адресу PCI видимо. Потом правка persistent-net.rules, чтобы порядок на железе был такой, как мне нужно. При этом куча диагностики завязана на однообразие, а не на enp-кто-в-лес-кто-по-рова: <буквы><цифры>.
# ethlist 0000:04:00.0 ether0 (ixgbe) : Link detected: yes Speed: 10000Mb/s Duplex: Full 0000:04:00.1 ether1 (ixgbe) : Link detected: yes Speed: 10000Mb/s Duplex: Full 0000:0a:00.0 ether2 (igb) : Link detected: yes Speed: 1000Mb/s Duplex: Full 0000:0b:00.0 ether3 (igb) : Link detected: yes Speed: 1000Mb/s Duplex: Full 0000:0e:00.0 ether4 (igb) : Link detected: yes Speed: 1000Mb/s Duplex: Full 0000:0e:00.1 ether5 (igb) : Link detected: no Speed: Unknown! Duplex: Unknown! 0000:0e:00.2 ether6 (igb) : Link detected: no Speed: Unknown! Duplex: Unknown! 0000:0e:00.3 ether7 (igb) : Link detected: no Speed: Unknown! Duplex: Unknown! 0000:09:00.1 ether8 (e1000e) : Link detected: yes Speed: 100Mb/s Duplex: Full 0000:09:00.0 ether9 (e1000e) : Link detected: yes Speed: 1000Mb/s Duplex: Full 0000:08:00.1 ether10 (e1000e) : Link detected: yes Speed: 100Mb/s Duplex: Full 0000:08:00.0 ether11 (e1000e) : Link detected: yes Speed: 100Mb/s Duplex: Full Такой вот есть ещё. Этот попроще, тут последние 4 - это 4-хпортовка. Остальные тоже бортовые. А по 4-6 штук обычных ещё штук 20 разных есть. И с четырёхпортовками, и с двухпортовками, и с совсем обычными.
(Ответ для Sergey Y. Afonin на комментарий #4) > > Название интерфейса меняется с eth0 на ether0 после повторной перезагрузки > > Именно так и задумано. А где название вообще eth0? ethN использовать, увы, > недопустимо: таков актуальный udev, и уже давно. Прошу уточнить, является ли корректным то, что после установки пакета udev-rule-generator-net (в зависимости от системы, например на Server, по зависимостям также ставит пакеты udevd-final и udev-rule-generator) и первой перезагрузки меняется: enp13s0 (или другое, зависит от стенда) -> eth0 и только после второй перезагрузки eth0 -> ether0 Если целевым желаемым названием является ether0, то считаю, что оно должно применяться сразу (после только одной перезагрузки); не должно быть промежуточного состояния eth0, которое, как вы говорите, недопустимо. Именно об этом была заведена текущая ошибка.
(In reply to Artem Varaksa from comment #23) > Прошу уточнить, является ли корректным то, что после установки пакета > udev-rule-generator-net (в зависимости от системы, например на Server, по > зависимостям также ставит пакеты udevd-final и udev-rule-generator) и первой > перезагрузки меняется: > > enp13s0 (или другое, зависит от стенда) -> eth0 > > и только после второй перезагрузки > > eth0 -> ether0 Вот это, наверное, нет. > Именно об этом была заведена текущая ошибка. Тогда сорри. По идее должно сразу получаться etherN, и у меня оно так и получается вроде бы. Попробую проверить.
С другой стороны, финал-то ожидаемый, etherN.
(Ответ для Artem Varaksa на комментарий #23) > enp13s0 (или другое, зависит от стенда) -> eth0 > > и только после второй перезагрузки > > eth0 -> ether0 > > Если целевым желаемым названием является ether0, то считаю, что оно должно > применяться сразу Проверил. У меня сразу получается ether, без промежуточного eth. Но система получена из стартера jeos/sysvinit p11, обновлена до Sisyphus. Проверял на копьютере как с одним адаптером, так и с несколькими. udev-rule-generator-net сейчас одинаковый и в Sisyphus, и в p11.
В моём случае, согласно описанию ошибки, проверялось на системах, установленных из образов: * https://ftp.altlinux.org/pub/distributions/ALTLinux/p11/images/workstation/x86_64/alt-workstation-11.0-x86_64.iso * https://ftp.altlinux.org/pub/distributions/ALTLinux/p11/images/kworkstation/alt-kworkstation-11.0-install-x86_64.iso * https://ftp.altlinux.org/pub/distributions/ALTLinux/p11/images/server/x86_64/alt-server-11.0-x86_64.iso обновлённых до p11 (# apt-get update && apt-get dist-upgrade -y && update-kernel -y && reboot).
(Ответ для Artem Varaksa на комментарий #27) > В моём случае, согласно описанию ошибки, проверялось на системах, > установленных из образов: > alt-workstation-11.0-x86_64.iso > alt-kworkstation-11.0-install-x86_64.iso Я не знаю, что в этих системах может работе пакета мешать. И он, в общем-то, не для них придумывался. > alt-server-11.0-x86_64.iso А они все с systemd? Может он мешает, я systemd на серверах пока не использую.
Да, во всех используется systemd.
На днях (правда уже месяца два, как "на днях" :-) ) планирую себе десктопную систему обновлять, придётся на systemd переходить. Посмотрю, что с systemd будет получаться.
Created attachment 18981 [details] Пока доступный стенд Собрал стенд. Как долго будет доступен, не знаю. 00:19.0 Ethernet controller: Intel Corporation 82567LM-2 Gigabit Network Connection 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 04:00.0 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller (Copper) (rev 06) 04:00.1 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller (Copper) (rev 06) 05:00.0 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller (Copper) (rev 06) 05:00.1 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller (Copper) (rev 06) 08:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 08:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 0c:00.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 08)
(Ответ для Антон Мидюков на комментарий #20) > А какие имена даёт им udev? Вот что получается без правил (кто в лес, кто по дрова; отсортировано по pci, как в предыдущем сообщении про стенд): 0000:00:19.0 enp0s25 (e1000e) 0000:01:00.0 enp1s0 (e1000e) 0000:04:00.0 enp4s0f0 (e1000e) 0000:04:00.1 enp4s0f1 (e1000e) 0000:05:00.0 enp5s0f0 (e1000e) 0000:05:00.1 enp5s0f1 (e1000e) 0000:08:00.0 ens3f0 (igb) 0000:08:00.1 ens3f1 (igb) 0000:0c:00.0 ens4 (e100)
(Ответ для Sergey Y. Afonin на комментарий #24) > > Прошу уточнить, является ли корректным то, что после установки пакета > > udev-rule-generator-net (в зависимости от системы, например на Server, по > > зависимостям также ставит пакеты udevd-final и udev-rule-generator) и первой > > перезагрузки меняется: > > > > enp13s0 (или другое, зависит от стенда) -> eth0 > > > > и только после второй перезагрузки > > > > eth0 -> ether0 Вот так выглядит в логе старт: # journalctl -b |grep udev-ru авг 26 09:57:32 3000g-9ad60c udevadm[767]: systemd-udev-settle.service is deprecated. Please fix udev-rule-generator.service, network.service not to pull it in. авг 26 09:57:37 3000g-9ad60c systemd[1]: Starting udev-rule-generator.service - Perform final udevd startup steps... авг 26 09:57:37 3000g-9ad60c systemd[1]: udev-rule-generator.service: Deactivated successfully. авг 26 09:57:37 3000g-9ad60c systemd[1]: Finished udev-rule-generator.service - Perform final udevd startup steps. А вот это появляется в логе после "/etc/rc.d/init.d/udev-rule-generator start" авг 26 10:00:20 3000g-9ad60c udev-rule-generator[1561]: reloading r8169 module for triggering udev succeeded авг 26 10:00:22 3000g-9ad60c udev-rule-generator[1595]: reloading r8169 module for renaming interfaces succeeded Судя по всему, при запуске из-под systemd, стартовый скрипт udev-rule-generator запускается как-то не так и не выполняет переименование. При нормальном запуске этот скрипт проверяет время создания файла 70-persistent-net.rules, и, если файл недавно исправлялся, дополнительно перезагружает модули для того, чтобы udev их переименовал. Почему-то сам udev, когда создаёт правила, сразу переименование не делает.
# chkconfig udev-rule-generator on Внимание: Отправляется запрос 'systemctl enable udev-rule-generator.service'. Synchronizing state of udev-rule-generator.service with SysV service script with /usr/lib/systemd/systemd-sysv-install. Executing: /usr/lib/systemd/systemd-sysv-install enable udev-rule-generator Только вот в /etc/systemd/system/sysinit.target.wants/udev-rule-generator.service присутствует "ExecStart=/etc/rc.d/init.d/udevd-final start", а не udev-rule-generator, хотя и udevd-final тоже нужен.
Примерно понятно.
В Сизифе Tue Aug 26 2025 Sergey Y. Afonin <asy@altlinux> 2:1.6-alt3 - fixed typo in udev-rule-generator.init - moved sysconfig/udev-rule-generator to udev-rule-generator package - fixed udev-rule-generator.service (needs enable; ALT #54998) После установки надо сделать systemctl enable udev-rule-generator.service. И, кстати, попутно возник вопрос: в случае отсутствия etcnet есть ли гарантия того, что NetworkManager запустится после udev? Если кто-нибудь правила переименования хоть через persistent-net.rules, хоть через link-файлы напишет? А то systemd-udevd запускается после network-pre.target
(In reply to Sergey Y. Afonin from comment #36) > В Сизифе > > Tue Aug 26 2025 Sergey Y. Afonin <asy@altlinux> 2:1.6-alt3 > - fixed typo in udev-rule-generator.init > - moved sysconfig/udev-rule-generator to udev-rule-generator package > - fixed udev-rule-generator.service (needs enable; ALT #54998) > > После установки надо сделать systemctl enable udev-rule-generator.service. > > И, кстати, попутно возник вопрос: в случае отсутствия etcnet есть ли > гарантия того, что NetworkManager запустится после udev? Если кто-нибудь > правила переименования хоть через persistent-net.rules, хоть через > link-файлы напишет? А то systemd-udevd запускается после network-pre.target NM сам заботится о том, чтобы начать работать с устройством только после того, как udev издаст add-событие об этом устройстве, см. src/libnm-platform/nm-linux-platform.c. (Исходники у него, конечно, весьма запутанные)
для p11: https://packages.altlinux.org/tasks/393331
(Ответ для Sergey Y. Afonin на комментарий #38) > для p11: https://packages.altlinux.org/tasks/393331 К какому виду в итоге должны прийти названия интерфейсов после добавления таска? Сейчас без таска пакет переименовывает интерфейсы в ethN, с таском либо возвращает ensN, либо ничего не меняет. Проверял на Alt Server 11, Workstation 11, Education 11
Уточнил название ошибки в связи с комментариями. Как я понимаю, ожидается etherN сразу же после 1-й перезагрузки (комментарий #24), но asy@ наверное ответит точнее.
(Ответ для Artem Varaksa на комментарий #40) > Как я понимаю, ожидается etherN сразу же после 1-й перезагрузки Именно так. При условии отсутствия файла /etc/udev/rules.d/70-persistent-net.rules, он создаётся с именами вида etherN, либо в таком виде дописываются вновь добавленные сетевые карты (так оно и было). Сразу же в таком виде всё должно примениться, а вот это не выполнялось, из-за чего желаемое имя устройств получалось только после повторной перезагрузки. С заданием 393331 должно срабатывать сразу, но при условии выполнения "systemctl enable udev-rule-generator.service" после установки пакета. Вот тут не знаю, стоит ли по умолчанию enable делать, или нет.
(Ответ для Sergey Y. Afonin на комментарий #41) > (Ответ для Artem Varaksa на комментарий #40) > > > Как я понимаю, ожидается etherN сразу же после 1-й перезагрузки > > Именно так. При условии отсутствия файла > /etc/udev/rules.d/70-persistent-net.rules, он создаётся с именами вида > etherN, либо в таком виде дописываются вновь добавленные сетевые карты (так > оно и было). Сразу же в таком виде всё должно примениться, а вот это не > выполнялось, из-за чего желаемое имя устройств получалось только после > повторной перезагрузки. С заданием 393331 должно срабатывать сразу, но при > условии выполнения "systemctl enable udev-rule-generator.service" после > установки пакета. Вот тут не знаю, стоит ли по умолчанию enable делать, или > нет. На реальном стенде с несколькими интерфейсами исправление корректно, интерфейсы становятся etherN сразу после первой перезагрузки. На виртуальных машинах (окружение Proxmox) с заданием интерфейсы возвращаются к enpN (что было изначально до установки пакета). Правильно ли я понимаю, что это корректное поведение при наличии # ignore * virtual interfaces в 75-persistent-net-generator.rules ?
(Ответ для Алексей Горячев на комментарий #42) > На виртуальных машинах (окружение Proxmox) с заданием интерфейсы > возвращаются к enpN (что было изначально до установки пакета). Правильно ли > я понимаю, что это корректное поведение при наличии # ignore * virtual > interfaces в 75-persistent-net-generator.rules ? Хороший вопрос. Я так-то этот пакет не с нуля писал, а существующий подхватил, и вариант его существования в виртуалках не рассматривал. Да и плохо представляю, может ли и зачем там быть больше одного интерфейса. Наверное может, но решать этот вопрос надо по мере осознания, если/когда будет понимание.
С версией udev-rule-generator-net-1.6-alt3 ошибка не воспроизводится, промежуточного ethN не возникает после перезагрузки.
* Переоткрываю, т.к. исправление пока не прошло в p11
(Ответ для Антон Мидюков на комментарий #6) > А я удалять из p11 тогда. Внезапно мне подсказали, что он вовсе входит в некоторые дистрибутивы на базе p11: https://packages.altlinux.org/ru/p11/srpms/udev-rule-generator/images/?branch=p11&release=release&task_repo=p11&type=iso И работоспособность пакета нужна, соответственно, не только, внезапно, с systemd, но на виртуалках... Что делать с отладкой на виртуалках пока не знаю.
(Ответ для Sergey Y. Afonin на комментарий #46) > (Ответ для Антон Мидюков на комментарий #6) > > > А я удалять из p11 тогда. > > Внезапно мне подсказали, что он вовсе входит в некоторые дистрибутивы на > базе p11: > https://packages.altlinux.org/ru/p11/srpms/udev-rule-generator/images/ > ?branch=p11&release=release&task_repo=p11&type=iso > > И работоспособность пакета нужна, соответственно, не только, внезапно, с > systemd, но на виртуалках... Что делать с отладкой на виртуалках пока не > знаю. udev-rule-generator-net не входит. udev-rule-generator-cdrom, как я полагаю, не нужен, и его нужно убрать.
(Ответ для Антон Мидюков на комментарий #48) > udev-rule-generator-cdrom, как я полагаю, не нужен, и его нужно убрать. А он, вообще, нужен? Может оставить только самостоятельный udev-rule-generator-net в следующий раз? udev-rule-generator-cdrom сейчас собирается только потому, что был когда-то.
(Ответ для Sergey Y. Afonin на комментарий #49) > (Ответ для Антон Мидюков на комментарий #48) > > > udev-rule-generator-cdrom, как я полагаю, не нужен, и его нужно убрать. > > А он, вообще, нужен? Когда я его добавлял, был нужен. Зачем -- не помню, но если он сломался, то смысла держать больше нет.
(Ответ для Sergey V Turchin на комментарий #50) > > > udev-rule-generator-cdrom, как я полагаю, не нужен, и его нужно убрать. > > > > А он, вообще, нужен? > > Когда я его добавлял, был нужен. Зачем -- не помню, но если он сломался, то > смысла держать больше нет. Сломано взаимодействие udev-rule-generator-net с systemd, а udev-rule-generator-cdrom я в принципе не использовал и не проверял при всех своих манипуляциях с пакетом udev-rule-generator, из котрого они оба получаются. Наверное я их тогда в Sisyphus разделю для начала, оно и по сути, как бы, разное.
(Ответ для Sergey Y. Afonin на комментарий #51) > Наверное я их тогда в Sisyphus разделю для начала Тогда я udev-rule-generator-cdrom пока не выбрасываю.
(Ответ для Sergey V Turchin на комментарий #52) > (Ответ для Sergey Y. Afonin на комментарий #51) > > Наверное я их тогда в Sisyphus разделю для начала > Тогда я udev-rule-generator-cdrom пока не выбрасываю. Предлагаю всё
(Ответ для Sergey V Turchin на комментарий #52) > (Ответ для Sergey Y. Afonin на комментарий #51) > > Наверное я их тогда в Sisyphus разделю для начала > Тогда я udev-rule-generator-cdrom пока не выбрасываю. Предлагаю всё же проанализировать зачем он нужен и не создаёт ли проблем своим наличием.
(Ответ для Антон Мидюков на комментарий #54) > Предлагаю всё же проанализировать зачем он нужен Создаёт /dev/{dvd,dvdrw,cdrw}N, а каким программам это может быть нужно, протестировать сложнее, чем оставить пакет. > и не создаёт ли проблем своим наличием. Я такого не вижу.
(Ответ для Sergey V Turchin на комментарий #55) > (Ответ для Антон Мидюков на комментарий #54) > > Предлагаю всё же проанализировать зачем он нужен > Создаёт /dev/{dvd,dvdrw,cdrw}N, а каким программам это может быть нужно, > протестировать сложнее, чем оставить пакет. > > > и не создаёт ли проблем своим наличием. > Я такого не вижу. Спасибо за пояснения.
