Ez most nem retró mese, hanem a napi valóság. Az alany a CentOS, amit – a hiányosságok ismeretében – talán a 4-es vagy 5-ös verziótól kezdve használok megelégedéssel. Néhány nappal ezelőtt megjelent a 7.2.1511-es verzió, azonban ebből a „megjelenésből” sokat nem vettem észre. A „frissesség” jegyében engedélyezve van a CR tároló, emiatt a csomagok zöme már korábban frissítésre került. Lehet, hogy nem kellett volna hagyni... Persze az is előfordulhat, hogy csak később (most) csodálkoznék rá bizonyos fejleményekre. :) Mert az szépen lassan lett bőven.

Az első ilyen „fejlemény”, hogy frissült egy rakás gnome alkalmazás, többek között a gedit nevű szövegszerkesztő is. A nyavalyám csak az, hogy a friss verzió az áttervezett UI-s – szerintem – rettenet lett, amitől már sikítva menekültem Fedora alatt is. Kár, hogy ezt is jóval a frissülések után vettem csak észre... Szerencsére egy

# yum downgrade gedit

paranccsal visszarakható az előző verzió, majd egy

# yum versionlock gedit

paranccsal megakadályozható, hogy felkerüljön az újabb. Van arra esetleg valami megoldás, hogy az új verzióban visszakapjam a régi felületet? Legalább annyira, hogy legyen ablakkeretem meg menüm? :-D Egyelőre a versionlock megteszi, de nagy sebességgel nekiálltam leszokni róla. A visszakapcsolgatás amúgy sem lenne megoldás, mivel láthatóan ezt a borzalom UI az új trend... (Van azért sejtésem róla, hogy Win8+ alatt is miért utálják sokan a modern felületet. Nem azért, mert újat kell megszokni. Egyszerűen az egész egy „tapicskolásra” optimalizált UI, aminek semmi keresnivalója desktop környezetben. Nem segíti, hanem hátráltat. Itt ugyanezt érzem. De ha a szerzők szerint ez jó, akkor hajrá. Én köszönöm, de keresek mást.)

Következő fejlemény: FS-UAE. Küzdöttem egy sort, míg lett 32 bites verzióm, mivel csak azon működött a JIT-es 68K emuláció. Az meg a normális sebességhez nem árt... Na, a frissítés valamelyik része hazavágta az emulátort. Valamilyen „GL” hibára hivatkozva elhasalt induláskor. A 64 bitesre fordított verzió az megy, csak „nem siet”. A 32 bitesből viszont nem sikerült újra csomagot generálnom, emiatt megnéztem, hátha van újabb verzió belőle. Hátha az gyorsabb 64 bites verzióban is... Ezzel a próbálkozással amúgy majdnem jól jártam, de aztán egyelőre mégsem. :)

A forgatott 32 bites a 2.4.1-es verzió volt, jelenleg meg már a 2.6-os főverzió a „stabil”. Ebből először forgattam egy x86-64-es binárist, hogy egyáltalán működik-e. Kb. működik, de az UAE-s video-driver nem indul el. Az eredeti AGA-kép emulációval fut, viszont meglepően gyorsan. Mint kiderült, megérkezett végre a JIT-es 68K emuláció x86-64-re is, remek! Még gyorsabb is érzésre, mint amilyen a 32 bites előző verzióval volt:

A mérő stuff szerint a sebesség még sem olyan nagy, mint érzésre, de szerintem ezzel kibékülnék. El lehet(ne) felejteni a 32 bites küzdést? Sajnos a videokártya emulációt, és vele a használható méretű képet nem sikerült bekapcsolni. Némi próbálkozás után az viszont kiderült, hogy nincs meg a beállított méretű Z3 memória azzal a konfigurációval, amivel kellene. (Sanszos, hogy az emulált videokártya memóriája sem látszik így...) Ez egy kissé furcsa, még van mit nyomozni bőven. A normális kép hiányában sajnos használhatatlan a cucc, így kényszerből visszaálltam vele a 2.4-es verzió 64 bites változatára. Hát, nem idegbeteg embernek való a sebessége, de ezzel még majd küzdök egy sort. Persze az is megoldás lehet, hogy végre kiköltözök az emulátorból, merthogy ez még azóta sem történt meg. De az egy nagyobb feladat lesz, kell hozzá némi lelkesedés. :)

