# [udev] Casualmente cambia ordine ai device [RISOLTO]

## Cazzantonio

Ho uno strano problema di cui non mi riesce di venire a capo...

Io ho una scheda wireless (ipw2200) che si connette ad un AP tramite wpa_supplicant e una opportuna chiave wpa.

Questo è il mio /etc/conf.d/net:

```
modules_eth0=( "!plug" )

config_eth0=( "dhcp" )

modules_eth1=( "!plug" )

modules=( "wpa_supplicant" )

wpa_timeout_eth1=90

wpa_supplicant_eth1="-Dwext -c /etc/wpa_supplicant.conf"

config_eth1=( "dhcp" )
```

Solitamente quando da terminale do /etc/init.d/net.eth1 start ottengo il seguente output e la rete è connessa:

```
heavensdoor ~ # /etc/init.d/net.eth1 start

 * Starting eth1

 *   Starting wpa_supplicant on eth1 ...                                          [ ok ]

 *   Starting wpa_cli on eth1 ...                                                 [ ok ]

 *     Backgrounding ...
```

Ogni tanto (da un po' di tempo ogni spesso... diciamo una volta ogni due riavvii...) non so perché ma lo script di init non lancia wpa_supplicant ma solo il dhcp, ovviamente in questo modo la rete resta in attesa in eterno (fino al timeout) e mi tocca uccidere il processo:

```
heavensdoor ~ # /etc/init.d/net.eth1 start

 * Starting eth1

 *   Bringing up eth1

 *     dhcp

 *       Running dhcpcd ...

Error, terminating on signal 2                                                    [ !! ]

 * ERROR:  net.eth1 caught an interrupt
```

Di solito perché lo script di init funzioni nuovamente in modo normale basta semplicemente riavviare... e questo è DAVVERO strano   :Shocked: 

Avete una minima idea di cosa possa scatenare questo comportamento che a primo avviso pare causale??   :Shocked: 

Vi prego diratemi fiducia nella natura determinista del mondo dell'informatica!   :Crying or Very sad: 

----------

## Cazzantonio

up?

----------

## MeMyselfAndI

guarda io uso wpa per le gestione delle connessione WIFI e un comportamento come il tuo non l'ho mai visto: 

se ti puo' essere utile ti posto il mio file di configurazione della rete e wpa_succplicant.conf vedi te se ci sono grosse differenze.

```

nitro ~ # cat /etc/wpa_supplicant.conf

ctrl_interface=/var/run/wpa_supplicant

ctrl_interface_group=wheel

ap_scan=1

network={

        ssid="HOME"

        key_mgmt=NONE

#       psk=023935848d4ce470ffb69aa5bc0d0258fb30a8add37e8605e7ded5a707ff9613

        priority=1

}

```

```

nitro ~ # cat /etc/conf.d/net

modules=("wpa_supplicant")

wpa_supplicant_eth0=("-w -Dwext")

wpa_timeout_eth0=30

config_HOME=("192.168.1.10 netmask 255.255.255.0 broadcast 192.168.1.255")

routes_HOME=("default via 192.168.1.254")

dns_servers_HOME=("192.168.1.254")

```

----------

## Cazzantonio

Non penso che il problema sia nel mio file di conf di wpa_supplicant:

```
heavensdoor ~ # cat /etc/wpa_supplicant/wpa_supplicant.conf

ctrl_interface=/var/run/wpa_supplicant

ctrl_interface_group=0

ap_scan=2

network={

        ssid="gruppospacca"

        scan_ssid=1

        proto=WPA

        auth_alg=OPEN

        key_mgmt=WPA-PSK

        pairwise=TKIP

        group=TKIP

        psk=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx    

}
```

Semmai potrebbe essere qualche tipo di bug dell'initscript solo vorrei capire COME   :Crying or Very sad: 

Quando avrò tempo me lo leggo tutto per capire come gestise la sotoria dei moduli e vedere se ne vengo a capo... ora non ho ne' tempo ne' voglia visto che ho già troppi grattacapi col programma della mia tesi

----------

## dark_knight

La mia idea è che all'avvio il computer scambi l'ordine con cui carica le interfacce di rete, quindi eth0 diventa la scheda wi-fi ed eth1 la scheda Ethernet.

Dico questo perchè io ho un problema simile: sul mio portatile ho 2 interfacce di rete (scheda wi-fi e scheda ethernet). Fino a qualche giorno fa, quando ancora non avevo configurato i moduli della scheda wifi, eth0 era la scheda ethernet. Oggi, la situazione è questa:

```
darkplace dark # ifconfig -a

eth0      Link encap:UNSPEC  HWaddr 00-C0-9F-00-00-2C-D3-14-00-00-00-00-00-00-00-00

          BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

eth1      Link encap:Ethernet  HWaddr 00:C0:9F:60:B3:BA

          inet addr:xxx.xxx.xxx.xxx  Bcast:xxx.xxx.xxx.xxx  Mask:xxx.xxx.xxx.xxx

          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:24076 errors:0 dropped:0 overruns:0 frame:0

          TX packets:14653 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:32957247 (31.4 Mb)  TX bytes:1409096 (1.3 Mb)

          Interrupt:17 Base address:0x4800

eth2      Link encap:Ethernet  HWaddr 00:0E:35:7C:BD:63

          BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:3036 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

          Interrupt:19 Memory:e0206000-e0206fff

lo        (...)

```

A parte il fatto che è comparsa dal nulla una misteriosa interfaccia eth0  :Wink: , eth1 è la scheda ethernet ed eth2 è la scheda wifi (al momento non collegata ad alcuna rete).

Dov'è la somiglianza nel tuo problema? Sta nel fatto che a volte (devo ancora capire quando e perchè, ma credo sia in qualche modo legato al fatto che il portatile parta con la batteria o con l'alimentazione) eth1 ed eth2 sono scambati, il che mi dà parecchio fastidio perchè la rete non viene inizializzata all'avvio, ma devo farlo manualmente...

