Kterak mě doběhl udev

3.3.2007 23:20 | Přečteno: 2025× | | poslední úprava: 3.3.2007 23:44

Tento příběh je spíše takovým otvírákem pro diskuzi, zda je popisované chování normální a nebo má smysl začít lobovat za jeho změnu.

Sice platí, že člověk, a už vůbec ne admin, nemá spravovat co není rozbité, ale občas se zdá, že nová verze skýtá neodolatelné možnosti a pohodlí. A tak jsem se rozhodl vyrábět nové CF pro naše routery. Šlo to celkem dobře, což je neklamný znak blížící se katastrofy. Ale katastrofám je třeba předcházet a tak jsem CF pro náš nejhůře přístupný router, umístěný na vysokém komíně na který se leze zvenku po žebříku, mnohonásobně otestoval a prověřil.

Celá akce samozřejmě šla tradičně, začalo pršet a fičel ledový vítr. Ale to už je taková zásada, cokoliv se rozbije, rozbije s v místě, kde se k tomu nelze dostat, uprostřed noci a pokud možno při namrzajícím dešti. Samozřejmě nás počasí nezastaví a tak byla CF osazena, router nabootován a NIC. Systém, který bootoval na zemi nejméně 10x úspěšně nenabootoval ani za nic.

Nu vrátili jsme se k osvědčené verzi a já jsem se jal zkoumat, kde jsem udělal chybu. A co myslíte, chybu jsem udělal, když jsem zapomněl na udev.

Ten si zapamatoval MAC adresy ethernetových karet a když startoval v jiném počítači, tak našel "nové" karty a přidělil jim čísla eth2 a eth3, namísto původních eth0 a eth1. To vedlo k tomu, že samozřejmě konfigurace sítě selhala, neměla co konfigurovat. Řešení bylo prosté, smazat /etc/udev/rules.d/z25_persistent-net.rules, a nechat jej na novém stroji založit znovu.

Tak teď když znáte pointu i atmosféru, pochopíte, že udev skoro až nemám rád. Resp. ono ani tak nejde o udev jako takový, ale scripty, které jej obklopují.

Považujete za správné, aby systém nerecykloval jména zařízení, pokud se změní jednoznačná identifikace zařízení? Tedy aby existovaly systémy, které mají jedinou ethernetovou kartu a ta neměla jméno eth0?

       

Komentáře

[DjAARA]

Jo, tak tahle vlastnost udevu mě teď v týdnu 3x vytočila, ale jsou i místa, kde se to může hodit (imho tak nasazení na notebooku s wifi v pcmcia, pci-e card…). V serveru by to prudit nemělo zvlášť v okamžiku, kdy ani jedna ze starých karet v novém systému neexistuje…

[Josef Kufner]

V serveru by to prudit nemělo zvlášť v okamžiku, kdy ani jedna ze starých karet v novém systému neexistuje…

Jenže právě kvůli tomuhle ti v novém serveru nebo po výměně síťovky nenaskočí síť a když k tomu nemáš připojený monitor ani jinou konzoli …

[Josef Kufner]

Na jednom notebooku každou chvíli nefungovala síť. Občas se chytla, občas ne. Občas wifi jakoby zapoměla dělat wifi, občas jo. Žádná pravidelnost, žádné smysluplné chování. A hádej čím to bylo... Jednou byla wifi eth1, firewire eth2 a ethernet eth0. Jindy zas bylo pořadí zcela jiné – hlavně wifi a firewire se prohazovaly.

Takže jaké chování má být to správné? Možná by stačilo, aby bylo zajištěno vždy stejné pořadí, ale to prostě technicky realizovat nejde, protože udev nemá šanci poznat, že tu síťovku tam už nechceš vrátit …

[Dan Ohnesorg]

Jenze potom je spravne nechat na adminovi, aby si ta pravidla sam napsal. A ne generovat je jaksi mimochodem. Zazil jsem motherboard, ktery po studenem startu mel integrovane sitovky v jinem poradi nez po teplem a prave pres pravidla v udev jsem ho umravnil, ale musel jsem ta pravidla napsat, system si je nevybajil sam od sebe.

[Michal Kubeček]

Zazil jsem motherboard, ktery po studenem startu mel integrovane sitovky v jinem poradi nez po teplem a prave pres pravidla v udev jsem ho umravnil

Máte-li jádro 2.6, pak se obecně o pořadí, v jakém jádro detekuje síťové karty, nedá obecně předpokládat vůbec nic.

[wake]

naopak, udev je uzasny. po drobne uprave pravidel mi ted montuje dedicated-backup USB disk pokazde na /mnt/backup, at je 1) pripojeny uz pri bootu nebo 2) at ho pichnu v prubehu uptime. v pripade 2) mi navic jeste automaticky spusti backup. PARADA.

[Shadow]

Inspirován vámi, spíchl jsem udev pravidlo pro spuštění skriptu po připojení SD karty. Takže teď mi stačí vložit kartu do čtečky a fotky se mi automaticky překopírují do příslušných adresářů. Máte pravdu, je to paráda.

[Shadow]

Naštěstí tohle je otázkou nastavení. A jak jsem se díval, v mém Arch Linuxu je tato "báječná" vlastnost (vázání jména síťového rozhraní na MAC adresu) implicitně vypnutá, což se mi jeví jako velmi rozumné. Pokud podobnou funkci vyloženě chci, tak si ji zapnu prostým přejmenováním jediného souboru.

[jyrki]

