[Hardware hiba] Megváltozott bináris állomány

Linux-security

Békésen böngészek a Firefoxszal, egyszer csak elszáll. Sebaj, előfordul az ilyesmi, indítom újra a böngészőt. Ekkor kapásból a crash ablak jön fel. Mi a fene? Nézzük a boot-oláskor back-upolt profillal. Ugyanaz. Akkor safe mode. Az is elszáll. Hűha! Ezután:

rpm -V firefox
..5......    /usr/lib64/firefox/libxul.so
A manual szerint:

       5 digest (formerly MD5 sum) differs

Egy másik gépről áthoztam ugyanezt a file-t, cmp-vel ellenőriztem, valóban eltért. Na, akkor reinstall a firefox. Ez a file már jó, helyette másik beteg:

rpm -V firefox
..5......    /usr/lib64/firefox/omni.ja

Fura. Reinstall újra a firefox-ot, mostmár jó a csomag. Már vagy 10 perce el sem romlott, a firefox is hibátlanul fut.

Na, most ez mi? Gyanakodjak a HDD-re, netán valami a tudtomon kívül cselekszik a gépemen root joggal, SELinux ellenére ott, ahol nem kellene? Vagy ilyenkor mi van?

  • 6984 megtekintés

( azbest | 2015. 02. 11., sze – 23:07 )

első körben memtest egy éjszakán át

Ma volt időm tesztelni. Valóban bizonytalankodik a RAM elérése. Következetesen a 16. bitet szúrja el, nagyjából 2300.3 MB-nál és 2300.4 MB-nál a 4 GB-ból.

El vagyok keseredve. :( Tény, hogy a gép 6 és fél éves, sokat használom naponta, gondolom, az alaplapi elkók vannak kiszáradófélben.

Gyanítom, a RAM nem szokott tönkremenni, inkább a statikus zajtartalék fogyhatott el az egyre zajosabb tápfeszültség miatt. Nincs semmi sem specifikáción kívül járatva, tehát biztosan nem ez a baj.

Sajnos nem emlékszem, teszteltem-e a RAM-ot, miután beletettem a gépbe, így azt sem tudom, hogy a memóriabővítés óta együttélek ezzel a szörnyű hibával, vagy sem.

Hirtelen nem is tudom, mi tévő legyek. Szét kellene szednem a gépet, meg kellene néznem, milyen elkókat vegyek, kérdés, kapok-e megfelelőt, aztán cserélhetem. Viszont, ha SMD kivitel, akkor nem nagyon tudom, hogyan forrasztom őket ki. Ha lábas jószág, akkor sem könnyű, mert a nyák nagy tápfelületei elvezetik a hőt, de egyszer egy másik alaplapon már sikerült.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Áram folyik rajta és melegszik, sőt ha jól tippelek akkor a 6+ éves cucc még DDR2, ahol a maiakhoz képest a feszkó is nagyobb. Gyengülnek a forrasztások és lehet hogy maga a lapka is kevésbé volt jó, mint a gyártósoron a többi, de persze a gyártási tűrésen belül volt még. Természetesen nagyon ritka a memória hiba, de előfordul.

Ha tippelnem kellene, alaplapot mondanék, de nem. A hiba csak az egyik modullal jön elő és bármelyik foglalatban, a másik modullal viszont nem.

Kivettem a hibás 2 GiB-os modult, ne tegye tönkre a filerendszeremet. Most 2 GiB maradt a gépben, éppenséggel arra elég, hogy kinézzek magamnak RAM-ot. Igen, DDR2 még. Eh, de nem hiányzott most ez...

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A ventilátorok még pörögnek, pókot is csak egyet találtam, de neki van értelme, mert megevett valami kisebb rovart, talán szúnyogot, én meg ez utóbbit nem szeretem, mert megtámad. :)

Tudom, ciki, de nincs itthon oszcilloszkópom, esetleg multiméterrel nézhetnék AC komponenst, de szerintem annyira nem mintavételez gyorsan, hogy értékelhető eredményem legyen. BIOS beállítások jók voltak, a gombelem is, bár ennek ellenére újra betöltöttem a default értékeket, aztán néhány apróságot képemre és hasonlatosságomra módosítottam, persze nem „tuning”.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Saját és kollégák bőrén is tapasztaltam már hasonló eseteket.

