Debian - HDD serialok kinyerése

Debian GNU/Linux

Sziasztok!

Adott 2 régebbi Debian szerver. Mindkettőnél ki akarom nyerni a HDD serialokat.

A cciss_vol_status -V /dev/cciss/c*d0 az egyiknél működik, szépen kiírja a fw, verziót, a controllert és ami nekem kell minden diskre:

Physical drives: 5
connector 1I box 0 bay 1                 ATA     WDC WD2003...

.

.

.

 

A másiknál viszont ugyanerre a parancsra a "Physical drives:" rész elég hiányos. Azt szerencsére kiírja, hogy HP smart array p400-as kártya van benne és RAID5-ben van a kötet. + még pár kísérő adatot is ír (pl. R/W / total cache memory, cache ratio, stb.) A lényegi rész viszont csak ennyi:

Physical drives: 5
         connector  OK
         connector  OK
         connector  OK
         connector  OK
         connector  OK

 

hpacucli-val ezt kapom:
physicaldrive 0:0 (box 0:bay 0, SATA, 2 TB, OK)
physicaldrive 0:0 (box 0:bay 0, SATA, 2 TB, OK)
physicaldrive 0:0 (box 0:bay 0, SATA, 2 TB, OK)
physicaldrive 0:0 (box 0:bay 0, SATA, 2 TB, OK)
physicaldrive 0:0 (box 0:bay 0, SATA, 2 TB, OK)

A show detail-hez kellene nekem azonosító, amire hivatkozhatok. De mindegyik helyen csak 0:0 szerepel. Holott vmi ilyet kellene látnom: physicaldrive 1I:0:1

Poénból kipróbáltam, hogy 0:0-ra mit ad vissza? ctrl slot=2 pd 0:0 show detail

Nem gondoltam volna, de egy disk serial-ját az 5-ből így visszakaptam. Feltételezem a listában az elsőt adta vissza.
Így 1 disk megvan, de még kellene 4. Bármi ötlet a folytatáshoz? Smartctl nem játszik, semmit nem tud kinyerni.
Számomra ez nem infó:
=== START OF INFORMATION SECTION ===
Device Model: [No Information Found]
Serial Number: [No Information Found]

( andrej_ v | 2020. 06. 09., k – 23:11 )

Szerkesztve: 2020. 06. 09., k – 23:11

Jóval egyszerűbb, hpacucli:

ctrl all show config detail

Ha nem segít, akkor smartctl -el hogyan próbálkoztál?

A P400-ból kiindulva ez elvileg G5-ös Proliant lesz ILO2-vel szerelve, remélem olyan típus. Ha a fenti nem válik be, akkor az ILO felől is meg lehet elvileg nézni a diszkeket, de lehet, hogy az csak G6+ILO2 vagy G7+ILO3-tól megy.

Egyébként ha "physicaldrive 0:0 (box 0:bay 0," -t mond a smartarray vezérlő, akkor ott valamilyen kábelezési vagy backplane probléma van, akár olyan formán is, hogy nem HP gépben van a vezérlő.

Rátapintottál a lényegre, nem HP gépben van a vezérlő. Viszont a másik Debian szervernél (szintén nem HP) az általam kiadott parancsok működnek. Igaz abban nem P400 van, hanem E200. Így megy, amit javasoltál, megvan mind az 5 serial. Egyetlen bökkenő van, hogy nem különbözőek.

A smartclt-t így néztem:
smartctl -T permissive -d sat+cciss,2 -a /dev/cciss/c0d0

Viszont a smartctl a másiknál sem megy. Ráadásul ott nem is apt-vel telepítettem, hanem letöltöttem az elérhető legfrissebbet. Emiatt kellett más megoldást keresni, és alkalmazni a cciss_vol_status -t. Csak az itt pont nem ad vissza semmi hasznosat, míg a másiknál igen.

Tegnap óta azon gondolkodom, hogy egy fw frissítés lehet helyre rántaná. Főverzióban is nagyobb az eltérés. Bár eddig még nem találtam debianhoz fw-t hozzá. (Igaz nem volt még időm sok időt beleölni.) Azokat a megoldásokat meg hagyjuk már, hogy Win alól trükközgessek! Csak ilyeneket találtam eddig.

Ahogy azt leírtam, a fw frissítés nem fog segíteni, mert a backplane miatt nem látja jól a diszkeket. Azt lehet megnézni, hogy a backplane jumperelhető-e SGPIO vagy I2C módra. Viszont mielőbb bármibe belekezdesz legalább két példányos és ellenőrzötten jó mentésed legyen.

Elrontani biztosan nem fogja a fw frissítés. Ha más nem, legalább a hibaüzenet megszűnik, hogy szükséges a frissítés. Addig míg más jobb ötlet nem merül fel úgy voltam vele nekifutok. Veszteni való nem volt.

A fenti hozzászólás óta találtam elvileg működő megoldást is:
https://support.hpe.com/hpesc/public/km/search#q=HPE%20Smart%20Array%20…

