Első (SATA) merevlemez neve?

Merevlemezek, vezérlők

Adott egy (PXE-ről, CD/DVD-ről, vagy USB mass storage-ról) bootoló live Linux "disztribúció", amin egy archiváló/helyreállító szoftver fut, előregyártott feladatlistával, felhasználói interakció nélkül.

Az a feladat, hogy a gépben található, elsődleges merevlemezről (desktop gépek, a többségükben 1 darab SATA eszköz van) adatokat gyűjtsünk be. (vagy adatokat írjunk ki kötegelten)

Ez a feladat 1995-től 2013-ig nem jelentett problémát, mert az elsődleges merevlemezt mindig /dev/sda-nak hívták (PATA estében egy időben /dev/hda-nak) tehát, ha az volt a kérés, hogy mondjuk a harmadik partíció tartalmát olvassuk be, akkor megcsócsáltuk a /dev/sda3-at, és mindenki boldog volt.

Jött azonban a nagyszerű 3.6+ kernel, ahol párhuzamosították egyes blokk eszközök drájverének betöltését, így már többet nem a /dev/sda az elsődleges diszk, hanem mondjuk a bootolásra használt pendrájv. Vagy éppen a gépben lévő SD kártya olvasó. Vagy akármi.

A net ugye azzal van tele, hogy a fájlrendszerek csatolására, és a bútlóder konfigurálására használj UUID-ot/GUID-ot/PARTUUID-ot/LABEL-t/mittudoménmit. Ez oké, de ez azt feltételezi, hogy tudom, hogy az adott gépben mik ezek az egyedi azonosítók. Én meg nem tudom, mert ugyanazt az image-et bootolom fel 350 gépen, ahol minden azonosító egyedi. Sőt, ad abszurdum, lehet, hogy a diszk töküres, mert épp az a feladat, hogy írjak rá image-ből egy rendszer partíciót. Na, de melyik eszközbe, ha nem ő a /dev/sda?

initrd/initramfs és udev van, de mit mondjak neki, mit mappeljen le /dev/őkellnekem névre?

Van az a nagyon workaround ötletem, hogy modularizálni az összes nem-SATA/SAS block device drivert, és utólag betölteni (vagy egyáltalán be sem tölteni, csak ha épp tényleg kell) de tetszene valami korrektebb metódus. Ja, a kernel jelenleg monolitikus, történelmi okok miatt... (Tecciktudni, beágyazott rendszer, ami régen 1 floppyról ment, csak azóta kicsit kinőtte magát)

Ötletek are welcome.
Kösz!

  • 7513 megtekintés

( errotan v | 2014. 01. 27., h – 07:59 )

Végigmész az sda, sdb, sdc, stb. fájlokon "fdisk -l /dev/sda" paranccsal és elemzed a kimenet.

Mivel az archiváló szoftvernek konkrét device fájlt kell megadnom, ezért a by-path önmagában nem elég, mert kell valami, ami parse-olja - jelen esetben - a fájlnevet, ez alapján eldönti, hogy melyik a nyerő diszk, és mondjuk gyárt rá egy symlinket.

Akkor már egy fokkal jobb, ha inkább közvetlen udev rule-t hegesztek rá.

Na, akkor mutatok nektek érdekeset. Ez egy Debian 7.0, "gyári" udev csomaggal: 


# udevadm test -a -p  $(udevadm info -q path -n /dev/sda) 2>/dev/null | egrep '^ID_PATH=|^DEVPATH='
DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda
ID_PATH=pci-0000:00:1f.2-scsi-0:0:0:0


# udevadm test -a -p  $(udevadm info -q path -n /dev/sr0) 2>/dev/null | egrep '^ID_PATH=|^DEVPATH='
DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0
ID_PATH=pci-0000:00:1f.2-scsi-0:0:0:0

A két különböző eszközre (HDD és DVD író) ugyanaz az ID_PATH jön vissza, holott láthatóan a DEVPATH nem ugyanaz. A "60-persistent-storage.rules" fájl ez alapján symlinkel a /dev/disks/by-path alá, márpedig így szépen felülírják egymást.

