Vlákno názorů k článku Předvídatelné pojmenování síťových karet v Linuxu: kam se podělo eth0 od ByCzech - integrované síťové karty jsou pojmenovány eno0, eno1...
-
- integrované síťové karty jsou pojmenovány eno0, eno1 …
- karty ve slotech PCI Express jsou pojmenovány ens0, ens1 …
- karty s více konektory přidávají k názvům ještě pozici: enp1s0
- (volitelné) název odvozený z MAC adresy: enx78e7d1ea46da
- klasické nepředvídatelné pojmenování podle jádra jako eth0
Síťová karta integrovaná na základní desce mého desktopu s jedním konektorem má název enp4s0 a na notebooku enp8s0 a wifi wlp9s0, co dělám blbě, podle tohoto bych očekával u obou PC eno0 a WiFi u notesu wlo0? Osobně jsem to takto ještě neviděl, podle mě si naopak systemd nepredikovatelně vymýšlí a je v tom větší bordel než předtím. Když jsem potřeboval trvalé pojmenování (např. u serveru s více síťovkami), řešil jsem to utilitou ifrename. Na desktopu a notebooku je v grafických klikátorech pojmenování zbytečné, málokdy je k dispozici více síťovek a když, tak se to dá i v těch klikátorech nastavit na konkrétní (ale dnes již jak vidno stejně nic neříkající název). Za mě další nekompatibilní zbytečnost, která se dostala do systemd.
A co se týká toho názvu s MAC, to je úplná debilita, nedivím se, že je to radši vypnuté. -
VS (neregistrovaný)
Nefunguje to vždy dokonale, ale z větší části je to bordelem v informacích poskytovaných "BIOSem".
Za mě je to ale pro embedded a serverové nasazení jednoznačně plus. Persistence podle MAC adres je peklo při přehazování disků mezi zařízeními, a u moderních systémů k zamíchání pořadí eth0,1,2... bez toho docházelo v nezanedbatelném počtu případů.
I když nefunguje vždy ani to, že k přejmenování nedojde při přidání karty do slotu. Už jsem se setkal s tím, že došlo k přeznačení při vložení nové karty, ale to byl poměrně speciální systém, kde daný slot byl multifunkční, a dané PCIe linky se aktivovaly až při vložení karty do něj, a informace přes biosdevname zřejmě nebyly také úplně OK.
Na stejném HW se vyskytuje název "enp0s31f6" pro jeden z onboard portů - WTF?
-
Adam KaliszStříbrný podporovatelTaky mám takový systém. Jde o desku SuperMicro SAEX11-F, která má dvě Intel síťovky on board, jedna z toho je kombinovaná s IPMI-Ethernetem (který může běžet např. jako tagged nebo se po bootu vypnout)
Potom dvě síťovky, jedna Intel desktop adaptér a druhá Intel 2x GbE Port serverová síťovka. Váš název enp0s31f6 taky vidím. -
Lol Phirae (neregistrovaný)
Síťová karta integrovaná na základní desce mého desktopu s jedním konektorem má název enp4s0 a na notebooku enp8s0 a wifi wlp9s0, co dělám blbě, podle tohoto bych očekával u obou PC eno0 a WiFi u notesu wlo0?
Ještě jsem snad nenarazil na stroj, kde by ten název neobsahoval pXsY (ani u virtuálů)... Asi dělá něco špatně spíš LP. Celé to hodnotím jako úplnou hovadinu a jako řešení (převážně neexistujícího) problému to stejně nefunguje, vůbec to předvídatelné není.
-
Ještě jsem snad nenarazil na stroj, kde by ten název neobsahoval pXsY (ani u virtuálů)...
Tak já už na to pojmenování enoX narazil, ale nebylo zjevné proč to tak někdy je a jindy ne. A zkoumat to zdlouhavě se mi nechce. Kdyby chtělo podívám se do zdrojaků, ale pojmenování je prostě nepredikovatelně a mám stejný názor i na to, že to řeší problém, který neexistuje, bohužel způsobem škrábání se pravou rukou za levým uchem a vytváří problémy jiné, které by bez toho neexistovaly.
-
Ondřej CaletkaZlatý podporovatelTak koukejte, jak to vypadá, když máte server s netriviálním množstvím síťových karet a funkčním firmwarem:
# dmidecode System Information Manufacturer: Dell Inc. Product Name: PowerEdge R430 # ip l 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 18:66:da:88:b4:44 brd ff:ff:ff:ff:ff:ff 3: eno2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 18:66:da:88:b4:45 brd ff:ff:ff:ff:ff:ff 4: enp4s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether a0:36:9f:d8:49:86 brd ff:ff:ff:ff:ff:ff 5: eno3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 18:66:da:88:b4:46 brd ff:ff:ff:ff:ff:ff 6: eno4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 18:66:da:88:b4:47 brd ff:ff:ff:ff:ff:ff 7: enp5s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether a0:36:9f:d7:c3:08 brd ff:ff:ff:ff:ff:ff 8: enp4s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether a0:36:9f:d8:49:87 brd ff:ff:ff:ff:ff:ff 9: enp5s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether a0:36:9f:d7:c3:0a brd ff:ff:ff:ff:ff:ffZejména si povšimněte v jakém pořadí se karty seřadily. Při pojmenování starým způsobem, byly onboard síťovky pojmenované
eth0,eth1,eth3(!) aeth4, první přídavná karta měla portyeth2aeth6a druhá přídavná karta portyeth5aeth7. Tohmuhle uspořádání se nijak slušně říct nedá.Na svém notebooku, kde mám jednu síťovou kartu drátovou a jednu bezdrátovou, je situace samozřejmě úplně jiná; tady mi nové pojmenování nic nepřináší a jen zbytečně znepřehledňuje situaci, takže ho mám vypnuté.
-
DannyStříbrný podporovatelProblem je prave v tom, ze to cele zavisi na (ne)funkcnosti firmware. Na nekterych platformach se to chova predikovatelne, na nekterych ne (a pak lidi nadavaji celkem opravnene). Uz jsem se setkal i s pripadem, kdy snaha o prediktivni pojmenovani rozhrani skoncila neumerne dlouhym bootem... tim, ze se prediktivni pojmenovani - presneji receno prejmenovani - deje az na urovni initrd (podobne, jako funguji persistentni pojmenovani znama z udevu). Na konci byl bordel, kde pulka sitovek mela oznaceni "renameX"... a pak co je lepsi :)
-
Ondřej CaletkaZlatý podporovatel
To, že se to zaseklo a pak ti zbyly síťovky pojmenované jako renameX je právě důkaz toho, že starý systém perzistentního přejmenovávání síťovek podle MAC adres nefungoval vždy dobře a bylo potřeba ho nahradit.
-
DannyStříbrný podporovatel
Naopak, zadratovani do persistent rules udevu to v danem pripade spolehlive vyresilo. Ano, vazba na MAC muze komplikovat treba vymeny sitovych karet - na druhou stranu, jak casto tohle clovek v praxi dela? Uz prave ta vazba na MAC v udevu resila ten problem, ze se sitova rozhrani inicializuji v ruznem poradi v zavislosti na HW i poradi zavedeni ovladacu...
Muzu zminit jiny pripad, kdy mi pridani sitovky do (do te doby volneho) PCIe slotu rozhazelo pojmenovani rozhrani vsech rozhrani... a z enp3s0, ktera se nikam nehnula byla najednou enp5s0. Proste wtf. Vysledkem je, ze nepredelavas jen nastaveni site, ale treba i firewally svazane na rozhrani... Vyvojar tehle veci se vymluvi na spatny firmware a tim to pro nej skonci. Na "chybu toho druheho" se rado svadi vsechno.
Problem noveho systemu je vzdy to, ze jeho autor si mysli, ze problem vyresi - nevyresi, naopak na mnoha mistech zpusobi problemy nove (a to autora novinky obvykle netrapi). Ja jen doufam, ze za rok neprijde nekdo s nejakou dalsi "kreaci", ve ktere bude zase vsechno jinak... protoze jestli neco opravdu prusvih je, tak je to snaha menit fungujici veci a neochota autora resit problemy zmenou zpusobene.
-
Petr M (neregistrovaný)
Problém je, že ať vymyslíš co vymyslíš, vždycky to bude o spolupráci HW a SW. Každý řešení má svoje mouchy a je na tobě, aby sis vybral to míň blbý.
Pokud to svážeš s MAC, můžeš dokonce i prohazovat karty ve slotech, ale při výměně desky za jinou se ti to rozbije. Jak často cvičně v serveru prohazuješ fošny? Normální to je asi jenom ve výrobě síťovek, jinde ne.
Pokud to svážeš s rozhraním, je to konzistentní, ale závisí to na tom, jak nižší vrstva reportuje topologii systému. Hlásí BIOS on-board kartu jako en nebo eo? Hlásí několik portů na jednoportovce? Hlásí existenci nevyužívaných PCI slotů (a přidáním karty na nižší PCIe lane se to rozbije)? Atd. Závislosti na výrobci a jeho vychytávkách se nevyhneš...P.S. koupil jsem si nový auto a ono na D1 drncalo. To je strašný, jak blbý se dneska dělají auta...
-
dustin (neregistrovaný)
====
Pokud to svážeš s MAC, můžeš dokonce i prohazovat karty ve slotech, ale při výměně desky za jinou se ti to rozbije.
====Pro obyč. gigabit stačí použít víceportovou PCI-e Intel za pár desítek dolarů a interní vůbec nepoužívat, jenom na IPMI/ILO. Pak opravdu stačí jen přehodit disky a nastavit bootovací. V pár strojích to pro snadné přehození mám, triviální.
-
dustin (neregistrovaný)
Nevím, z jaké distribuce tento výpis pochází, ale v debianu jsem vždy záznamy těch přeskočených čísel síťovek našel v 70-persistent-net.rules , protože došlo k výměně síťovky a nová měla jinou MAC adresu. Stačilo ze souboru odstranit záznamy pro staré karty a nové přečíslovat tak, jak jsem potřeboval. Po rebootu (či udevadm trigger) byly vždy pojmenované dle mého nastavení.
-
Petr M (neregistrovaný)
Aha, takže ve slotu 1 klekne síťovka. Postup:
1) Vypneš stroj
2) Vytáhneš síťovku
3) Vrazíš tam novou, rozdíl jenom v MAC
4) Zapneš stroj a prohlídneš chyby, upravíš ručně skripty
5) RebootuješPostup, kde se 4) a 5) stanou automaticky je špatně, protože se v /dev u rozhraní liší pár znaků? Zajímavá teorie...
-
dustin (neregistrovaný)
Ano, s tím rozdílem, že bootnu z live distribuce a opravím ten net-persistence záznam na novou MAC adresu. Po ostrém bootu vše OK.
Síťovky vyměňuji výjimečně. Daleko častěji potřebuju přehodit disky do jiného stroje. Některé síťovky použiji z původního, nové přidám do net-persistence před ostrým bootem. Vím naprosto přesně, jak to bude po bootu na novém stroji vypadat.
Samozřejmě mluvím o serverech s více rozhraními, kde se něco řeší.
-
Petr M (neregistrovaný)
Aha. Takže ještě boot na live distro (to máš povoleno v BIOSu, nebo 2x rekonfigurace BIOSu?) s tím, že live distro prostě najde na serveru nějaký síťovky a neřeší, kam který fous vede... A v případě zapomenuté FLASHky s live distrem se ještě pěkně proběhneš. No tys to narovnal jak šilhavej geometr silnici.
-
dustin (neregistrovaný)
Obávám se, žes to nepochopil. To live distro je potřeba jen pro přístup k disku s /etc, MAC adresy samozřejmě znám, nic detekovat nebude. Navíc si to mohu přenastavit ještě před shozením na stávajícím běžícím stroji.
Ty nechodíš do serverovny s otestovaným live linuxem v tašce? Jinak není problém si je kdekoliv na place vyrobit, net je dnes běžně dostupný. Řekl bych, že žádné servery nespravuješ...
-
Trident (neregistrovaný)
Ja kvuli vymene blbe sitove karty teda vetsinou moc serveru neeviduju na vypnuti. Technici to delaji vetsinou za behu. Vyjma nejake entry level masinky kde to je na motherboardu. To se spis bojim toho ktery mamlas na tech x86kach zase delal podporu hotplugu. Ne veskery hw bezny na certifikovanych konfiguracich(vetsinou pokud jsme koupili nejake startupisty...).
-
j (neregistrovaný)
Starym zpusobem se to seradi podle toho v jakym poradi system karty najde, a protoze jsou pripojeny prevazne k pci(e) tak to odpovida logickymu (nikoli nutne fyzickymu) poradi slotu.
A pokud ma system vic integrovanych karet a jsou pripojeny k vice linkam sbernice, tak je kupodivu muze najit i po kartach ve fyzickcyh slotech, jednoduse proto, ze ten slot ma linku s nizsim ID.
V kazdym pripade dokud se nemenila konfigurace HW, tak byla pravdepodobnost ze se ethX prideli jine karte v realnym provozu prakticky nulova. A to pomijim prosty fakt, ze spousta distribuci po prvnim startu automaticky vygenerovala prislusny pravidlo udevu a nazvy zafixovala pomoci MAC.
Kazdopadne to bylo asi tak miliardkat prehlednejsi, a kdyz nic jinyho, tak kazdej vedel, ze sit = ethX. Nektery appky dodnes neumi najit sit, pokud se ethX rozhrani nejmenuje.
-
Petr M (neregistrovaný)
Na jiným místě zase argumentuješ tím, že chceš, aby se po změně pořadí/typu karet nic na označení nezměnilo. Což postaru s /dev/eth* nefunguje ani omylem... Tak co teda chceš?
Jsou tři řešení problému s rozhraníma:
1) Postup postaru podle pořadí hledání:
+ víš, že je to /dev/eth*,
+ nemusíš nic nastavovat,
- změna HW to rozhodí,
- update to potenciálně rozhodí (protože není jednoznačně definován způsob, jak to natahování ovladačů udělat a nová verze jádra se může chovat trochu jinak),
- nemáš rozlišený porty podle karty
2) Postup podle MAC adresy:
+ stejná karta má kdekoliv stejný označení,
+ určíš si sám, pod čím má být v /dev,
- musíš se s tím babrat ručně,
- složitější a delší výměna karty,
- u víc strojů se stejným železem musíš individuálně konfigurovat každý interface (zkus to při instalaci stovky serverů po devíti síťovkách)
3) Postup podle toho, co je v článku
- nezvyklý označení v /dev/ (jenom věc zvyku, na reálnou použitelnost nemá vliv)
- změna konfigurace HW to může změnit
+ nic nemusíš nastavovat
+ na stejným HW máš zaručený stejný jména rozhraní
+ výměna karty se omezí na prostou výměnu železa, netřeba cokoliv konfigurovat
+ protože to jede paralelně, zrychlí se ti boot -
To co popisuje v reálu je jinak, takže hezká teorie, ale neodpovídající realitě. Ale přesně tímhle způsobem jsou prezentovány funkce systemd:
systemd developer: "Funguje to takhle a takhle"user: "Ale mi to rozbíjí to a to"
systemd developer: "Chyba je jinde ne u nás, my to máme dobře"
user: "Ale předtím to fungovalo"
systemd developer: "To jiné, co jsme nekompatibilním chováním rozbili je třeba upravit, aby to fungovalo s naším novým nekompatibilním chováním, takže chyba není u nás"
user: "Ale vy tvrdíte, že to má fungovat tak a tak, ale nefunguje to a proto ten problém, který tvrdíte, že to má řešit, vůbec neřeší"
systemd developer: "To není pravda, nám to funguje správně, to všechno ostatní funguje blbě a je třeba to opravit tam"
:D
Pro tyhle podivíny mám vzkaz: Když se ti zdá, že všichni jedou v protisměru, jsi nejspíš ty sám ten debil, co jede v opačném pruhu!
-
Tak koukejte, jak to vypadá, když máte server s netriviálním množstvím síťových karet a funkčním firmwarem
A kde je eno0? :D Předvídatelně bych první onboard síťovku čekal s indexem 0 nikoli jedna. Stejně jako se to děje u enpXsY, kde je 0 normální hodnota, ale u onboard už to pro změnu neplatí? Myslím, že to vypovídá o tom, jak uvažují vývojáři systemd.
Jinak na jiném takovém serveru to jde i jinak, např. takto:
$ ip l
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: lan4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 50:e5:49:55:2c:4f brd ff:ff:ff:ff:ff:ff
3: lan5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether 00:1f:1f:fa:77:79 brd ff:ff:ff:ff:ff:ff
4: wan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 00:30:4f:29:4f:3f brd ff:ff:ff:ff:ff:ff
5: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 00:08:a1:8b:b9:78 brd ff:ff:ff:ff:ff:ff
6: lan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:1b:21:c5:ed:4b brd ff:ff:ff:ff:ff:ff
7: lan2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:1b:21:c5:ec:2f brd ff:ff:ff:ff:ff:ff
8: lan3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:1b:21:c5:f0:26 brd ff:ff:ff:ff:ff:ff
9: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 3
link/ppp -
Ondřej CaletkaZlatý podporovatel
Jak někdo poznamenal, číslování
enoodpovídá značení na krabici a na krabici jsou porty označeny čísly 1 až 4.Výpis s rozhraními
lanawanje hezký, ale to určitě nevzniklo samo, že ne? Takové nastavení samozřejmě můžete udělat, šlo to i dřív a jde to i teď. Jediné, co se změnilo je, že vývojáři nahradili kód pro udržování pořadí karet, který ne vždy fungoval dobře (a uživatelé si na to oprávněně stěžovali), něčím, co namísto snahy o zachování pořadí nastavuje jména tak, aby byly nastaveny pokaždé stejně. Což je nejen výrazně jednodušší, ale v mém případě i mnohem funkčnější, protože pořadíethrozhraní tak jak je jádro na mém serveru při prvním startu nadetekovalo bylo v zásadě náhodné, bez jakékoli logiky. -
Výpis s rozhraními lan a wan je hezký, ale to určitě nevzniklo samo, že ne? Takové nastavení samozřejmě můžete udělat, šlo to i dřív a jde to i teď
Ne nevzniklo to samo, stejně jako samo nevzniklo nové (ne)předvídatelné pojmenování síťových karet. Nějak ten argument nechápu, co má říct. Věci samy od sebe nevznikají.
Konkrétně na výše zmíněném serveru, ze kterého ten výpis pochází to přežilo několik různých HW obměn/upgradů a také už minimálně třetí generaci Debianu, jen se upgraduje a server jak vidno žije vesele dál. Takže nějak nemůžu souhlasit s prezentovaným problémem - že je původní chování špatně a k ničemu a nové je záchrana světa, proto je třeba to ve výchozím stavu všem pro jejich dobro změnit.
-
Ondřej CaletkaZlatý podporovatel
Dobře tak ještě jinak:
- Pojmenování síťových karet vlastními názvy pomocí udev pravidel fungovalo už minimálně 10 let a funguje nadále. Dokonce je to, aspoň z mého pohledu, preferovaná varianta, protože rozhraní
lan,wanadmzjsou mnohem přehlednější než cokoli jiného. - Pokud nejsou zavedena žádná pravidla, síťové karty dostávají název
eth<číslo>v pořadí, jak jsou detekovány. Pro většinu uživatelů to není problém, protože buď:- mají jen jednu kartu daného typu, nebo
- prodleva mezi detekcí jednotlivých karet je tak velká, že jsou nadetekovány vždy ve stejném pořadí.
- udev dříve obsahoval kód, který se pokoušel zachovávat pomocí vzájemného přejmenovávání pořadí síťových karet tak, jak byly nadetekovány při prvním startu. Tento kód se sám o sobě uplatnil jen pro menšinu uživatelů (těm, pro které neplatí výše zmíněné body), v určité části případů přitom nefungoval správně.
- Vývojáři udevu se rozhodli tento obtížně udržovatelný a debuggovatelný kód zahodit a nahradit něčím, co půjde udržovat snadněji. Pořád ale platí, že většina uživatelů tu službu nepotřebuje, protože nepotřebovala ani tu starou, částečně nefunkční službu.
- Pojmenování síťových karet vlastními názvy pomocí udev pravidel fungovalo už minimálně 10 let a funguje nadále. Dokonce je to, aspoň z mého pohledu, preferovaná varianta, protože rozhraní
-
Vývojáři udevu se rozhodli tento obtížně udržovatelný a debuggovatelný kód zahodit a nahradit něčím, co půjde udržovat snadněji.
Jo takhle, vývojáři to nedělají pro to, aby to co nejlépe fungovalo, ale pro to, aby se to snadno udržovalo. Takové vývojáře poslat k šípku a nabrat ty, pro které je funkčnost a bezproblémovost jejich díla prestiž a ne otrava, vedoucí vlastní leností ke krokům, které jsou pro ně samotné jednoduché, protože to těžké tak přenášejí na chudáky uživatele!
-
DannyStříbrný podporovatel
Takovych prepisu kodu jsme byli svedky uz nekolikrat na mnoha mistech a vzdycky to skonci u toho, ze po case je ten kod opet obtizne udrzovatelny a debugovatelny. Vysledkem je sice kod novy, ktery ale nepokryje do te doby odladene a vychytane detaily, ktere se tam postupne dopisuji... a nakonec mame obtizne udrzovatelny kod. Nekonecny pribeh :-)
Jinak samozrejme "puvodni" rules z udevu se parsuji i nadale (stav s udev 239) - ten kod tam porad je, tzn. ve vysledku neplati ani ta treti velka odrazka (jinymi slovy jde mit "eth0" i na systemu, kde kernelu "net.ifnames=0" neposilas)...
-
null null (neregistrovaný)
@Danny
IMO pokud se každý refactoring nakonec opět stane některým z kruhů pekla, tak z mé zkušenosti bývá chyba v architektuře - jako např. na danou komponentu se klade příliš mnoho nároků a je potřeba to oddělit nebo změnit, případně revidovat možné stavy a kombinace se kterými pracuje a pod., nějaká kombinace faktorů ... ale mnohokrát jsem došel k tomu, že se takové problémy vyřeší až větší změnou než je pouhá implementace komponenty.
No je mi jasné co to obnáší, ale .... -
j (neregistrovaný)
"Vývojáři udevu se rozhodli tento obtížně udržovatelný a debuggovatelný kód zahodit a nahradit něčím, co půjde udržovat snadněji."
Snadneji pro koho? Pro toho idiota poetteringa a jeho squadru? Protoze VSEM ostatnim to prineslo jen neustale dokola se objevujici problemy a naprosto nulovy uzitek.
-
DannyStříbrný podporovatel
Vypis s rozhranimi "lan" samozrejme "sam" vzniknout muze... U rozhrani, ktere se do systemu propisou z distribuovanyho switche (DSA) je to naprosto bezne k videni :-)
Jinak zadny system nefunguje dobre. Jisteze mohly byt teoreticke problemy s persistent-net-rules u udevu, ale obvykle to fungovalo bez potizi a poradi (a tedy pojmenovani) karet se od instalace nikdy nezmenilo (a pripadne zmenit poradi take nebylo tezke). S prediktivnimi jmeny to je zdanlive vyresene - teoreticky, jen na papire, praxe ukazuje, ze i s tim jsou (jine) problemy a vyresene to (opet) spolehlive neni. Dilem diky tomu, ze fakticky nejde o vychozi pojmenovani, ale uz jen prejmenovani behem bootu (ktere ne vzdy dobehne, jak by melo), dilem diky tomu, ze se ruzne firmware chovaji ruzne - viz problemy treba se zmenou/preskladanim cisel bus i pri vlozeni noveho hardware do prazdneho slotu... to, ze onboard sitovky mnohych desek vubec nejsou rozpoznane jako onboard je uz jen tresnicka na dortu (mam treba desktop, kde onboard sitovka je bus 3, a pcie karty bus 1,5 - logika zadna).
Samozrejme se muzes stale dokola vymlouvat na vyvojare firmwaru a jejich chyby - ale ten problem tu proste bude, protoze ani zadny firmware neni a nikdy nebude bez chyb. Zrovna linuxovy kernel je plny ruznych quirku, kterymi se vselimozne chyby ve firmware obchazi - aby hardware vubec fungoval. A je jich tam fakt spousta. Spolehat plne na firmware zrovna pri pojmenovani sitovych rozhrani s odkazem na tuto letitou zkusenost neni zrovna stastne, nemyslis?
Navic, kdyz vezmes celou teoreticky moznou delku nazvu pro PCI device ([P<domain>]p<bus>s<slot>[f<function>]n<phys_port_name>) nebo i USB device ([P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]), tak je pomerne neprehledne, stejne jako mozny tvar odvozeny z MAC (x<MAC>- to je take ve specifikaci)... tak to v konecnem dusledku zrovna prehledne neni a nejspis i bude zdrojem sedivych vlasu v dusledku ruznych preklepu.
-
Lol Phirae (neregistrovaný)
Paradoxně, ta metoda pojmenování podle MAC adresy (
enx<mac_addr>), které je z pohledu predikovatelnosti a možného rozjebání při změnách (jiného) hardwaru zdaleka nejméně problémová, je defaultně vypnutá. Smyslu půl to nedává, jako ostatně mraky dalších věcí v Poetteringlandu. :-X
