Dotaz: problém s eth po updatu kernelu

[Standa]

Ahoj, mám Centos 5.5, síťovky r8139 a r8168 a pokaždé, když updatuji kernel, tak se mi po restartu navzájem zamění eth0 za eth1, takže musím přehodit utp kabely. Pokud provedu ještě jeden restart, tak už jsou eth správně. V modprobe.conf mám alias eth1 r8168, ifconfig ukazuje vše správně, ale dmesg vypisuje r8168: eth0: link up. Ovladač pro r8168 se přes DKMS po každém updatu kernelu kompiluje. Nevíte prosím, jak a kde nastavit, aby se pokaždé driver nekompiloval pro novou verzi? Díky za odpovědi. Standa

Odpovědi

[jozinzbazin]

nevim jak v centosu, ale ve Fedore mame nasledujici soubor, ktery se stara o zachovani jmen. Myslim ze nepotrebuje dalsi komentar

$ cat /etc/udev/rules.d/70-persistent-net.rules

# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rule written by anaconda)
# Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rule written by anaconda)

# PCI device 0x10ec:0x8168 (r8169) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:26:18:9a:9a:01", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x168c:0x002b (ath9k) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:d3:62:f9:81", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

[Filip Jirsák]

Někdy je potřeba tenhle soubor trochu upravit, aby se třeba neřídil MAC adresou, ale něčím jiným. Nedávno jsem řešil, proč dostane síťová karta po každém restartu o jedno číslo vyšší eth, když se udev používá a karta je v tomto skriptu zapsaná, až jsem pak zjistil, že ta síťová karta integrovaná na základní desce má pokaždé jinou MAC adresu.

[frr]

To je neuvěřitelné, co někteří výrobci nablejou do BIOSu... už jsem viděl motherboardy, kde byla konfigurační EEPROM u síťovek prázdná, a potažmo MAC adresa samé nuly... ale generovat MAC adresu při bootu náhodně? No to je maso. Co by pokoutní garážový lepič PC hardwaru neudělal proto, aby se vyhnul košer vypálení unikátní MAC adresy do každého motherboardu. Povšimněte si, že se vyhýbám tomu, abych si vzal nevyváženě a politicky nekorektně do úst konkrétní národnost nebo geografickou oblast.

[2X4B-523P]

to je příprava na IPv6

[Filip Jirsák]

Naprogramovat to chování muselo být dokonce těžší, než kdyby ta adresa byla někde uložená. Ona ta MAC adresa totiž nebyla úplně náhodná. Měla vždy stejný začátek – pravděpodobně vendor prefix, ale když jsem to zjistil, neměl jsem vůbec náladu na to zjišťovat délku vendor prefixu MAC adresy, ale spíš něco provést tomu, kdo tohle spáchal. Docela by mne zajímalo, jak má tohle fungovat s DHCP nebo portem na switchi zamknutým pro konkrétní MAC adresu.

[frr]

Právě že dopsat do BIOSu, aby nacpal do síťovky 3B vendor prefix + 3B náhodná data je z hlediska masové výroby jednodušší, než na každém vyrobeném kusu bootnout speciální dávku, která flashne adresu in circuit a někde na serveru přičte jedničku, nebo totéž přes JTAG, nebo zařídit, aby osazovací stroj sázel na plošák EEPROMky "předflashnuté" unikátním obsahem... obvykle používané MicroWire EEPROM (93C46 apod.) samy o sobě nejsou flashovatelné in circuit (na rozdíl od 24C01 na I2C).

Docela by mě zajímalo, jestli výrobci motherboardů v rámci QC vůbec vloží CPU+RAM, připojí kabely a motherboard bootnou, nebo jenom připojí JTAG a nějakou jehlovou sondu a oměří, co se dá, aniž by připojili jediný vnější kabel. Pokud ta deska u výrobce ani jednou nenabootuje, tak se nedivím, že je pro výrobce problém flashovat unikátní MAC adresy. Pravděpodobně je to celé nakonec jenom otázka peněz = vědomá úspora nákladů.

[dustin]

Jo, to zní jako velice pravděpodobný důvod.