Udev, som standard, navngir nettverksenheter i henhold til fastvare/BIOS data eller fysiske egenskaper som buss, spor eller MAC-adresse. Formålet med denne navnekonvensjonen er å sikre at nettverksenheter er navngitt konsekvent og ikke basert på tiden nettverkskortet var oppdaget. I eldre versjoner av Linux—på en datamaskin med to nettverkskort laget av Intel og Realtek, for eksempel— nettverkskort produsert av Intel kan ha blitt eth0 mens Realtek-kortet ble eth1. Etter en omstart, er kortene noen ganger nummerert omvendt.
I det nye navneskjemaet vil typiske nettverksenhetsnavn være noe sånt som enp5s0 eller wlp3s0. Hvis denne navnekonvensjonen ikke er ønsket, kan det tradisjonelle navneskjemaet eller et tilpasset oppsett være implementert.
Det tradisjonelle navneskjemaet som bruker eth0, eth1, osv. kan
bli gjenopprettet ved å legge til net.ifnames=0
på kjernens
kommandolinje. Dette er mest passende for systemene som bare har
en Ethernet-enhet av samme type. Bærbare datamaskiner har ofte
flere ethernet-tilkoblinger som heter eth0 og wlan0 og er også
kandidater for denne metoden. Kommandolinjen sendes i
GRUB-konfigurasjonsfilen. Se Section 10.4.4,
“Opprette GRUB konfigurasjonsfilen”
Navneskjemaet kan tilpasses ved å lage tilpassete udev regler. Et skript er inkludert som genererer de første reglene. Generer disse reglene ved å kjøre:
bash /usr/lib/udev/init-net-rules.sh
Nå, inspiser /etc/udev/rules.d/70-persistent-net.rules
filen, for å finne ut hvilket navn som ble tildelt hvilken
nettverksenhet:
cat /etc/udev/rules.d/70-persistent-net.rules
I noen tilfeller som når MAC-adresser har blitt tildelt et nettverkskort manuelt eller i et virtuelt miljø som Qemu eller Xen, blir kanskje ikke nettverksregelfilen generert fordi adresser ikke er konsekvent tildelt. I disse tilfellene kan denne metoden ikke bli brukes.
Filen begynner med en kommentarblokk etterfulgt av to linjer for hver NIC. Den første linjen for hvert NIC er en kommentert beskrivelse som viser dens maskinvare-IDer (f.eks. PCI leverandøren og enhets IDene, hvis det er et PCI-kort), sammen med driveren i parentes, hvis driveren kan bli funnet. Ingen maskinvare-IDer eller drivere brukes til å bestemme hvilket navn som skal gis grensesnittet; denne informasjonen er kun for referanse. Den andre linjen er udev regelen som samsvarer med dens NIC og faktisk tildeler det et navn.
Alle udev regler består av flere nøkkelord, atskilt med komma og valgfritt mellomrom. Her er nøkkelordene, og en forklaring på hvert enkelt:
SUBSYSTEM=="net"
- Dette
forteller udev å ignorere enheter som ikke er
nettverkskort.
ACTION=="add"
- Dette
forteller udev å ignorere denne regelen for en hendelse som
ikke er en add ("remove" og "change" hendelser , men
trenger ikke å endre navn på nettverksgrensesnittene).
DRIVERS=="?*"
- Dette
eksisterer slik at udev vil ignorer VLAN- eller et bro
undergrensesnitt (fordi disse undergrensesnittene ikke har
drivere). Disse undergrensesnittene hoppes over på grunn av
navnet som ville bli tildelt ville kollidere med deres
overordnede enheter.
ATTR{address}
- Verdien av
denne nøkkelen er NIC sin MAC adresse.
ATTR{type}=="1"
- Dette sikrer
at regelen kun samsvarer med det primære grensesnittet for
enkelte trådløse drivere som skaper flere virtuelle
grensesnitt. De sekundære grensesnittene er hoppet over av
samme grunn som VLAN og bro undergrensesnitt er hoppet
over: ellers ville det vært en navnekollisjon.
NAME
- Verdien av denne
nøkkelen er navnet som udev vil tilordne til dette
grensesnittet.
Verdien av NAME
er den viktige
delen. Forsikre deg om at du vet hvilket navn som har blitt
tildelt hvert av nettverkskortene dine før du fortsetter, og sørg
for å bruke NAME
verdien når du
opprette konfigurasjonsfilene nedenfor.
Selv om den tilpassede UDEV regelfilen er opprettet, kan UDEV
fortsatt tilordne ett eller flere alternative navn for en annen
NIC basert på fysisk kjennetegn. Hvis en tilpasset UDEV regel
ville gi nytt navn til en annen NIC ved hjelp av et navn som
allerede er tildelt som et alternativt navn på en annen NIC,
denne UDEV regelen vil mislykkes. Hvis dette problemet skjer, kan
du opprette /etc/udev/network/99-default.link
konfigurasjonsfil med en tom alternativ tildelingspolitikk, og
overstyrer standard konfigurasjonsfil /usr/lib/udev/network/99-default.link
:
sed -e '/^AlternativeNamesPolicy/s/=.*$/=/' \ /usr/lib/udev/network/99-default.link \ > /etc/udev/network/99-default.link
Noe programvare som du kanskje vil installere senere (f.eks.
diverse mediespillere) forventer at /dev/cdrom
og /dev/dvd
symbolkoblinger eksisterer, og å peke på
en CD-ROM- eller DVD-ROM-enhet. Dessuten kan det være praktisk å
sette referanser til disse symbolkoblingene i /etc/fstab
. Udev kommer med et skript som vil
generere regelfiler for å lage disse symbolkoblingene for deg,
avhengig av egenskapene til hver enhet, men du må bestemme hvilken
av to operasjonsmoduser du ønsker at skriptet skal bruke.
For det første kan skriptet operere i “by-path” modus (brukes som standard for USB- og FireWire-enheter), der reglene den oppretter avhenger av den fysiske banen til CD- eller DVD-enheten. For det andre kan den operere i “by-id” modus (standard for IDE- og SCSI-enheter), de reglene den oppretter avhenger av identifikasjonsstrenger som er lagret på selve CD eller DVD enheten. Banen bestemmes av udev sitt path_id skript, og identifikasjonsstrengene leses fra maskinvaren av ata_id eller scsi_id programmene, avhengig av hvilken type enhet du har.
Det er fordeler med hver tilnærming; riktig tilnærming til bruk vil avhenge av hva slags enhetsendringer som kan skje. Hvis du forventer at fysisk vei til enheten (det vil si portene og/eller sporene som den kobler til ) endres, for eksempel fordi du planlegger å flytte stasjonen til en annen IDE-port eller en annen USB-kontakt, så bør du bruke “by-id”modus. På den annen side, hvis du forventer at enhetens identifikasjon endres, for eksempel fordi det kan dø, og du vil erstatte den med en annen enhet med de samme egenskapene og som er koblet til de samme kontaktene, bør du bruke “by-path” modus.
Hvis begge endringene er mulig med stasjonen din, velg en modus basert på typen endring du forventer skal skje oftest.
Eksterne enheter (for eksempel en USB-tilkoblet CD-stasjon) bør ikke vedvarende bruke by-path, fordi hver gang enheten kobles til en ny ekstern port, vil dens fysiske bane endres. Alle eksternt tilkoblede enheter vil ha dette problemet hvis du skriver udev-regler som gjenkjenner dem på deres fysiske sti; problemet er ikke begrenset til CD og DVD-stasjoner.
Hvis du ønsker å se verdiene som udev-skriptene vil bruke, for den
aktuelle CD-ROM-enheten, finn den tilsvarende mappen under
/sys
(f.eks. kan dette være
/sys/block/hdd
) og kjør en kommando
som ligner på følgende:
udevadm test /sys/block/hdd
Se på linjene som inneholder utdata fra forskjellige *_id programmer. “by-id” modus vil bruke ID_SERIAL verdien hvis den finnes og ikke er tom, ellers vil den bruke en kombinasjon av ID_MODEL og ID_REVISJON. “by-path” modus vil bruke ID_PATH verdien.
Hvis standardmodusen ikke passer for din situasjon, så kan følgende
modifikasjoner gjøres på /etc/udev/rules.d/83-cdrom-symlinks.rules
filen,
som følgende (hvor mode
er en av “by-id” eller “by-path”):
sed -e 's/"write_cd_rules"/"write_cd_rules mode
"/' \
-i /etc/udev/rules.d/83-cdrom-symlinks.rules
Merk at det ikke er nødvendig å lage regelfilene eller
symbolkoblingene på dette tidspunktet fordi du har bind-montert
vertens /dev
mappe inn i LFS systemet
og vi antar at symbolkoblingene finnes på verten. Reglene og
symbolkoblingene vil opprettes første gang du starter opp LFS
systemet.
Men hvis du har flere CD-ROM-enheter, kan symbolkoblingene generert
på det tidspunktet peke på andre enheter enn de peker på hos verten
din fordi enheter ikke oppdages i en forutsigbar rekkefølge. Den
første tildelingen opprettet når du starter opp LFS systemet vil
være stabile, så dette er bare et problem hvis du trenger
symbolkoblingene på begge systemene til å peke på samme enhet. Hvis
du trenger det, inspiser (og muligens rediger) den genererte
/etc/udev/rules.d/70-persistent-cd.rules
filen
etter oppstart, for å sikre at de tilordnede symbolkoblingene
samsvarer med det du trenger.
Som forklart i Section 9.3,
“Oversikt over enhets- og modulhåndtering” rekkefølgen som
hvilke enheter med samme funksjon vises i /dev
er i hovedsak tilfeldig. Hvis du for
eksempel har et USB-webkamera og en TV-tuner, noen ganger
/dev/video0
refererer til kameraet og
/dev/video1
refererer til tuneren, og
noen ganger etter en omstart endres rekkefølgen. For alle klasser
av maskinvare unntatt lydkort og nettverkskort kan dette fikses ved
å lage udev-regler for egendefinerte vedvarende symbolkoblinger.
Tilfellet med nettverkskort dekkes separat i Section 9.5,
“Generell nettverkskonfigurasjon” og lydkortkonfigurasjon kan
finnes i
BLFS.
For hver av enhetene dine som sannsynligvis vil ha dette problemet
(selv om problemet ikke eksisterer i din nåvørende Linux
distribusjon), finn den tilhørende mappen under /sys/class
eller /sys/block
. For videoenheter kan dette være
/sys/class/video4linux/video
. Finn ut attributtene som
identifiserer enheten unikt (vanligvis fungerer, leverandør- og
produkt-IDer og/eller serienumre):
X
udevadm info -a -p /sys/class/video4linux/video0
Skriv så regler som lager symbolkoblingene, f.eks.:
cat > /etc/udev/rules.d/83-duplicate_devs.rules << "EOF"
# Persistent symlinks for webcam and tuner
KERNEL=="video*", ATTRS{idProduct}=="1910", ATTRS{idVendor}=="0d81", SYMLINK+="webcam"
KERNEL=="video*", ATTRS{device}=="0x036f", ATTRS{vendor}=="0x109e", SYMLINK+="tvtuner"
EOF
Resultatet er at /dev/video0
og
/dev/video1
enheter refererer
fortsatt tilfeldig til tuneren og webkameraet (og bør derfor aldri
brukes direkte), men det finnes symbolkoblinger /dev/tvtuner
og /dev/webcam
som alltid peker på den rette
enheten.