Linux potkavam asi tak casto jako Windows, jedu na FreeBSD. Nicmene nedavno jsem mel problem s jednim PC s Ubuntu 6.06, v PC prestala fungovat integrovana sitovka - eth0. Pridal jsem tedy novou sitovku - stejny chip Realtek RT8139. Vypis dmesg ukazoval zarizeni eth0 a eth1. Takze ifconfigem nastavuji eth1 a ejhle, zarizeni neexistuje. Nakonec jsem prisel na to ze eth1 v PC neni, ale je tam eth2. Muze za to udev?
Vzpominam si ze v tom PC pred nejakou dobou byla wifi karta....

[Semo]

Taktiez robim mini distribuciu na nahravanie z AD prevodnikov a podobne som asi pred tyzdnom narazil tiez. Jadro pri boote vidi sietovku na eth0 (podla dmesg), ale niekde pocas init scriptov sa pouzije udev a sietovka sa prestahuje na eth1 (je to pritom jedina sietovka v systeme - teda skor v emulatore qemu) a teda nastavene navolenia siete nefunguju. Takze uz pocas instalacie musim generovat pravidla pre udev, aby to nachadzal v rovnakom poradi ako Slax pri instalacii. Pri vsetkych predchadzajucich verziach s tymto problem nebol.

[Dan Ohnesorg]

Tak par dalsich poznatku:

Zda se, ze takto odporne se chova jen Etch a od nej odvozene distribuce. SUSE a Red Hat se chovaji prijatelne, sitove karty nechavaji na pokoji.

Zde zminovany nesoulad mezi dmesg a skutecnymi zarizenimi dela opravdu udev, kernel zarizeni cisluje stale po staru, takze jak nachazi karty tak je cisluje a vypisuje o tom hlasky do konzole, udev potom jmena predelava.

A co je vubec nejhorsi, v Etchi je nekde chyba, kterou hledame, takze se spatne snasi udev s prikazem wlanconfig a tak uz mame zarizeni ath14 a v tom rules souboru jsou MAC adresy duplicine.

Stay tuned.

[Michal Kubeček]

Zda se, ze takto odporne se chova jen Etch a od nej odvozene distribuce. SUSE a Red Hat se chovaji prijatelne, sitove karty nechavaji na pokoji.

Tohle zaslouží trochu upřesnění, tedy aspoň co se SuSE týká. Verze SuSE s jádrem 2.4 (tedy do 9.0) nechávaly síťovým rozhraním skutečně jméno přiřazené jádrem. Protože se ale v jádrech 2.6 detekují zařízení jinak a není zaručeno, že pořadí jejich detekce (a tedy ani "jaderná" jména) bude persistentní; proto první verze s jádrem 2.6 (9.1 - 10.0*) přešly na přiřazení konfigurace ne jménu rozhraní, ale persistentnímu identifikátoru (u ethernetových karet odvozenému z MAC adresy), tj. např. ifcfg-eth-id-00:11:2f:5a:29:3e místo ifcfg-eth0. Pravděpodobně s ohledem na to, že většina ostatních distribucí (tedy aspoň těch, které problém řešily a nenechaly v něm uživatele vykoupat) zvolila řešení s přejmenováním síťových rozhraní pomocí udev, od verze 10.1* používá SuSE kombinovaný model, kdy rozhraní přejmenovává přes udev také na persistentní jména, ale konfiguraci v /etc/sysconfig/network stále přiřazuje persistentnímu identifikátoru jako dříve.

---

* - nejsem si úplně jistý, zda přejmenovávání pomocí udev používala až 10.1 nebo už 10.0

[Dan Ohnesorg]

Jenze to je trochu jiny pripad a jina uroven. Pokud zalozim ifcfg-eth-id.... a nebo do SuSEfirewall2 scriptu vepisu misto jmen karet MAC adresy, tak si zajistim persistenci, ale treba "ip link show" mi bude stale ukazovat eth0 a budu se na nej moct odvolavat. Takze se pri konfiguraci celkem snadno rozhodnu, jak to chci mit. Pravda ne pri konfiguraci pomoci YaSTu.

Jenze v Etchi jsem po precteni vsech scriptu od udev nenasel zadnou promennou, kterou bych dal nekam do /etc/default/udev a toto chovani ovlivnil. Podle me by to melo byt tak, ze pravidla pro udev ma clovek delat aktivne a ne aby vznikala sama od sebe.

[Ondrej 'SanTiago' Zajicek]

Podle me by to melo byt tak, ze pravidla pro udev ma clovek delat aktivne a ne aby vznikala sama od sebe.

Presne tak. udev je docela dobry, kdyz z nej clovek vyhodi vsechna pravidla, ktera tam nastrkala distribuce, a napise si vlastni. V tech defaultnich jsou obcas i zbesile chyby, jako treba MODE="0644" pro /dev/input/eventX.

[xvasek]

RH má v konfiguraci kvůli tomuto přejmenovávání možnost definovat MAC adresu, což by mělo zajistit stálé přiřazení aliasu. Pokud tam MAC není, tak přiřazuje čísla od eth0 dál. To mi přijde asi jako nejlepší možné chování, nicméně jeho přenositelnost značně pokulhává.

Obecně by bylo asi nejlepší jít na to pravou Linuxovou cestou a přidělit tomuto chování konfigurační option - něco jako "persistent network aliases" s volbami all nebo výčtem zařízení. Pak to popsat v manuálu a pak čekat, kdo se na to nachytá a napíše blog o debilní konfigurační option.

[Chipa]

Tak tomu říkám náhoda, zrovna jsem uvažoval, že se zeptám, proč mám v Archu jednou síťovku jako eth0 a wifi eth1 a jindy naopak. Vypadá to, že se budu muset udev mrknout na zoubek, ať čas od času nemusím připojení do ehternetu startovat profilem wireless

[Shadow]

V Arch Linuxu není vázání eth* zařízení na konkrétní MAC adresu implicitně povoleno. Instrukce, jak jej povolit, naleznete v /etc/udev/readme-udev-arch.txt.