Nevezzük csak bugnak? :) Ennyit az udev által kreált perzisztens nevekről :P

A 7.0 az a wheezy?
Mert ha az, akkor valami egyéb gubanc van. Ugyanezt én is kipróbáltam, de nekem eltérő értékeket produkált.
A vadonatúj mint (32 bites, a debianom 64-es) meg egyáltalán nem tud ID_PATH-ról.

Ugye nem virtuális gépen próbáltad?
Hálókártyákkal tud hülye vicceket az udev, nehogy kiderüljön, hogy egyéb hardverrel is.

Valamiért a virtualizált hálókártyákat a fizikaiaktól eltérően kezeli. Van egy szép, hosszú exclude listája, benne többek közt a Virtualbox, vmware hálókártyáival...

Igen, 64 bites Wheezy. Nem virtualizált, ez az asztali gépem, egy Gigabyte alaplappal, az alaplapi AHCI vezérlőn egy SSD (/dev/sda) és egy DVD író (/dev/sr0) lóg.

Kipróbáltam, hasonló szopás van máshol is: ez egy HP Microserver: 


backup2 # udevadm test -a -p  $(udevadm info -q path -n /dev/sda) 2>/dev/null | egrep '^ID_PATH='
ID_PATH=pci-0000:00:11.0-scsi-0:0:0:0

backup2 # udevadm test -a -p  $(udevadm info -q path -n /dev/sdb) 2>/dev/null | egrep '^ID_PATH='
ID_PATH=pci-0000:00:11.0-scsi-0:0:0:0

backup2 # udevadm test -a -p  $(udevadm info -q path -n /dev/sdc) 2>/dev/null | egrep '^ID_PATH='
ID_PATH=pci-0000:00:11.0-scsi-0:0:0:0

backup2 # udevadm test -a -p  $(udevadm info -q path -n /dev/sdd) 2>/dev/null | egrep '^ID_PATH='
ID_PATH=pci-0000:00:14.1-scsi-0:0:1:0

Látható, hogy három eszközre is ugyanazt az ID_PATH-t adja. És sz.rok is a symlinkek, pontosabban ugye csak kettő van a négy helyett.

Szerk: időközben kipróbáltam Debian 6.0-n is (Squeeze) ott még külső path_id binárist hívogat az udev, de ugyanúgy sz.r ott is.

Mindjárt töltök egy aktuális udev forrást, de szerintem máig nincs rá normális javítás. Amit a fenti git linken találsz, azt nevezzük inkább workaroundnak.

> This was "fixed" upstream and in saucy by dropping the by-path symlinks
> for drives which are not "real" SCSI but actually ATA drives

Magyarul, egész egyszerűen kidobták a by-path linkeket.

( zamboriz v | 2014. 01. 27., h – 12:13 )

http://en.community.dell.com/techcenter/os-applications/w/wiki/using-ed…

https://bugzilla.redhat.com/show_bug.cgi?id=621175#c37 


Below is the algorithm that should be used to detect boot device using EDD data.

Find boot device:
   Build block device list L
   For each device B in L
      Map B to edd device (see below).
      If B maps to int13_dev80
         Return B // Install bootloader in B
      If B maps to other edd device
         Drop B from L
   If bootdevice is not found
      Return can't detect, fall back to mbr_signature checking or return first device from L if no mbr_signature available

