9.4. Administrere enheter

9.4.1. Nettverksenheter

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.

9.4.1.2. Opprette tilpassede Udev regler

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

Note

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økler, atskilt med komma og valgfritt mellomrom. Denne regelens nøkler og en forklaring av hver av dem er som følger:

• 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/=.*$/=/'  \
    -i /usr/lib/udev/network/99-default.link \
     > /etc/udev/network/99-default.link

9.4.2. CD-ROM symbolkoblinger

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.

Important

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.

9.4.3. Håndtere dupliserte enheter

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/videoX. Finn ut attributtene som identifiserer enheten unikt (vanligvis fungerer, leverandør- og produkt-IDer og/eller serienumre):

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.