Az OS „ápdét” következő fejleménye: a JTAG kábelem. Eddig egy „régi vágású”, párhuzamos portos példányt használtam nagy megelégedettséggel. Ehhez régebben is, illetve az utolsó migrálás alatt is driver-t kellett fordítani, eddig minden rendben is volt vele. Most, a programozó szoftver a kábel inicializálásakor mindenféle látható hibaüzenet nélkül elszáll. :( Némi nyoma azért marad, dmesg:

Fantasztikus. Kezd ez így sok lenni egyszerre. :) Ráadásul mindez akkor, amikor éppen használnom is kéne! Valahol itt jutott eszembe, hogy ha már van yum history undo, akkor „visszacsinálom” a frissítés előtti állapotot, aztán darabonként felrakva az újdonságokat, csak kiderül, hogy mi rontotta el a dolgokat. Ugyan a kérdéses tranzakció meg is lett, de teljes egészében nem sikerült visszacsinálni. (Túl sok csomagot pakolásztam fel/le az FS-UAE-s próbálkozások alatt.) Viszont pár csomagot sikerült downgrade-elni, a fontosak közül a kernel / glibc / glib2 például visszakerült. A borulások viszont maradtak. Itt egy kissé elveszett a türelmem... :) Úgyhogy vissza a vissza.

Erre megoldásom most ismét nem lesz, marad a probléma megkerülése. Pár évvel ezelőtt sikerült beszerezni az eredeti USB-s JTAG hardver klónját, de ez a „klónság” az árán kívül máson nem látszik. (Vicces a szitu amúgy, mert az eredeti hardver kapcsolási rajza nem publikus. Viszont egyszer kikerült a gyártó oldalára egy doksi, amiben szerepelt. A keresési találatok között sok helyen megtalálni még a pontos linket is rá, de maga a fájl szőrén-szálán eltűnt. A „megfelelő” emberek akkor letöltötték, így neki is állhattak utángyártani. Az interfész „lelke” egy CY7C68013 típusú mikrovezérlő. A bele való firmware az eszköz csatlakoztatásakor töltődik bele, és ezt a fejlesztő környezet tartalmazza. A klón ilyen „tizenpárezer” HUF-ból megállt, a gyárit 80 fölött adták, amikor még lehetett kapni.) Ezt a programozót még CentOS6 alatt el is indítottam, de aztán maradtam a printerportos változatnál. Csak azért nem triviális az eset, mert az IDE telepítője a „gyári” driver telepítését nem tudja megcsinálni (kernel-modult szeretne forgatni, az meg nem megfelelő verzió miatt nem sikerül), emiatt az USB-s cuccok sem kerülnek a helyükre. Az USB-s JTAG kábelhez ez a driver szerencsére már nem kell, ezt a libusb-n keresztül tudja a szoftver használni, de azt meg kell oldani, hogy az interfészt működtető firmware be is töltődjön az eszköz csatlakoztatásakor. Ehhez célszerű valami „közismert” helyre másolni a firmware-(eke)t:

# cd /opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/install_script/install_drivers/linux_drivers/pcusb
# cp *.hex /lib/firmware/

(Ugyan gyárilag az /usr/share/ alá másolódnának ezek a fájlok, de a többi fw a /lib/firmware/ alatt található, így inkább oda valók.) Ezután már csak „rá kell beszélni” a rendszert, hogy töltögesse is befele őket a megfelelő eszköz csatlakoztatásakor. Ez az udev feladata, a firmware-eket tartalmazó könyvtárban ott is a megfelelő fájl xusbdfwu.rules néven. Ezt egy kissé át kell most írni, mivel manapság már egész más a szintaktika. :) Az látszik, hogy a letöltést az fxload végzi, ez szerencsére megvan valamelyik repóban. A firmware-ek elérési útja is más, szóval van mit túrni. Ez a végeredmény:

# version 0003
ATTRS{idVendor}=="03fd", ATTRS{idProduct}=="0008", MODE="666"
SUBSYSTEMS=="usb", ACTION=="add", ATTRS{idVendor}=="03fd", ATTRS{idProduct}=="0007", RUN+="/sbin/fxload -v -t fx2 -I /lib/firmware/xusbdfwu.hex -D $tempnode"
SUBSYSTEMS=="usb", ACTION=="add", ATTRS{idVendor}=="03fd", ATTRS{idProduct}=="0009", RUN+="/sbin/fxload -v -t fx2 -I /lib/firmware/xusb_xup.hex -D $tempnode"
SUBSYSTEMS=="usb", ACTION=="add", ATTRS{idVendor}=="03fd", ATTRS{idProduct}=="000d", RUN+="/sbin/fxload -v -t fx2 -I /lib/firmware/xusb_emb.hex -D $tempnode"
SUBSYSTEMS=="usb", ACTION=="add", ATTRS{idVendor}=="03fd", ATTRS{idProduct}=="000f", RUN+="/sbin/fxload -v -t fx2 -I /lib/firmware/xusb_xlp.hex -D $tempnode"
SUBSYSTEMS=="usb", ACTION=="add", ATTRS{idVendor}=="03fd", ATTRS{idProduct}=="0013", RUN+="/sbin/fxload -v -t fx2 -I /lib/firmware/xusb_xp2.hex -D $tempnode"
SUBSYSTEMS=="usb", ACTION=="add", ATTRS{idVendor}=="03fd", ATTRS{idProduct}=="0015", RUN+="/sbin/fxload -v -t fx2 -I /lib/firmware/xusb_xse.hex -D $tempnode"