----------

## Cazzantonio

può essere... buona idea...  :Confused: 

appena ricapita controllo!

Potrebbe essere legato al nuovo udev... io ho entrambi i supporti per le schede compilati come moduli... forse li carica a volte in ordine inverso...   :Confused: 

----------

## MeMyselfAndI

Ma se fosse dovuto ad un problema banale come quello del cambio nome del device non dovrebbe potersi avviare se rilanci l'initscript, il nome del device rimane sempre quello... o forse ho capito male io e con riavviare intendi spegnere-accendere il picci?

----------

## Cazzantonio

Si confermo! E' un problema di ordine di caricamento dei moduli che a quanto pare non è assolutamente univoco con il nuovo udev.

A questo punto mi domando quale sia la soluzione elegante... aprire un bug report a proposito di udev? (nel bugzilla di gentoo o in quello di udev?), cercare un modo per associare univocamente i nomi dei device?

 *MeMyselfAndI wrote:*   

> Ma se fosse dovuto ad un problema banale come quello del cambio nome del device non dovrebbe potersi avviare se rilanci l'initscript, il nome del device rimane sempre quello... o forse ho capito male io e con riavviare intendi spegnere-accendere il picci?

 

No il problema è che il nome dei device è scambiato dopo alcuni avvii... la soluzione banale è rimuovere entrambi i moduli e caricarli successivamente nell'ordine giusto. Forse non ho capito bene quello che intendi...

----------

## MeMyselfAndI

io rinomino all'avvio i device delle schede di rete con questa regola:

```

KERNEL=="eth*", SYSFS{address}=="00:0e:35:b5:9e:05", NAME="eth0", WAIT_FOR_SYSFS

KERNEL=="eth*", SYSFS{address}=="00:0f:1f:2b:16:57", NAME="eth1", WAIT_FOR_SYSFS

```

cosi' evito problemi di scambio nomi o altro.

----------

## Cazzantonio

qua viene affrontato questo problema:

http://marc.theaimsgroup.com/?t=116498436300001&r=1&w=2

qua invece potete guardare per l'unica soluzione funzionante al momento (pare che usare la blacklist e poi caricarli in modules.d/autoload sia buggato):

http://www.reactivated.net/writing_udev_rules.html#example-netif

Lasciatemi dire, in via del tutto personale, che una volta tanto penso che i devel abbiano scazzato alla grande. Ok che basarsi sull'ordine di caricamento POTREBBE essere fallace, ma di fatto FINORA TUTTI SI SONO BASATI SULL'ORDINE DI CARICAMENTO!   :Evil or Very Mad: 

Almeno potevano sprecarsi nel mettere qualche einfo alla fine dell'ebuild di udev... almeno quello...   :Mad: 

Ogni tanto mi viene il pensiero che la politica di debian non sia del tutto sbagliata...   :Rolling Eyes:  Eventi come questi rendono troppo instabile l'aggiornamento di gentoo   :Rolling Eyes: 

@MeMyselfAndI

A cosa serve "WAIT_FOR_SYSFS" ?

----------

## .:chrome:.

 *Cazzantonio wrote:*   

> Ok che basarsi sull'ordine di caricamento POTREBBE essere fallace, ma di fatto FINORA TUTTI SI SONO BASATI SULL'ORDINE DI CARICAMENTO!

 

ma scusa... d'altronde quale altra possibilità c'è?

io penso che sia la soluzione più semplice, e la più funzionale.

vuoi imporre un determinato ordine di rilevamento? basta che metti tutto modulare e imponi l'ordine di caricamento dei moduli

----------

## MeMyselfAndI

 *Cazzantonio wrote:*   

> 
> 
> @MeMyselfAndI
> 
> A cosa serve "WAIT_FOR_SYSFS" ?

 

Dal man di udev:

```

WAIT_FOR_SYSFS

          Wait for the specified sysfs file of the device to be created. Can be used to fight against kernel sysfs timing

          issues.

```

io lo uso perche' mi era stato consigliato da qualcuno se non mi ricordo male, dovrebbe prevenire problemi tra kernel e interfaccia del device se non sbaglio.

Purtroppo non mi sono mai addentrato nelle specifiche di questa opzione e non so nel dettaglio cosa comporti averla o non averla. Diciamo che la uso perche' faccio come i pecoroni e mi han consigliato di metterla.

----------

## Cazzantonio

 *.:chrome:. wrote:*   

> ma scusa... d'altronde quale altra possibilità c'è?
> 
> io penso che sia la soluzione più semplice, e la più funzionale.

 

Ok ma potevano almeno avvertire... conta che la maggior parte degli utenti NON SA come scrivere le regole di udev mentre probabilmente ha imparato come configurare /etc/conf.d/net ed è abituata a usare quello confidando che i nomi dei device siano sempre quelli.

[piccola parentesi]udev genera un file /etc/udev/rules.d/70-persistent-net.rules che dovrebbe mappare le schede sempre nello stesso ordine ma a quanto pare non funziona... io ho usato le seguenti regole in /etc/udev/rules.d/10-local.rules:

```
#Ethernet lan con driver r8169

DRIVERS=="r8169", NAME="eth0", SYMLINK="elan"

#Wireless lan con driver ipw2200

DRIVERS=="ipw2200", NAME="eth1", SYMLINK="wlan"
```

[/piccola parentesi]

 *Quote:*   

> vuoi imporre un determinato ordine di rilevamento? basta che metti tutto modulare e imponi l'ordine di caricamento dei moduli

 

Che come hai visto bene non è possibile... udev non garantisce un ordine di caricamento... puoi solo creare regole come quella di prima

----------

## .:chrome:.

forse ho capito cosa intendi.

alludi forse al fatto che udev >087 sostituisce coldplug nella funzione di caricamento dei moduli?

per quanto riguarda la scheda di rete ho risolto mettendo tutta la classe net in "ignore", nella configurazione di udev:

 */etc/udev/rules.d/05-udev-early.rules wrote:*   

> SUBSYSTEM=="net",    OPTIONS="ignore_device"

 

successivamente carico nell'ordine che voglio.

pensi possa fare al caso tuo?

----------

## Cazzantonio

 *.:chrome:. wrote:*   

> forse ho capito cosa intendi.

 

Intendo dire che è frustrante fare un aggiornamento e scoprire che qualcosa non funziona come prima... soprattutto che questo qualcosa non è desumibile da qualche warning, einfo, changelog o annuncio... ci ho messo qualche giorno a capire cosa fosse...

Se avessi gestito un server mi sarebbero girati i coglioni (ok forse mi sarei dato da fare e avrei risolto prima... comunque mi sarebbero girate le balle lo stesso)

----------

## guerro

Domanda stupidissima quanto banale:

E se utilizzassi la convenzione per cui:

eth  -> LAN

wlan -> Wireless?

Non otterresti sempre che la scheda di rete sarà sempre eth0 e la wireless sempre wlan0?

Per lo meno dovresti aggirare il problema che a quanto ho capito è di udev...   (che spero risolvano i devel)

----------

## Cazzantonio

 *guerro wrote:*   

> Domanda stupidissima quanto banale:
> 
> E se utilizzassi la convenzione per cui:
> 
> eth  -> LAN
> ...

 

Il problema l'ho già risolto da un bel po'... (da cui il tag [risolto])

Il resto della polemica è solo per ribadire che non mi piace la politica dei dev su questo aggiornamento (ovvero quella di non avvertire debitamente gli utenti in modo appropriato)

----------

## comio

 *Cazzantonio wrote:*   

>  *guerro wrote:*   Domanda stupidissima quanto banale:
> 
> E se utilizzassi la convenzione per cui:
> 
> eth  -> LAN
> ...

 

a mio avviso non è necessariamente colpa di udev. In realtà tutto dipende da come partono i driver... chi prima arriva, meglio alloggia. L'errore di fondo è quello di usare gli identificativi ethX in modo generico, dato che a priori non sono associabili ad un HW ben definito (se non dopo il boot del driver). La soluzione è quella di riferirsi al dispositivo con qualcosa di univoco che lo distingue (mac) e, per semplicità, associare un nome più mnemonico (udev).

Altri os si limitano a puntare i dispositivi di rete con il mac o derivati dello stesso proprio per evitare di questi casini. In ogni caso, per mia esperienza personale, bisogna farsi una bella regola udev ed assegnare nomi che non siano semplicemente ethX ma che, magari, fanno capire meglio.

Io ho nominato le mie interfacce di rete in questo modo:

```

eth_dmz

eth_out

eth_wifi

```

ciao

luigi

----------

## dark_knight

Scusate se riesumo questo vecchio thread, ma c'è qualcosa che non riesco a spiegarmi.

Il mio problema di assegnazione random dei nomi di interfaccia persiste, nonostante, dopo una lettura di man udev e di quanto postato sopra, e qualche sana googlata, abbia fatto queste modifiche ai file delle regole:

* aggiunto

```
SUBSYSTEM=="net", OPTIONS="ignore_device"
```

a 05-udev-early.rules

* aggiunto

```
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0E:35:7C:BD:63", NAME="eth4"

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:C0:9F:60:B3:BA", NAME="eth5"
```

oppure

```
KERNEL=="eth*", SYSFS{address}=="00:0E:35:7C:BD:63", NAME="eth4", WAIT_FOR_SYSFS

KERNEL=="eth*", SYSFS{address}=="00:C0:9F:60:B3:BA", NAME="eth5", WAIT_FOR_SYSFS
```

a 70-persistent-net.rules

