udev: két diszk, ugyanaz a serial

Debian GNU/Linux

Hello,

Debian Etch, 2.6.24-etchnhalf.1-686, udevd 0.105

A rendszeren van két USB-s diszk, jellemzően felváltva feldugva (mentés megy rá heti váltásban). Az a gond hogy egy ideje az udev ugyanazt a serial-t jelzi mindkét diszkre, a script ami figyeli a diszk cserét nem tud különbséget tenni.
A két diszk egy szállítás, ugyanaz a márka (Samsung HD642JJ), az udevadm ezt adja: 

# udevinfo -a -p /sys/block/sdb | grep serial
    ATTRS{serial}=="31AF4D71B008"
    ATTRS{serial}=="0000:00:1d.7"
# udevinfo -a -p /sys/block/sdc | grep serial
    ATTRS{serial}=="31AF4D71B008"
    ATTRS{serial}=="0000:00:1d.7"

(a két serial helyesen: 31AF4D71B008, 31AF4D71B000)

Ha az usb_storage modult újratöltöm, néha az udev a 00 végű eszközt nem hozza létre a disk/by-id könyvtárba: 

# ls -l /dev/disk/by-id/
összesen 0
lrwxrwxrwx 1 root root  9 2010-03-11 16:48 scsi-SServeRA_Sys_FFA27D29 -> ../../sda
lrwxrwxrwx 1 root root 10 2010-03-11 16:48 scsi-SServeRA_Sys_FFA27D29-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2010-03-11 16:48 scsi-SServeRA_Sys_FFA27D29-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2010-03-11 16:48 scsi-SServeRA_Sys_FFA27D29-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 2010-03-11 16:48 scsi-SServeRA_Sys_FFA27D29-part5 -> ../../sda5
lrwxrwxrwx 1 root root  9 2010-03-12 21:14 usb-SAMSUNG_HD642JJ_31AF4D71B008 -> ../../sdc
lrwxrwxrwx 1 root root 10 2010-03-12 21:14 usb-SAMSUNG_HD642JJ_31AF4D71B008-part1 -> ../../sdc1

Nincs sdb itt, de amúgy létezik az eszköz. Viszont a következő reload után van link a helyes serial-al.

A /dev/.udev/db/block@sd[bc] tartalma viszont majdnem tök ugyanaz: 

N:sdb
S:disk/by-id/usb-SAMSUNG_HD642JJ_31AF4D71B008
S:disk/by-path/pci-0000:00:1d.7-usb-0:4:1.0-scsi-0:0:0:0
M:8:16
E:ID_VENDOR=SAMSUNG
E:ID_MODEL=HD642JJ
E:ID_REVISION=1112
E:ID_SERIAL=SAMSUNG_HD642JJ_31AF4D71B008
E:ID_TYPE=disk
E:ID_BUS=usb
E:ID_PATH=pci-0000:00:1d.7-usb-0:4:1.0-scsi-0:0:0:0

értelemszerűen a név, path és minor értékek mások, de a serial itt is ua.

Van valakinek ötlete mitől lehet ez?

Köszönöm:

a.

  • 1337 megtekintés

( sany | 2010. 03. 15., h – 01:12 )

Esetleg a helyes seriallal udev szabályt írsz mindkét diszkre
és ezzel csatolod?

Hát, ezt nem értem. Most ütöttem be a Debian csomagkeresőbe, hogy

linux-image-2.6.24

és azt "sorry" -t kaptam. A google a debian.org -on azt találta hogy "etch-and-a-half" és úgy kezdi, hogy nem javasolt, telepítsd fel a Lenny -t.
Mondjuk ez nem ötperc, de tartok tőle hogy ez lesz a megoldás. Egyébként nem lehet hogy a frissítés óta csinál ilyeneket - ha jól értem régebben ez jól működött. Akkor lehet hogy a downgrade a linux-image-2.6.18 -ra megoldhatja (nincs old boot konfig?)

* Én egy indián vagyok. Minden indián hazudik.

Hello,

és azt "sorry" -t kaptam
az a fura hogy most a dist-upgrade is csak a clamav-ot és a segédeit akarja frissíteni :)

és úgy kezdi, hogy nem javasolt
az egész etch-re azt mondják hogy nem javasolt már :), legalábbis a debian-users-en ezt mondta egy tag - tudom, nem jelent semmit.

Mondjuk ez nem ötperc, de tartok tőle hogy ez lesz a megoldás
igen, és azt a nem-öt-percet elég nehéz lesz megtalálni, hogy mikor.

nem lehet hogy a frissítés óta csinál ilyeneket - ha jól értem régebben ez jól működött
igen működött, a serial-okat anno így írtam be a script-be és a rule-okba.

Downgrade-et nem igazán akarok, akkor megoldom másképp upgrade-ig.

Köszi:

a.

( egeresz | 2010. 03. 17., sze – 16:57 )

adj neki filesystem cimket

es a /dev/disk/by-label/ alapjan probalkozz.

hello,

köszi, épp most ajánlották uezt a debian-users-en, ami workaround-nak akár jó is lehet - kérdés hogy meglevő encrypted fs-en lehet-e label-t létrehozni (utólag) és azt az udev fogja-e olvasni, ill bármi más? (vagy kell hozzá a kulcs minden esetben?) (ilyet még nem csináltam, lehet h hülye a kérdés).

(amúgy a disk/by-id/ alatt ott a symlink, azt is lehet használni, csak gondoltam lehetne elegánsabban, nem keresgélni a linkek között...)

köszi:

a.

na valami ilyesmire számítottam... :(

btw: ha az udev amúgy detektálja hogy felcsatlakoztattak valamit, és meghív egy scriptet ami megnézi a symlinket a /dev/disk/by-id/ alatt és abból grep/sed/awk/cut kókánnyal kiszedi a serialt, akkor az is működhet, de ezt lett volna jó elkerülni.

köszönöm:

a.

Köszönöm, ennyire nem merültem még el az udev-ben.

Az egy dolog h az udev ezeken keresztül hozza létre, de az udev paraméterezi fel nem? Ezek szerint a udev jól működik?
(bár a topic nyitóban azt írtam h van amikor nem jön létre pl az sdb)

Ha már itt tartunk: a /dev/.udev/db/block\@sd* file-ok hogy jönnek létre? Azokban viszont rosszul vannak a serial-ok, konkrétan mindkettőben ugyanaz a serial van (volt).

Köszi:

a.

kernel felismer egy device-t.
felveszi a /sys/ strukturaba (a kernel)
kiszol az udev-nek (ami userspace program) hogy esemeny volt.
Az udev a konfigja alapjan csinal valamit. Pl, ha diszk volt, akkor tobbek kozott a fent emlitett helper programokkal kideriti az ID-t, meg a serialt meg midnenfelet. Nem tudom, hogy az udev mit csinal, mit tarol el a /dev/.udev/ alatt, most ez nekem is uj.

Kiprobalhatod, hogy letorlod a kerdeses cuccokat onnan, ez egy temporalis terulet, boot-kor ujraepiti az udev.

( airween v | 2010. 03. 17., sze – 21:20 )

Csak ráadás: ma du az egyik felhasználó kihúzta mindkét USB-s diszket, most az egyik eszköz symlink-jei (és csak az egyiké) ott maradtak: 

ls -la /dev/disk/by-id/ | grep sd[bc]
lrwxrwxrwx 1 root root   9 2010-03-12 21:40 usb-SAMSUNG_HD642JJ_31AF4D71B000 -> ../../sdb
lrwxrwxrwx 1 root root  10 2010-03-12 21:40 usb-SAMSUNG_HD642JJ_31AF4D71B000-part1 -> ../../sdb1

sírok... :(

a.

mikor volt bootolva?

03.11-én.
12-én lett a két diszk felcsatlakoztatva, a dátum amúgy stimmel a fenti symlinknél. És a másik diszkre is ez a dátum volt.

ez nekem ugyanannak a hibanak tunik. Az udev valami miatt nem proceszalja jol a dolgokat.
hát'ja, túl sok dolgot nem konfigurálhattam félre, így marad a bug :)

Köszönöm:

a.