Régi gépterem hasonló csotrogányokkal:
- Instabillá vált gép, már telepítéskor beborult -> kondik kinyíltak, alacsony ram órajelen még működött, de inkább egy még régebbi csotrogány lett feltámasztva.
- Ram bővítés után nem indul. -> a modulok behelyezésének és slotjának sorrendje sem volt mindegy, késleltetést alacsonyra kellett állítani, ezért előbb a kisebb rammal indítva bios konfigolás, majd a nagyobbat is betéve a cpu-hoz közelebbi slotba már jó. A különböző ramok és száradó kondik is okozhatták. Bios elem felejtése áramszünetkor szintén megkövetelte a rituálé eljátszását.
- Mozgatás, szerelés után nem indul -> a száradó kondik miatt nagyon érzékeny a kontaktusra. Egyre nehezebb volt bemozgatni a ramokat, hogy még működjenek. Később néhány gépnél már nem mindegyik slot volt használható.

Fiatal gépen instabil rendszer:
- meghibásodott ram modul, újratelepítés után már korrupt fájlok sora. Meg tud hibásodni, használat közben "kopik" az is, csak jellemzően nem ez a leggyengébb láncszem a gépben. Korábban működött, de valsz gyártáskor gyengébb minőségűre sikerült chip. De akár közeli vihar okozta kisülés vagy űrből átsuhanó nagy energiájú részecske közbenjárása is kiválthatja.
- vga ram kipusztult a gyári oc-zett irodai kártyából (gigabyte irodai, de mégis oc-zott kártyák kerülendők. Az oc-n nagyobb a hangsúly).

Régi géppel szerintem nem érdemes küzdeni, ha már jelentkeznek az öregedés jelei. Állandó hibalehetőség. Azóta belátta a gépterem cseréjének szükségességét az az intézmény is, ahol küzdöttem vele. Meg az utánam beálló rendszergarázda valsz már nem töltött álmatlan éjszakákat a csodatevéssel :) (btw az nekem hobbi volt inkább, mert közelebb áll hozzám a fejlesztés, amit munkaidőben végeztem mellette)

Olvasgass az ESD mibenlétéről! Mikor a nejlonzacskó átégeti a gate szigetelését. :) Semmi füst, csak elkezd néha rosszul működni a szerkezet.
A 80-as években megjelent RCA CMOS katalógusban volt jó leírás, + elektronmikroszkópos felvétel a sérülésekről. Akkoriban a 3-400V-os védelem volt az új, most meg éppen 16000V "human body model" a menő.

Na jó, de ez a RAM nem lett kiszedve a foglalatból, a lábak potenciálban nem mentek nagyon el egymástól, ezen felül nem az interface-e ment tönkre, hanem úgy kb. egy mátrix sor vagy oszlop, vagy annak a frissítése, vagy ilyesmi. A hibás címek eléggé tipikusak, talán 0x40-enként következtek, ha jól emlékszem.

Szerk.: Arról nem is beszélve, hogy mindig úgy szerelem a gépet, hogy az egyik alkaromat a gépházon tartom, hogy azonos potenciálon legyek vele. Kis energiák ellen meg vannak Clamp-diódák ezekben az eszközökben.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ja, szóval gyenge a forint.