Összesen 7 .hex fájl másolódott a helyére, ebben meg csak 6 fajta eszközhöz van akció, de ezen most átsiklok... :) Ebből nekem elvileg a 0007-es idProduct sorhoz tartozó xusbdfwu.hex firmware fájl kell, de a többi is elfér. Ezt a módosított fájlt az /etc/udev/rules.d könyvtárba másolva, majd csatlakoztatva az eszközt, egyből jó is lesz. (Ha a JTAG interfészen a visszajelző LED elkezd világítani, akkor a belevaló beletöltődött.) A fw letöltődése után az eszköz újracsatlakozik, most már 0008-as idProduct számmal, ami a hozzá tartozó sor miatt gyorsan meg is kapja a „mágikus” jogosultsági számát, így használhatja bármelyik felhasználó. Már csak egy lépés van hátra: a programozó szoftver indításánál ki kell szedni a régi user-space driver betöltését, utána már használható is:

Fantasztikus! :) Viszont ha már az udev körül kotorászok... A CentOS7-re áttéréskor elmaradt a nyomtatóm beállításának a véglegesítése. A megfelelő dolgok akkor telepítve lettek, csak a lézercsodának szintén kell valamilyen firmware, amit a gép tud letölteni. Ez a 6-os alatt ment automatán egyből, itt viszont eddig kézzel kellett ezt indítani. Úgyszintén udev-es feladat, a 6-os mentésem meg még mindig megvan, jöhet egy kis nyomozás...

Ott az /ect/udev/rules.d könyvtárban van pár 86-hpmud-hp_laserjet* kezdetű fájl, ebből a saját verzióm a 86-hpmud-hp_laserjet_1000.rules lesz. Ezt átmásolva a 7-es megfelelő könyvtárába viszont továbbra sincs automatikus fw-letöltés, hát persze: régi a szintaktika. A fölösleges sallangokat kioptimalizálva ez jött össze:

# hp_laserjet_1000
SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="0517", PROGRAM="/bin/sh -c 'logger -p user.info loading hp_laserjet_1000 firmware $env{BUSNUM} $env{DEVNUM}'", RUN+="/bin/sh -c '/usr/bin/hp-firmware -y3 -s$env{BUSNUM}:$env{DEVNUM} &'"

Ez így bekapcsoláskor még logol is (/var/log/messages) amellett, hogy végre be is töltődik a nyomtatóba a belevaló. Mondjuk amennyit nyomtatok, nem tört le a kezem a manuális betöltéstől, de azért van a gép, hogy helyettem dolgozzon. :) A betöltést a hp-firmware nevű util végzi, ez része a HPLIP csomagnak. Maga a firmware az /usr/share/hplip/data/firmware könyvtárban van, de hogy ez mikor került oda... Talán a HPLIP beállító szoftver (hp-setup) első futtatásakor töltötte le a megfelelő helyről. De ezzel most be is fejezem, rám fért egy kis sikerélmény már, na...

Konklúzió? Ez csak egy „sima” frissítés volt? Két nap alatt annyi szívás jött össze, amennyi talán összesen nem volt az eddigi CentOS-os „pályafutásom” alatt. Hirtelen be lett pótolva minden? :-D Ráadásul maradéktalanul nem lehetek elégedett, maradt még nyomozni való. Pont az ilyen szívások elkerülése miatt használnék „Enterprise” OS-t egy „pörgősebb” fejlesztési ütemű Linux helyett, elfogadva a hátrányokat. Persze ennyi időnként bele is férhet az ilyesmi, de a jót könnyű megszokni. Az is igaz, hogy a „nyavalyák” olyan cuccokkal jöttek elő, amiket saját magam telepítettem, de azért akkor is... Meg az, hogy ilyen jellegű verziófrissítések beeshetnek, mint ami a gnómos programokkal történik... Erősen barátkozom a MATE csomagjaival, az epel-ben van belőlük bőven. (Talán mást is zavar az új irány? :-D ) Például az eog helyett már fel is került az eom. Kár, hogy medit-et nem találtam eddig. :)

Linkek:

1. yum versionlock
2. HPLIP
3. MATE

balagesz

---

2015.12.20.