Map block device B to edd device:
   For each dir E in /sys/firmware/edd/*
     If file /sys/firmware/edd/E/host_bus does not exist or
        file /sys/firmware/edd/E/interface does not exist
          Return can't map
     A = PCI address from /sys/firmware/edd/E/host_bus
     C = channel from host_bus /sys/firmware/edd/E/host_bus
     I = interface type from /sys/firmware/edd/E/interface (SCSI or ATA)
     If I is ATA
        D = device number from /sys/firmware/edd/E/interface
        P = /sys/devices/pci0000:00/0000:%s/host%d/target%d:0:%d:0/%d:0:%d:0/block/%s", A, C, C, D, C, D, B
     Else if I is SCSI
       D = id from /sys/firmware/edd/E/interface
       P = /sys/devices/pci0000:00/0000:%s/virtio%d/block/%s, A, D, B
     Else
       Return can't map // other interfaces can be added later
     If P exists
       Return E // B maps to E
  Return can't map

( PcZolee v | 2014. 01. 27., h – 12:22 )

Helló.

Értem a problémádat, és biztos meg lehet oldani mindenféle heggeszgetésekkel, de -bár tudom, hogy nem minden szempontból megoldás- a helyedben 3.6 alatti kerneleket használnék a live rendszeremen, így máris meg van oldva a gond. Persze, ha van vmi, ami indokolja, hogy 3.6+ -t használj, akkor nem szóltam.

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

( gabrielakos v | 2014. 01. 27., h – 22:59 )

Nekem még tán sose volt gépben 3.6-os kernel, mindenesetre már sokkal régebbi kerneleknél se volt feltétlen igaz, hogy az sda-ról bootoltunk vagy hogy következőleg arról fogunk bootolni amit most sda-nak hívnak, sőt...

Én mondjuk olyat tudok elképzelni, hogy az lsscsi kimenetét megnézed, abból kiszeded ami diszk lehet (márka/típus alapján pl.) azon meg fdisk -l
Már persze feltéve, hogy pontosan egy diszk van és arra akarsz telepíteni.

--
Gábriel Ákos
http://i-logic.hu

( cheeky v | 2014. 01. 28., k – 09:35 )

Nem cizelláltam túl, de onnan indulnék, hogy sysfs-ből minden paraméterét tudod a diszkeidnek, ami érdekelhet. Nyilván tudod annak a diszknek a gyártóját/típusát, amiről jelen esetben boot-olsz (pendrive).

Fogod, csinálsz egy find-ot: 

find /sys/bus/scsi/devices/[0-9]*/ -type d -name scsi_disk

Ha akarod, rendezed. Megvannak a diszk típusú SCSI eszközeid, felismert kontrollerenként, csatornánként, eszközönként sorba rendezve. Addig mész a listán, míg olyan diszket nem találsz, ami nem a pendrive-od.

> Közelítsük meg másképp: amiről a beágyazott cuccod fut, az tuti USB, nem?

Hát, a topicnyitó legelső mondata alapján ("Adott egy (PXE-ről, CD/DVD-ről, vagy USB mass storage-ról) bootoló live Linux "disztribúció", amin egy archiváló/helyreállító szoftver fut,...") én kicsit másképp kezdtem volna a helyedben ezt a hozzászólást, de már mindegy :)

Egyébként az USB eszközök kizárása közel jár a megoldáshoz, bár inkább az udev-et fogom megtuningolni, hogy nekem jobban tetsző eszközneveket hozzon létre.

Bocs, de a sokadik nekifutásnál az eredeti peremfeltétel feledésbe merült.
Alapvetően azonban ha úgy állsz neki, hogy nem kizársz bizonyos eszközöket, hanem csak a hard disk típusú eszközöket veszed figyelembe, akkor jó úton járhatsz.

Az a baj az egésszel amúgy, hogy az udev is elég bizonytalan e téren, mint azt több hozzászólásban is boncolgattátok, de a sysfs is release-ről release-re változik. Szóval bármilyen megoldást is találsz, felkészülhetsz rá, hogy 3-4 kernel verziónként utána kell hangolnod. :(

( ruczati | 2014. 01. 28., k – 10:35 )

<nemkonstruktív>
Első szexpartnered neve?
</nemkonstruktív>

( xclusiv v | 2014. 01. 29., sze – 20:39 )

Az én tippem is lswh, nálam ilyen szépen listázza (monnyuk 3.2-es kernellel):

$ sudo lshw -class disk
...
*-disk:0
description: ATA Disk
product: ST3500620AS
vendor: Seagate
...
logical name: /dev/sda

Itt már a description is beszédes, vendor-ból meg ma már csak néhány van, az is jó lehet.