A CPU támogatja a DDR2-t és a DDR3-at is, de sajnos a lap csak a DDR2-t fogadja. :( Az igazsághoz hozzátartozik, hogy a DDR3-as RAM-ok sem nagyon olcsók manapság, de ennek részben tényleg árfolyam oka van.

Éppen van a gépemben 4 foglalat... Egyelőre megpróbálok garanciális ügyintézést, bár tartok tőle, hogy elhajtanak, erről mindjárt indítok egy topikot, mert úgy érzem, megéri önálló témaként felvetni. Viszont, ha nem jön be, érdekelhet, csak kérdés, hogyan, hol, mennyiért. Amúgy 800 MHz DDR2, 4 GiB, 2x2 GiB vagy 4x1 GiB formában bír érdekelni. A 4x1 GiB hátránya, hogy nem lehet mellé tenni további RAM-ot, de egyelőre 4 GiB-tal vígan elvagyok, még egy virtuális gép is elketyeg benne szükség esetén.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Már kétszer (1x laptop, 1x meg szerver alatt) történt velem olyan, hogy memória hiba fájl rendszer korrupciót okozott. Azóta hiába a HDD az első gondolatom, elég előre került a memória teszt a tennivalók listáján...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

igen, a linux már 2004-ben is képes volt read-only executable fileokat menetrendszerűen elkorruptolni a filerendszeren, ekkor vettem mac-et. öröm látni hogy e téren még ma is tisztelik a hagyományokat!

(aztán megtudtam hogy linuzosz torvaldosz szerint a hfs+ egy borzalmas fs, ooookay i guess:-)

Memóriahibánál ahova beolvassa a fájlt a memóriába, elég ott hibás bitre futni, látszólag máris hibás lesz a fájl, de az is előfordulhat, hogy a diszkterület, ahol a fájl helyet foglal, az sérül OS-től függetlenül.
Egyébként ha hiszed, ha nem, a "w" bitek nélküli jogosultság mellett simán írható a fáj megfelelő jogosultsággal bíró processzek számára :-P Ennek az ellenkezője is igaz: lehet "w" mindenkinek, mégsem fogod tudni uid=0 processzel sem írni az adott fájlt, hiába a rw mount - és még selinux sem kell hozzá. :-P

Mivel a sérültnek tűnő fájlt csak helyben és csak egyszer(!), a fs cache ürítése nélkül ellenőrizte a kolléga, így nem zárható ki az sem, hogy a memóriából olvasott mást, mint ami a diszken volt.

Ha AMD CPU -> benne van az MMU. Találkoztam már egy csoda alaplappal, ami a cpu hűtés legkisebb sérülését totál memóriahibával honorálta. Valószínűleg a cpu rosszul volt a burkolathoz forrasztva, és pont az mmu vagy cache rész érzékenyebb lett a helyi túlmelegedésre. A cpu kihúz, bedug, újraken - és a hiba megszűnt a következő szállításig.
A legcsúnyább esetem - amikor alaplapokat, cpukat és hűtéseket cserélgettem n dimenziós mátrixban - és minden elromlott! A megoldás a memtest cseréje lett. :)

Mielőtt hülyét csinálok magamból a boltban, megnézem ezt a RAM modult másik gépben is. Úgy kiderül, hogy van-e köze alaplaphoz, CPU hűtéshez, vagy vándorol a hiba teljesen más környezetbe is. Ha igen, az engem erősen meg fog győzni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( eax | 2015. 02. 11., sze – 23:11 )

Hat ez ennyibol meg barmi lehet. A nyilvanvaloakon (nezz logot meg halozati forgalmat) tul erdemes megnezni, hogy pontosan mi valtozott. Az omni.ja egy sima jar (zip) file, a .so-ra meg ott a bindiff.

( locsemege v | 2015. 02. 14., szo – 17:59 )

Egyébként ez az, úgy látom, SMD elkók vannak benne.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nekem hiányosak az ismereteim, de szerintem nem a felületszereltségre gondolsz.
Persze biztosan vannak smd kondik is rajta, de valószínűleg a szilárd elektrolitos fémsapkásokra gondolsz a sima elektrolitosok használata helyett.

Úgy hallottam, hogy a szilárdak előnye a folyadékoshoz képest, hogy nem szárad ki. Tovább maradnak a gyári közeli állapotban a paraméterei, mint a folyadékosnak. A szilárdaknak eleve valamivel rosszabbak a paraméterei, de azt tartósan tudják tartani. Idővel persze az is el tud romlani.