A fenti linkről ide mentem tovább:
https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_7e4ae58f0d9…
A CP017698.scexe file le lett töltve a szerverre.

Sajnos csak a napokban sikerült összehangolni, hogy én is ráérjek és a szerver közelében is legyen valaki, ha valami balul sülne el restart után.

A letöltött file kapott execute jogot, futtatuk, a bash vs dash problematikáján túltettük magunkat, majd a végén közölte, hogy 32 bites fw-rel 64 bites környezetben ő bizony nem hajlandó foglalkozni. A bosszantó az, hogy a hp oldalán a file neve mellett nem volt, hogy 32 bites. Igaz az sem, hogy 64. De 64 bites változatot meg sehol sem találok az oldalukon. Valamit nagyon benézhettem, mert kizárt dolog, hogy ne lenne 64 bites. Van ötletetek?

"Elrontani biztosan nem fogja a fw frissítés"

- nana, egyszer nekem volt egy kalandom egy adaptec kártya frissítésével, az official fw update után nem látta a lap a kártyát. Volt egy kis pánik, még jó hogy csak backup szerver volt. Pár napig eltartott, míg megoldódott. 

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Úgy érti, hogy a jogosultságprobléma elkerülése érdekében root-ként próbáld. Egyébként a hdparm -I, smartctl -a is beazonosítja a drive-ot, firmware-t. Ami miatt néha ezeknek az utasításoknak a kimenete hiányos, hogy nem minden drive azonosítja magát megfelelően, meg nem mindegyik szerepel az adott progi adatbázisában, emiatt nem ismer meg mindent.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ez csak tippelgetés vagy komolyabb szakmai érveket is tudnál felsorakoztatni? Eddig a 3rd party progik elvéreztek, ez is csak +1. Linuxon a smartctl etalonnak számít, ha az nem szedi ki az infót, akkor maradnak a gyári progik (jelen esetben a HP , ami valóban több infóval szolgált.)

Win alatt elismerem, hogy jó, de hogy Linux alatt verné a smartctl-t, azzal vitatkoznék.

tippnek szántam, nincs olyan kontrollerem, mint a kérdezőnek, és az eddigi tippek nem működtek. ingyenes program 20 mp alatt letölti és kipróbálja, hogy jó-e. nincs érvem rá, amit eddig próbált nem volt jó, ezt nem próbálta. ha a kontroller nem hajlandó elárulni, akkor meg tökmindegy mivel próbálkozik.

De sikerült, a hpacucli -val lehet a P400-ból kinyerni az infót (ctrl all show config detail). Lehet smartctl-ezni, de diszk és sokminden függő, hogy mennyire megy, HP vasban általában megy, akkor a /dev/sgX (régi kártyánál még lehet a /dev/cciss/X) eszközt érdemes használni és úgy paraméterezni a cuccot. A smart infók kiolvasása viszonylag trükkös, kell hozzá a vezérlő támogatása és persze a kliensprogramban ennek a megvalósítása.

Az alapkérdésből az derül ki, hogy nem-HP gépben és ráadásul valamilyen féligmeddig kábelezve van bent a vezérlő és a diszkek (0:0-s eszközök). Ilyet például akkor produkálnak SmartArray kártyák, ha a backplane nem az elvárt SGPIO vagy I2C-re van állítva ("szerencsére" ebben nem mindíg konzekvens minden kártyatípusuk), de még amúgy nagyjából meg is találja, a led vezérlésből csak az aktivitás szokott rendben lenni. Aki akarja az ezek tudatában és masszív tesztelést követően bevállalhatja a nem-HP gépes működést, de sosem fogja magát a kártya otthon érezni ezekben.

( klixnetwork | 2020. 06. 11., cs – 08:48 )

Miért kell gyártó specifikus RAID vezérlőt használni, tákolt és/vagy más gyártó szerverében?! Annyi alternatíva lenne... Intel, LSI, Supermicro, Adaptec (bár nagyrészt úgyis mind ugyanarra az alapra épül)

Figyi! Lehet sajnálkozni több dolgon, hogy mi lett volna ha ez, mi lett volna ha az, de nincs értelme. Én úgy vagyok vele, hogy van egy probléma, és valahogyan meg kell oldani. Hidd el nekem is könnyebb lenne azt mondani, hogy vegyél egy zsír új vasat, arra telepítek legfrissebb OS-t, aztán minden happy. Sajnos nem ismerem a szervernek az előéletét, de sokszor láttam már olyat, hogy kellett valami gyorsan, mert tűzoltás volt. Lehet akkor éppen ilyen kártya volt hamar elérhető, és azért lett az belerakva. Az már más kérdés, hogy jó magyar szokás szerint azóta is az rohad benne, és nem lett évek múlva sem véve bele egy normális.

A helyzet az, hogy hasonló esetben a tűzoltás egy dolog, de rögtön utána közölni kell, lehetőleg írásban, hogy ebben a formában ez így nem üzemeltethető és adni rá megoldási javaslatot. Egyáltalán nem biztos, hogy hanyatthomlok új gépet kell vetetni. Ami viszont biztos, hogy ha állandóan csak "jajjgyorsanmegoldjuk" van, akkor abból előbb utóbb nagy problémák lesznek és halmozottan.

El kéne oda jutni, hogy nagyjából mindenhonnan lepattannak a "jajjgyorsanoldmegnekem 1kforintért", mondjuk úgy "rövidtávon gondolkodók" próbálkozók és kvázi összezárással találkoznak. Ha mindíg lesz valaki aki ígyúgy megoldja és azt látják, igazából működik, de azt már nem látják, hogy orbitális szerencsével maradnak a felszinen, az roppant nehéz lesz. Ez nem jelenti azt, hogy a hirtelen tűzoltást normális óradíjért nem lehet megoldani, de amint problémás dolgok bukkannak fel hátrébb kell állni és szembesíteni kell a valósággal az épp tűzoltáson átesettett. Nemrég egy videjóban hallottam az angélus kifejezést: "running on borrowed time", és tényleg ilyen.

Azt sem árt szem előtt tartani, hogy egy adott igénynek van egy nagyjából reális tól-ig bekerülési költsége. Ha ezt "okosban" próbálják előadni (pl. nem vesznek szünetmentest, vagy hiszik backup nélkül jólesz, vagy a szoftverre nincs terméktámogatás stb.), akkor előbb-utóbb minimum annyi pénzt fognak kifizetni, mint amit aszitték, hogy megspórolnak. Ha szerencséjük van, akkor csak minimum...

andrej! Nem engem kell meggyőznöd. :) Minden betűjével egyetértek veled, amit leírtál. Csak amikor pl. ismerősnek csinálsz valamit szívességből az megint más, mintha egy ügyfelet kell meggyőzni. Bár hosszú távon tényleg vissza fog ütni én is azt mondom. Sőt már vannak jelei most is. Én ennél azt hittem csak pár percnyi mókolás lesz, de most már csak, mint kihívás is érdekel, mert nem hiszem el, hogy nincs rá használható megoldás. + nem volt haszontalan, mert közben olyan parancsok is előjöttek, amiket korábban nem is használtam. Ki tudja? Hátha kellenek még azok valahol a jövőben?

Itt nem tudom mire akarsz kilyukadni? Ezen infók nagy részét az lsblk-val is látom.

A felesleges sallangot kitöröltem, a lényegi rész itt van:

ata-HL-DT-ST_DVDRAM_GH22NS70...-> ../../sr0
cciss-3600508... -> ../../cciss/c0d0
cciss-3600508...-part1 -> ../../cciss/c0d0p1
cciss-3600508...-part2 -> ../../cciss/c0d0p2
cciss-3600508...-part3 -> ../../cciss/c0d0p3
dm-name-vg0-home -> ../../dm-4
dm-name-vg0-root -> ../../dm-0
dm-name-vg0-swap -> ../../dm-1
dm-name-vg0-usr -> ../../dm-2
dm-name-vg0-var -> ../../dm-3
dm-name-vg0-vz -> ../../dm-5
dm-uuid-LVM-iG22ETlgUst... -> ../../dm-4
dm-uuid-LVM-iG22ETlgUst... -> ../../dm-5
dm-uuid-LVM-iG22ETlgUst... -> ../../dm-1
dm-uuid-LVM-iG22ETlgUst... -> ../../dm-2
dm-uuid-LVM-iG22ETlgUst... -> ../../dm-3
dm-uuid-LVM-iG22ETlgUst... -> ../../dm-0
lwwn-0x600508... -> ../../cciss/c0d0
wwn-0x600508...-part1 -> ../../cciss/c0d0p1
wwn-0x600508...-part2 -> ../../cciss/c0d0p2
wwn-0x600508...-part3 -> ../../cciss/c0d0p3

Kb arra akartam kilyukadni hogy pld nálam:

lshw simán kiadva class nélkül:

su -

lshw

.....

-disk
                description: ATA Disk
                product: WDC WD10JPCX-24U
                vendor: Western Digital
                physical id: 0
                bus info: scsi@0:0.0.0
                logical name: /dev/sda
                version: 1A01
                serial: WD-WXD1E15D9KAV
                size: 931GiB (1TB)
.....

azaz a Serial : WD-WXD1E15D9KAV
Ez látszik a

ls -al /dev/disk/by-id/

......
lrwxrwxrwx 1 root root   9 jún   24 18:18 ata-WDC_WD10JPCX-24UE4T0_WD-WXD1E15D9KAV -> ../../sda
.....

Azaz a ata-WDC_WD10JPCX-24UE4T0_WD-WXD1E15D9KAV vége maga sérial:

WD-WXD1E15D9KAV

Biosban nézted?