# Hochzählung der Dev-Nodes

## b3cks

Moin,

mir ist gestern malwieder ein Problem aufgefallen. Vor langer Zeit, als ich mein ThinkPad T61 frisch eingerichtet hatte, fand ich mein DVD/RW-LW unter /dev/dvd bzw. /dev/dvdrw, wie auch gewünscht. Alles war gut.

Irgendwann wollte ich dann mal eine DVD brennen, aber das damalig genutzte Brennprogramm verweigerte seinen Dienst. Grund: Kein DVD-Laufwerk gefunden. Hm, dachte ich, es doch noch da. Ist es auch, aber nun unter /dev/dvd2 bzw. /dev/dvdrw2. Und das Brennprogramm war hart auf /dev/dvdrw eingestellt. Ärgerlich, aber leicht lösbar, das Problem.

Nun habe ich wieder das Problem. Gestern wollte ich eine DVD gucken, mittels dem Notebook. Und siehe da, mplayer findet kein Laufwerk. Denn dieses ist nun unter /dev/dvd3 bzw. /dev/dvdrw3 zu finden und mplayer guckt scheinbar nur unter /dev/dvd.

Kann mir mal einer erklären, warum und wieso das passiert und wie man dieses bescheidene Verhalten ändern kann? Das eigentliche Laufwerk ist nämlich /dev/hda und das ist bisher auch immer so geblieben. Da es ein Notebook ist, wird da auch nicht viel bzw. eigentlich gar nicht dran rumgefummelt - hardwareseitig. Also, wie kommt es zu dieser Hochzählung?

Gruß!

----------

## AmonAmarth

poste mal bitte den inhalt von /etc/udev/rules.d/70-persistent-cd.rules

anhand der einträge sollte man erkennen können wieso udev die device nummer hochzählt.

----------

## b3cks

Den Dateiinhalt kannst du hier einsehen. Ich nehme mal an, das Problem ist ganz einfach: Die ersteren Zeilen sind alte udev-Regeln, wodurch beim aktualisieren immer hochgezählt wurde!? Wenn ja, ist es sicher, die alten Regeln einfach zu löschen und die letzten einfach anzupassen?

----------

## AmonAmarth

 *b3cks wrote:*   

> Den Dateiinhalt kannst du hier einsehen. Ich nehme mal an, das Problem ist ganz einfach: Die ersteren Zeilen sind alte udev-Regeln, wodurch beim aktualisieren immer hochgezählt wurde!? Wenn ja, ist es sicher, die alten Regeln einfach zu löschen und die letzten einfach anzupassen?

 

afaik kannst du den inhalt einfach löschen und neustarten, danach sollte der zähler wieder bei "leer" landen. anpassen sollte auch gehen, solang du die alten einträge rauswirfst. die verschiedenen einträge scheinen durch ein kernelupdate hervorgerufen worden zu sein (einmal scsi und einmal IDE device).

----------

## Josef.95

Jo, in so einem Fall einfach die

/etc/udev/rules.d/70-persistent-cd.rules

löschen (oder wegsichern)

beim nächsten reboot wird diese von udev passend neu angelegt.

/edit:

Ähnliches wird auch in den Messages nach den mergen von udev erwähnt

(hier bez. der Netzwerkkarten)  *Quote:*   

>  * persistent-net does assigning fixed names to network devices.
> 
>  * If you have problems with the persistent-net rules,
> 
>  * just delete the rules file
> ...

  selbiges kannst du bei "Unstimmigkeiten" mit der "-cd.rules" Datei machen...

MfG

----------

## slick

 *Josef.95 wrote:*   

> Jo, in so einem Fall einfach die
> 
> /etc/udev/rules.d/70-persistent-cd.rules
> 
> löschen (oder wegsichern)
> ...

 

In der /etc/rc.conf (oder wars die /etc/conf.d/rc, habs gerade nicht im Kopf) gibts auch einen Eintrag um die persistenten Regeln ganz abzuschalten.

----------

## Max Steel

 *slick wrote:*   

> /etc/rc.conf (oder wars die /etc/conf.d/rc,

 

/etc/conf.d/rc ---> baselayout-1

/etc/rc.conf ---> baselayout-2/openrc

----------

## mv

 *slick wrote:*   

> In der /etc/rc.conf (oder wars die /etc/conf.d/rc, habs gerade nicht im Kopf) gibts auch einen Eintrag um die persistenten Regeln ganz abzuschalten.

 

Das ist keine gute Idee. Die bessere Vorgehensweise ist, die Regeln korrekt anzupassen: Offensichtlich ist ja das Testen von ENV{ID_PATH} in Deinem (mit "Du" meine ich den OP)  Fall nicht geeignet, um das Laufwerk eindeutig zu identifieren (weil Du anscheinend bei Kernel-Updates mal den Treiber umgestellt hast o.ä.). Wirf doch mal so etwas an wie 

```
 udevadm info --path=/sys/block/hda --query=all --attribute-walk
```

 (das "hda" ist natürlich ggf. anzupassen), um nach einer besseren Identifikationsmöglichkeit zu suchen (ein Serial z.B. oder den Namen): Dann kanst Du in den ersten vier Zeilen das ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0" ersetzen durch die bessere Identifikation (vergiss nicht, zwei == zu machen). Die restlichen Einträge der Datei kannst Du entsorgen (beim Einstecken der HUAWEI wird sowieso wieder ein passender Eintrag angelegt, wenn Du keine andere Regel dafür vorsiehst).

----------

## b3cks

Habe die Datei einfach gelöscht und neu gestartet. Nun ist sie wieder, mit den korrekten Einträgen, da.

Ich denke mal, bearbeiten wäre genauso gut gegangen. Vielen Dank für die Hilfe!

----------

## mv

 *b3cks wrote:*   

> Ich denke mal, bearbeiten wäre genauso gut gegangen.

 

Ich würde sie trotzdem bearbeiten: Dann bekommst Du auch keinen Ärger, wenn Du mit einem neuen Kernel (mit anderen Kerneloptionen) bootest.

----------

## b3cks

Gut, werde ich mich später mal mit befassen.

----------