Valóban SMD-re gondoltam, de szétszedve a gépet, noha nem szedtem ki az alaplapot, nem néztem meg a „forrasztási” oldalt, más jelekből arra következtetek, hogy lábas jószágok ezek. Ugyanakkor ez az alaplap abban az időben készült, amikor a vásárlóknak kezdett elegük lenni az elkók kiszáradása miatt hamar elhullott alaplapokból, s megjelentek a nagy élettartamú elkókkal az alaplapok. Ahogy írod is, ezen épp ilyenek vannak.

Ami még szimpatikus, hogy a CPU tápját előállító tápegység kapcsolási frekvenciája igen nagy lehet, mert elég kis kapacitású kondenzátorok vannak benne, nevezetese 820 µF-osok. Ez nagyjából 100 A terhelőáramhoz elég szép. Jó, gondolom, sokfázisú vezérlés, mindig folyik befelé is áram, de akkor is.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2015. 02. 15., v – 00:27 )

A kevés memóriával például ez a baj:

Feb 15 00:19:00 gépem kernel: PM: Creating hibernation image:
Feb 15 00:19:00 gépem kernel: PM: Need to copy 269068 pages
Feb 15 00:19:00 gépem kernel: PM: Normal pages needed: 269068 + 1024, available pages: 254993
Feb 15 00:19:00 gépem kernel: PM: Not enough free memory
Feb 15 00:19:00 gépem kernel: PM: Error -12 creating hibernation image

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Noha tudjuk, hogy most a RAM okozta a problémát, a prelink érdekel. Az RTFM típusú beszólás kevésbé. Inkább arra kérlek, röviden foglald össze magyarul, mit is csinál a prelink, miért nyúl hozzá a binárisokhoz, és ez hogyan egyeztethető össze a csomag konzisztencia ellenőrzésével, úgy mint hash. Tényleg nem tudom és érdekel, ezért kérdezem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A mit és hogyan csinál a prelink-re vársz nem rtm/lmgfy választ? A dinamikusan linkelt binárisokat/shared libeket átnézi, és átvakarja őket úgy, hogy a bináris indításakor a shared libek relokálására lehetőleg ne legyen szükség, ami az indulási időt csökkenti.

Ez tök jó, csak ha változik a bináris, akkor hogyan lehet megkülönböztetni ezt az esetet attól, ha valami kórság miatt változott a bináris és ezzel együtt a hash? Mert a csomagkezelő képes ezt ellenőrizni, s te sem véletlenül említetted a csomagkezelő által adott hibára a prelink lehetőségét.

Tehát az a gondom a prelinkkel, hogy elveszítjük a csomagkezelőben tárolt hash, csomagok konzisztenciája vizsgálatának előnyét.

Vagy valamit nem tudok, és erre is van megoldás.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem, nem vszíted el - szerintem a csomagkezelő van olyan intelligens, hogy ránéz a prelink adatbázisára, és ha az érintett bináris ott szerepel, akkor a prelink által módosított fájlról ott eltárolt hash-t használja (a prelinknek is kell a módosított fájlról hash, hogyha vissza alarja csinálni a módosítást, biztos lehessen abban, hogy a fájl a prelinkelés óta nem változott meg), de ez csak tipp, nem mélyedtem el ennyire a működésben.

( locsemege v | 2015. 02. 15., v – 19:20 )

Az a helyzet, hogy tényleg a RAM a beteg. Másik gépbe téve a modult ugyanaz a probléma, ugyanazon a címen. Ugyanakkor megtaláltam a memória számláját, garancialevelét.

Picit offolok, mert a másik gépen a memóriateszt Grub2-vel történő indítása elsőre azt eredményezte, hogy kevés low memóriára panaszkodott. Némi utánaolvasást követően ezt írtam a grub.cfg-be:

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

menuentry 'Memtest86+' {
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos5'
        knetbsd /elf-memtest86+-5.01
}

menuentry 'Power OFF!' {
        halt
}

### END /etc/grub.d/40_custom ###

A kikapcsolás nem tartozik szorosan hozzá, de hasznos lehet, így ezt is ideírtam. A set root meg az elérési út értelemszerűen. Tudom, lehetne kerestetni is, de ezt szerintem be lehet drótozni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE