7.4. Administrere enheter

7.4.1. Nettverksenheter

Udev navngir som standard nettverksenheter i henhold til Fastvare/BIOS data eller fysiske egenskaper som buss, spor eller MAC-adresse. Formålet med denne navngivningskonvensjonen er å sikre at nettverksenheter navngis konsekvent og ikke basert på tidspunktet nettverkskortet ble oppdaget. For eksempel på en datamaskin som har to nettverkskort laget av Intel og Realtek, kan nettverkskortet produsert av Intel bli eth0 og Realtek kortet blir eth1. I noen tilfeller blir kortene omnummerert etter omstart.

I det nye navneskemaet vil typiske nettverksenhetsnavn være noe som enp5s0 eller wlp3s0. Hvis denne navngivningskonvensjonen ikke er ønsket, kan den tradisjonelle navneskjemaet eller en tilpasset ordning implementeres.

7.4.1.1. Deaktivering av vedvarende navngivning på kjernekommandolinjen

Det tradisjonelle navneskjemaet som bruker eth0, eth1, etc kan gjenopprettes ved å legge til net.ifnames=0 på kjernekommandolinjen. Dette er mest hensiktsmessig for de 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 avsnitt 8.4.4, “Opprette GRUB konfigurasjonsfilen”.

7.4.1.2. Opprette tilpassede Udev regler

Navneskjemaet kan tilpasses ved å lage tilpassede Udev regler. Et skript er inkludert som genererer de innledende reglene. Generer disse reglene ved å kjøre:

bash /lib/udev/init-net-rules.sh

Inspiser nå filen /etc/udev/rules.d/70-persistent-net.rules for å finne ut hvilket navn som ble tildelt hvilken nettverksenhet:

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

I noen tilfeller, for eksempel når MAC adresser har blitt tildelt et nettverkskort manuelt eller i et virtuelt miljø som Qemu eller Xen, kan det hende at nettverksregelfilen ikke har blitt generert fordi adressene ikke blir tildelt konsekvent. I disse tilfellene kan denne metoden ikke brukes.

Filen begynner med en kommentarblokk etterfulgt av to linjer for hver nettverkskort. Den første linjen for hvert nettverkskort er en kommentert beskrivelse som viser maskinvare-IDene (f.eks. PCI leverandøren og enhets-IDene, hvis det er et PCI-kort), sammen med driveren i parentes, hvis driveren kan bli funnet. Verken maskinvare-ID eller driveren brukes til å bestemme hvilket navn et grensesnitt skal få; denne informasjonen er kun for referanse. Den andre linjen er Udev regelen som samsvarer med dette nettverkskortet og faktisk tildeler det et navn.

Alle Udev regler består av flere nøkler, atskilt med komma og valgfri mellomrom. Denne regelens nøkler og en forklaring på 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 begivenhet som ikke er en tilføyelse ("fjern" og "endre" hendelser skjer også, men trenger ikke å gi nytt navn til nettverksgrensesnitt).
  • DRIVERS == "?*" - Dette eksisterer slik at Udev vil ignorere VLAN eller bridge subgrensesnitt (fordi disse subgrensesnittene ikke har drivere). Disse undergrensesnittene hoppes over fordi navnet som tildeles vil kollidere med deres foreldreenheter.
  • ATTR {adresse} - Verdien til denne nøkkelen er NICs MAC adresse.
  • ATTR {type}=="1" - Dette sikrer at regelen bare samsvarer med det primære grensesnittet når det gjelder visse trådløse drivere, som lager flere virtuelle grensesnitt. De sekundære grensesnittene hoppes over av samme grunn som VLAN og bridge undergrensesnittene hoppes over: det ville være en navnekollisjon ellers.
  • NAME - Verdien til denne nøkkelen er navnet som Udev vil tildele dette grensesnittet.

Verdien av NAME er den viktige delen. Forsikre deg om at du vet hvilket navn som er tildelt hvert av nettverkskortene dine før du fortsetter, og sørg for å bruke den NAME verdien når du oppretter konfigurasjonsfilene nedenfor.

7.4.2. CD-ROM symlinker

Noe programvare som du kanskje vil installere senere (f.eks. Forskjellige mediaspillere) forventer at /dev/cdrom og /dev/dvd symlinker eksisterer, og at de peker på en CD-ROM eller DVD-ROM enhet. Det kan også være praktisk å sette referanser til disse symlinkene i /etc/fstab. Udev kommer med et skript som genererer reglerfiler for å lage disse symlinkene for deg, avhengig av funksjonene til hver enhet, men du må bestemme hvilken av de to driftsmåtene du vil at skriptet skal bruke.

For det første kan skriptet fungere i "by-path" modus (brukes som standard for USB og FireWire enheter), hvor reglene det oppretter avhenger av den fysiske banen til CD eller DVD enheten. For det andre kan den fungere i “by-id” modus (standard for IDE og SCSI enheter), der reglene den lager, avhenger av identifikasjonsstrenger som er lagret i selve CD eller DVD enheten. Banen bestemmes av Udevs path_id skript, og identifikasjonsstrengene leses fra maskinvaren av programmene ata_id eller scsi_id, avhengig av hvilken type enhet du har.

Det er fordeler med hver tilnærming; riktig tilnærming vil avhenge av hva slags enhetsendringer som kan skje. Hvis du forventer at den fysiske banen til enheten (det vil si portene og/eller sporene den kobles til) endres, for eksempel fordi du planlegger å flytte stasjonen til en annen IDE port eller en annen USB kontakt, bør du bruk “by-id” -modus. På den annen side, hvis du forventer at enhetens identifikasjon endres, for eksempel fordi den kan dø, og du vil erstatte den med en annen enhet med samme funksjoner og som er koblet til de samme kontaktene, bør du bruke “by-path” modus.

Hvis begge typene er mulig med stasjonen din, velger du en modus basert på hvilken type endring du forventer å skje oftest.

Eksterne enheter (for eksempel en USB tilkoblet CD stasjon) bør ikke bruke by-path, fordi hver gang enheten kobles til en ny ekstern port, vil den fysiske banen endres. Alle eksterne tilkoblede enheter vil ha dette problemet hvis du skriver Udev regler for å gjenkjenne dem ved deres fysiske bane; problemet er ikke begrenset til CD og DVD stasjoner.

Hvis du ønsker å se verdiene som Udev skriptene vil bruke, finn den tilsvarende katalogen under /sys for den aktuelle CD-ROM enheten (f.eks. Dette kan 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 eksisterer og ikke er tom, ellers vil den bruke en kombinasjon av ID_MODEL og ID_REVISION. “by-path” modus vil bruke ID_PATH verdien.

Hvis standardmodus ikke er egnet for din situasjon, kan følgende modifisering gjøres i /etc/udev/rules.d/83-cdrom-symlinks.rules filen, som følger (der modus er en av "by-id ” eller“ by-path ”):

sed -i -e 's/"write_cd_rules"/"write_cd_rules mode"/' \
      /etc/udev/rules.d/83-cdrom-symlinks.rules

Merk at det ikke er nødvendig å opprette reglefilene eller symlinkene på dette tidspunktet, fordi du har bindemontert vertens /dev katalog i LFS systemet, og vi antar at symlinkene eksisterer på verten. Reglene og symlinkene blir opprettet første gang du starter LFS-systemet ditt.

Men hvis du har flere CD-ROM-enheter, kan symlinkene som genereres på det tidspunktet, peke på forskjellige enheter enn de peker på verten din, fordi enheter ikke blir oppdaget i en forutsigbar rekkefølge. Tilordningene som ble opprettet når du først startet LFS systemet, vil være stabile, så dette er bare et problem hvis du trenger symlinkene på begge systemene å peke på samme enhet. Hvis du trenger det, inspisere (og eventuelt rediger) den genererte /etc/udev/rules.d/70-persistent-cd.rules filen etter oppstart, for å sikre at de tildelte symlinkene samsvarer med det du trenger.

7.4.3. Håndterer dupliserte enheter

Som forklart i kapittel 7.3, “Oversikt over enhets og modulhåndtering”, er rekkefølgen enheter med samme funksjon vises i /dev, i det vesentlige tilfeldig. Hvis du for eksempel har et USB webkamera og en TV-tuner, refererer noen ganger /dev/video0 til kameraet og /dev/video1 refererer til tuneren, og noen ganger endres rekkefølgen til den motsatte etter en omstart. For alle maskinvareklasser unntatt lydkort og nettverkskort, kan dette løses ved å opprette Udev regler for tilpassede vedvarende symlinker. Tilfellet med nettverkskort dekkes separat i avsnitt 7.5, "Generell nettverkskonfigurasjon", og lydkortkonfigurasjon finner du i BLFS.

For hver av enhetene dine som sannsynligvis har dette problemet (selv om problemet ikke eksisterer i din nåværende Linux distribusjon), finn den tilsvarende katalogen 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-ID og/eller serienummer):

udevadm info -a -p /sys/class/video4linux/video0

Skriv deretter regler som lager symlinkene, for eksempel:

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 fremdeles refererer tilfeldig til tuneren og webkameraet (og dermed aldri skal brukes direkte), men det er symlenkene /dev/tvtuner og /dev/webcam som alltid peker til riktig enhet.

Forrige Hjem Neste