(non ho abilitato queste due ultime coppie di regole assieme, ma solo in mutua esclusione; notare i numeri di interfaccia molto alti, in maniera che potessi notare chiaramente un successo nell'applicazione della regola)

Ma nulla cambia... i nomi continuano ad essere assegnati a caso  :Sad:  Idee? Dove sbaglio?  :Smile: 

----------

## MeMyselfAndI

le regole di udev vengono lette da 00 a 99, e se un device viene creato con un regola non viene ricreato nuovamente se compatibile con un'altra regola:

aggiungi 

```

KERNEL=="eth*", SYSFS{address}=="00:0E:35:7C:BD:63", NAME="eth4", WAIT_FOR_SYSFS

KERNEL=="eth*", SYSFS{address}=="00:C0:9F:60:B3:BA", NAME="eth5", WAIT_FOR_SYSFS

```

queste due righe a 10-nomeacaso.rules

inoltre penso tu possa togliere

```

SUBSYSTEM=="net", OPTIONS="ignore_device"

```

----------

## dark_knight

Grazie del suggerimento... ho aggiunto quelle due righe da te riportate in un file chiamato 10-custom.rules, ma non ho tolto

```
SUBSYSTEM=="net", OPTIONS="ignore_device" 
```

Il problema, però, continua a ripresentarsi...  :Sad: 

----------

## MeMyselfAndI

giusto per curiosita' esegui udevstart una volta modificate le regole vero?

a cosa serve quella regola in 05?

----------

## dark_knight

Si, e non andava. Ho anche riavviato il sistema per evitare che ci fossero eventuali interferenze a me ignote ed, all'avvio, il problema persisteva.

Quella regola l'ho aggiunta seguendo le indicazioni di questo messaggio di .:chrome:.

 *.:chrome:. wrote:*   

> per quanto riguarda la scheda di rete ho risolto mettendo tutta la classe net in "ignore", nella configurazione di udev:
> 
>  */etc/udev/rules.d/05-udev-early.rules wrote:*   SUBSYSTEM=="net",    OPTIONS="ignore_device" 
> 
> successivamente carico nell'ordine che voglio.
> ...

 

Proverò a rimuoverla non appena torno davanti al computer  :Smile: 

AGGIORNAMENTO:

* con quella regola, avevo il problema segnalato prima, cioè i nomi delle interfacce flippavano a piacere tra eth1 ed eth2

* senza quella regola, aggiungo un tocco di singolare entropia alla situazione: oltre ad assumere i nomi eth1 ed eth2, a random, le interfacce a volte assumono dei nomi nella forma ethX, con X il primo numero disponibile dopo quelli che io avevo definito nelle regole. In altre parole, poichè nelle regole avevo impostato eth4 ed eth5, le interfacce prendevano i nomi eth6 (se solo una non prendeva un nome tra eth1 ed eth2) oppure eth6 ed eth7 (senza un ordine preciso).

* come ulteriore test, ho provato a mettere in lettere minuscole i MAC address delle schede. Questa soluzione si è dimostrata vincente (con la regola di ignore_device DISATTIVATA), in quanto adesso le interfacce prendono il nome da me deciso (un qualsiasi nome mnemonico io definisca). Risolto quindi il problema dell'ordinamento.

Ora però, se qualcuno di voi ha un'idea, vi chiederei come fare per togliere l'interfaccia eth0 (che, ricordo, ha queste specifiche:

```
eth0      Link encap:UNSPEC  HWaddr 00-C0-9F-00-00-2C-D3-14-00-00-00-00-00-00-00-00

          BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b) 
```

non è associata ad alcun dispositivo fisico ed è comparsa dal nulla tra un aggiornamento ed un altro) Magari la soluzione a questo problema risiede lo stesso in udev? Non che questa eth0 mi dia fastidio, ma per una questione di ordine...  :Smile: 

----------

## sanzo77

Mi accodo penosamente alle richieste di dark_knight, ho appena aggiornato ed'è comparsa questa eth0 che non so come togliere... inoltre ho letto Writing udev rules ma inutile dire che nn ci ho capito un H . Però ora mi riapplico e vedo di capire dove devo mettere mano e come... 

Vorrei tutto sommato togliere eth0 o per lo meno farlo tornare ad essere la wifi... ed eth1 ritornare ad essere la lan.  :Crying or Very sad: 

----------

## sanzo77

Allora vediamo se ho capito (ma dubito visto che non funziona):

per risolvere il problema dei nomi assegnati random devo dire ad udev in che sequenza caricare i device

vado in /etc/udev/rules.d e creo un nuovo file tipo 10-myudev.rules e ci metto 

```

KERNEL=="eth*", SYSFS{address}=="00:0E:35:7C:BD:63", NAME="eth4", WAIT_FOR_SYSFS

KERNEL=="eth*", SYSFS{address}=="00:C0:9F:60:B3:BA", NAME="eth5", WAIT_FOR_SYSFS 

```

ovviamente sostituendoci i miei mac address e i nomi che voglio io. Fino qua tutto a posto, infatti attualmente ho le mie due interfacce che si chiamano eth4 e eth5.

Ora però vorrei capire una cosa: 

in /etc/init.d ci sono 2 link verso net.lo che si chiamano net.eth0 e net.eth1, devo eliminarli e sostituirli con eth4 e eth5 facendoli puntare sempre a net.lo?

Inoltre permane il problema di eth0 che continua ad essere quel device sconosciuto...

----------

## MeMyselfAndI

Esattamente. Occhio che il mac address deve essere uguale, maiuscole e minuscole comprese.

----------

## sanzo77

Grazie dell'aiuto.

Il problema dell'ordinamento sembra risolto, pero' c'e' qualcosa che nn mmi quadra:

se io levo il modulo e lo rimetto mi riparte da eth1. Inoltre durante il boot sembra che abbia tenuto traccia di eth0 (ora non ricordo il warning esattamente), ma dato che ho tolto il symlink skippa l'operazione...

E cmq il problema di eth0 latente con quella forma strana nn si e' risolto... continua ad esistere...

----------

## sanzo77

Uppo la discussione perche' il fatto di aver tolto il symink di eth0 comporta un piccolo rallentamento in fase di boot: prima di darmi il warning in cui mi avverte che il collegamento a net.eth0 e' mancante ci sono circa 10 secondi di attesa (durante i quali il sistema non fa nulla).

Vorrei capire chi e' che sottintende che debba esistere eth0 e come fare a eliminarla...

----------

## comio

 *sanzo77 wrote:*   

> Uppo la discussione perche' il fatto di aver tolto il symink di eth0 comporta un piccolo rallentamento in fase di boot: prima di darmi il warning in cui mi avverte che il collegamento a net.eth0 e' mancante ci sono circa 10 secondi di attesa (durante i quali il sistema non fa nulla).
> 
> Vorrei capire chi e' che sottintende che debba esistere eth0 e come fare a eliminarla...

 

- elimina dal runlevel di default net.eth0 usando rc-update.

- rinomina net.eth0 in net.NuovoNomeCheHaiDato

- Modifica /etc/conf.d/net mettendo il nome giusto del device (al posto di eth0)

- aggiungi al runleve di default net.NuovoNomeCheHaiDato

ciao

----------

## sanzo77

Ok! Grazie, era rimasto appeso e non lo vedevo con rc-update -s, mi dava un warning che pero' scorreva esattamente 1 riga sopra alla dimensione della console e mi era sfuggita  :Neutral: 

 *Quote:*   

> 
> 
> - aggiungi al runleve di default net.NuovoNomeCheHaiDato
> 
> 

 

Questo e' necessario? Io ho messo 2 symlink net.eth4 e net.eth5 in /etc/init.d ed entrambi puntano a net.lo. In questo modo nn vengono cmq eseguiti? (o meglio vengono eseguiti perche' al boot vedo che richiama i 2 link, la tua soluzione cosa comporterebbe?).

----------

## comio

 *sanzo77 wrote:*   

> Ok! Grazie, era rimasto appeso e non lo vedevo con rc-update -s, mi dava un warning che pero' scorreva esattamente 1 riga sopra alla dimensione della console e mi era sfuggita 
> 
>  *Quote:*   
> 
> - aggiungi al runleve di default net.NuovoNomeCheHaiDato
> ...

 

magari hai hotplug che ti fa partire le if. Se funzia... va bene come hai già!

ciao

----------

## Cazzantonio

Non so se è già stato fatto notare ma il nuovo udev si prende cura di questo problema senza bisogno di creare regole personalizzate. (Si vede che hanno notato il problema... certo se ci pensavano PRIMA... beh meglio tardi che mai).

C'è questa regola

```
/etc/udev/rules.d/75-persistent-net-generator.rules
```

Che genera questo file

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

Dove vengono salvati i device trovati di volta in volta in modo da chiamarli sempre con lo stesso nome.

In pratica non dovete più cambiare niente ne' scrivere regole ad hoc

----------

