Migrálunk, migrálunk...

 ( balagesz | 2015. január 11., vasárnap - 22:14 )

Egyszer régen már meséltem egy ilyen történetet, és ami számomra is meglepő: ez már több mint három (!) éve volt. Egyrészt eszement módon megy az idő, másrészt vannak az Enterprise Linuxnak előnyei is: ezen idő tulajdonképpen eseménytelenül tellett. Méghozzá annyira, hogy a pár hónappal ezelőtti hely-elfogyásig SEMMI extra megoldandó feladatra nem emlékszem. Természetesen pár dolog azért akadt; néhány programot kézzel kellett fordítani, mivel kész csomag nem volt. Meg minden alkalommal, amikor a kernel frissült, forgatni kellett hozzá az NV drivert, a VirtualBox kernel-modulját, a CPLD/FPGA fejlesztő szoftver programozókábel-meghajtóját, talán mást nem. (Az első kettő mehetett volna a DKMS segítségével automatán is, de ezt meg nem szeretem. :) Illetve minden ilyen esetben legalább ránéztem, hogy van-e frissebb sofőr a videokártyához, ha igen, akkor abból azt raktam fel.) Szóval az elmúlt három év „unalmas egyhangúságban” tellett, minden csak egyszerűen működött. (Igen, lehet meglepő, de van ilyen is!)

A jelenlegi háttértár elmúlt 3 éves, ezalatt pörgött elég sokat. Épp itt az ideje, hogy ki legyen cserélve. (Ki mennyi időt ad általában egy HDD-nek? :) ) Az 500 GB-os példánynak sincs jelen pillanatban semmi baja, jó lesz majd „mezei” adattárnak rendszerlemez helyett. De visszafele csak nem fejlődök; az új példánynak egy 1 TB-os meghajtót néztem ki. Ez már egy Advanced Format-os meghajtó, ami a nagy többségnek valószínűleg nem újdonság, nekem még az. :) Abból a szempontból mindenképpen, hogy a particionálásnál oda kell valamennyire figyelni a határokra. Ez az odafigyelés mondjuk kimerült annyiban, hogy Fedora alatt az aktuális GParted-del készült el a felosztás, a jó öreg cfdisk-et hanyagolva.

A terv a következő lett: a két ünnepi „zabálás” között megejtem a két OS frissítését. Mármint frissebb verziókat telepítek fel egy új HDD-re, nem a régieket „ápgrédelem”. Lesz egy CentOS6 → CentOS7, meg egy Fedora20 → Fedora21 csere. Mivel új HDD-re megy a móka, a régin megmarad minden rendszerestől, ha valami probléma lesz, nem lesz miatta hajtépés. (Főszabály: legyen mindig „B” terv! :) ) Mert hogy kérdéses részek lesznek még akkor is, ha minden simán megy.

Első körben jött a Karácsony, utána a particionálás:

A két OS-nek (Fedora21 + CentOS7) két gyökérpartíció, köztük némi SWAP, a maradék meg jöhet a /home alá illetve egy „általános” tároló. Fájlrendszernek ext3 lett választva ext4 helyett. Ugyan a telepítővel majd ismét csak arra formáznám, amire akarom, ext3 marad! Az eddigi ext4-gyel ugyan nem sok problémám volt, de akadt egy furcsaság, amit nem tudok hova tenni. Egyszer régebben „megsérült” egy fájl. Ez egy sima .jpg kép volt, amit egyszer csak nem tudott a képmegjelenítő megjeleníteni. Majd a „közelmúltban” ugyanez megismétlődött egy .pdf-fel is. Mindkét fájl olyan, hogy ritkán voltak olvasva, cserébe (elvileg) semmilyen program nem írta őket. Természetesen nem tudom ráfogni tuti biztosan a fájlrendszerre, az viszont nem rémlik, hogy régebben lett volna ilyen problémám valamikor is. (A CentOS5-ön még ext3-at használtam, előtte sokáig a ReiserFS aktuális verzióját, a „régit”. De ilyesmi egyiken se rémlik...)

A telepítés(ek)ről kép nincs, sok érdekesség ott nem történt. (Talán csak annyi, hogy a CentOS7-nek csilli-villi új telepítője van, amit – természetesen – sikerült is először jól kiakasztani. :) ) Mindenesetre összejött, de a szépségek csak most jönnek. Grrr...

Első „kedvencem”: GRUB2. (A mostani mondatokat párszor átfogalmaztam. Az első verzió nagy részét ki kellett volna sípolni. :-D ) Eddig a „régi” GRUB-ot használtam, de a CentOS is áttért az új verzióra, a Fedora már régen, szóval itt nem volt választás. A GRUB1 esetén volt egy /boot partícióm, mindkét rendszer azt használta, ha valamelyik turkálni akart a boot paraméterek között, akkor a közösben meg tudta tenni. Ennek a megoldásnak – hála a GRUB2-nek – lőttek. Vajon minek kellett a GRUB2 konfigurációs állományait „begyógyítani” az OS fájlrendszerébe? Ami eddig jól működött, azt minek kellett megjavítani? (Tudom, naiv kérdések...)

De ez az egész Linux-boot történet számomra érthetetlen. Adva van ugye az MBR. Alapesetben az ebben a blokk(ok)ban levő kódot indítja el a BIOS a boot folyamat során. Az MBR-ben levő programnak az lenne a feladata, hogy az OS boot folyamatát elindítsa. Ha esetleg több OS is van az adott HDD-n, akkor ide jöhet egy menü, ahol a dear user ki tudja választani, mit szeretne tölteni. Ez a történet a GRUB1 esetén nagyjából kerek is. Ami már ott is el volt tolva (ez valójában az összes Linux betöltőnél el van...) az az, hogy szerintem az MBR-ben levő töltögető rutinnak semmi köze nem szabadna hogy legyen ahhoz, hogy az OS-t „milyen módon” (például milyen paraméterekkel) kell indítani. Neki csak annyi lenne a feladata, hogy az (éppen kiválasztott) OS saját rendszertöltőjét elindítsa. (A GRUB ezt a klasszikus chainloader sorral tudja is, szerintem a Linux-nak is ezzel kellene működnie.) Na, az OS saját rendszertöltőjének a feladata kellene legyen az, hogy milyen kernelt tölt, milyen paraméterekkel. Ehelyett meg mi van? Az MBR-be (meg most már egy csomó egyéb blokkba) kerülő kód lassan egy komplett operációs rendszer, ami „mindent akar”. Erre a GRUB2 még rá is tesz egy lapáttal az OS alatt levő konfigurációs borzalmaival. Valójában el kellene dönteni, hogy kinek mi a feladata. Értem én, hogy a GRUB2 akarja a Linux betöltését elvégezni, ebben az esetben ő lesz az OS töltőrutinja, cserébe semmi keresnivalója az MBR-ben. Meg akkor fölösleges neki más OS-t tudni tölteni. Ha meg a klasszikus „boot-menü” szerepet akarja, akkor meg semmi keresnivalója a beállításainak a majdan betöltendő OS fájlrendszerében. Ez az egész elképzelés így akkor működik jól, ha van egy Linux-od, amihez tartozik a GRUB2, aztán vagy semmi egyéb, vagy esetleg egy Windows® van még mellette (ezt lehet chainloader-elni). De amint ebből a konfigurációból ki akarsz lógni, onnantól kezdve értelmét veszti az egész. Egyébként természetesen tisztában vagyok azzal, hogy az egész töltögetést még jól megkeveri manapság az (U)EFI, ha jól sejtem a boot-menüs témát önmagában is képes lehet ellátni, de valahogy az sem az egyszerűség jegyében készült.

Nálam a telepítés úgy zajlott, hogy először felkerült a CentOS7, az szépen felpakolta a saját GRUB2-jét. Utána feltelepült a Fedora21, az szépen felülírta a saját GRUB2-jével a CentOS-ét. „Szerencsére” megtalálta a CentOS7 telepítését, így a hozzá tartozó pontokat felvette a saját menüjébe, de ahogy az a lista kinéz... :-D (Konkrétan tragikus.) Eddig ez szép és jó, viszont fogalmam sincs, hogy a későbbiekben mi fog történni. Ha a Fedora alatt kernel-csere lesz, az egyszerű, simán frissíti a (saját) GRUB2 beállításait. De mi lesz akkor, ha CentOS alatt lesz kernel-csere? Két verziót tudok elképzelni. Az egyik, hogy a CentOS újrapakolja a saját GRUB2-jét ilyenkor, ezután boot-kor mindig annak az OS-nek látom a boot-menüjét, amelyiknek frissebb a kernel-cseréje. A másik, hogy nem történik semmi, Fedora alatt majd kézzel update-elni kell a GRUB2-t, hogy a CentOS új kerneljét majd rakja be. Az egyik esetben cserélődik majd oda-vissza a menüben a sorrend (juhéj!), a másikban meg „kézzel” kell mindig matatni. Kiváló! Azért egy kis esélyt adhatok egy harmadik változatnak is: miszerint a GRUB2 valahogy rájön, hogy egy másik partíción vannak az aktuálisan feltelepített darab beállító fájljai, majd az alapján építi újra a menüt automatikusan. Azért ezzel kapcsolatban egy kissé szkeptikus vagyok, de ha ez így fog működni, akkor is meg lehet kérdezni, hogy mi a francot is kódoltak össze a GRUB2 kapcsán a programozók.

Na de elég a nyavajgásból (Tudom: csináljak jobbat... Szerintem simán lehetne mutogatni a jelenlegit egy „mit hogyan ne csináljunk” előadáson...), úgyis lesz még itt „izgalom”. A fő történet a CentOS...

Alapból nincs hálózat. Ez persze nem gond, de valahogy csinálni kellene. A szokásos parancs:

# ifup eth0
/sbin/ifup: a(z) eth0 konfigurációja nem található.

Grafikus felületen nem szokott az ilyesmi gond lenni, de én még nem tartok ott. Az ifstat nevű parancs ad egy statisztikát, ott kiderül, hogy ma a hálózati csatolót enp2s0 néven hívják:

# ifup enp2s0 
A kapcsolat sikeresen aktiválva (D-Bus aktív útvonal:
/org/freedesktop/NetworkManager/ActiveConnection/1)

No, ezek után már lehet frissíteni. Túl sok frissülés azért nem történt, de azért pár csomag akadt. Ami szükséges szokott lenni mindig, az nem más mint az EPEL repo. Például az általam favorizált Xfce is innen rakható fel a legegyszerűbben, egy yum groupinstall Xfce paranccsal. 4.10-es Xfce, szuper! Viszont meglehetősen „minimalista”, túl sok extra nincs hozzá... De ez egy „érdekes” tapasztalat az EPEL-lel. Valahogy sokkal kevesebb az elérhető csomag, mint amennyi a 6-os ághoz volt. Furcsa, egy csomó dolgot forgathatok magam? :)

A grafikus felület elindítva, de a régi problémám az egérrel itt is előjön. (A probléma dióhéjban: gagyi az egér firmware-je. Az üzemmódváltó gomb három gombot emulál, az egyiket mindig lenyomottnak mutatva. Ettől az X képes „megőrülni”.) Az install (-ok) alatt is előjött ez, átmenetileg egy másik egérrel megoldottam a telepítést. De jó lenne ha működne... Régen ezt egy Xmodmap fájl létrehozásával / feltöltésével oldottam meg, de az néha nem működött. Ekkor egy ki/bejelentkezés segített, de ha véletlenül megnyomódott a módváltó gomb, újra lehetett ki/bejelentkezni. :) (Szerencsére véletlenül nem egyszerű megnyomni, szóval ez nem volt annyira gáz.) De most meglett a „jó” megoldás! Mivel /etc/X11/xorg.conf fájl már itt sincs, ezért az /etc/X11/xorg.conf.d/910-rat.conf fájl lett létrehozva, benne a következőkkel:

Section "InputClass" 
    Identifier "R.A.T." 
    MatchProduct "R.A.T.7|R.A.T.9" 
    MatchDevicePath "/dev/input/event*" 
    Option "Buttons" "17" 
    Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 7 6 12 0 0 0 16 17" 
    Option "AutoReleaseButtons" "13 14 15" 
    Option "ZAxisMapping" "4 5 6 7" 
EndSection

És igen, végre jól működik! Természetesen az üzemmódváltó az nem, de nem hiányzik. Illetve nyomogathatom ha akarom, nem lesz belőle „baj”. :) (Fedora21 alatt is ugyanez a feladat.) A megoldás egy Linux Mint-es leírásból van, ezúton is köszönet az eredeti szerzőnek!

Ezután kell a mókolt billentyűzetkiosztásom, az sima ügy, a megoldás itt is ugyanaz mint ott volt.

Na, jöhet az „alap” dolgok felpakolása, amire szükség van. Első körben kellene a „kedvenc” Xilinx-es fejlesztőkörnyezetem, az simán telepíthető, működik is. Persze a programozó kábel meghajtója nem települ (ez a CentOS6 alatt a vége fele már működött jól), túl friss neki a kernel. Ebből van friss(ebb) verzió is, meg lehetne próbálni felpakolni azt is. De az előzőleg használt user-space driver – annak ellenére, hogy elég régi – működik még mindig, annak a használatával meg egyáltalán nem kell kernel-modult forgatni. (Ha frissül a kernel, egy munkával kevesebb.) Ugyan néha „állásában” elszáll a letöltő alkalmazás, ;) de eddig még nem volt egyéb gondom vele, működik jól. A júzert hozzáadva az lp csoporthoz, egyből tudja sima felhasználóként is használni. De ha már hozzáadás, jöhet a dialout csoporthoz is, ekkor menni fognak a soros porti dolgok is.

Mi kell még? Egyelőre még mindig nem sikerült a kiköltözés az AMIGA emulátorból, így kellene nekem az is. Na, ez már keményebb dió; az eddig használt emulátorom, az E-UAE szépen segfault-ol indulás helyett. :( Az utolsó kiadás 2007-03-27 dátummal büszkélkedik, hát, az se ma volt. Az a csoda, hogy CentOS6 alatt még működött hibátlanul... Eddig saját fordítást még nem próbáltam belőle, most lefordítani sikerült, de ugyanúgy elesik induláskor. Barátom a kereső, sikerült egy másik emulátort találni, ami – úgy tűnik – most is aktív fejlesztés alatt áll. Ez nem más, mint az FS-UAE. Színes-szagos cucc, a fordításához kell az SDL-devel, openal-soft-devel, libX*-devel, meg sok egyéb, ami már fenn van. Lefordul, működik! :) (A forráscsomagban található egy fs-uae.spec nevű fájl is, azt odaadva az rpmbuild-nak simán készül belőle csomag. A fordítás amúgy egy sima make kiadásából áll, nincs configure script, ellentétben azzal, amit a doksi állít.) De azért vannak problémák. Alapból nincs beállító felülete, erre a célra az FS-UAE Launcher lenne való, de ahhoz meg python3 kellene, olyan meg mintha nem lenne még CentOS7 alatt. De ez megoldható, Fedora alatt lehet vele generálni egy alap beállító fájlt, utána azt már tudom itt is használni. A „Launcher” úgyis akkor lenne hasznos, ha sok fajta AMIGÁt akarnék emulálni, így több fajta beállítást lehetne egyszerűen kezelni vele. De itt erre nincs szükség. Viszont van egy eddig megoldatlan problémám is: lassú. :) Az oka is megvan: x86_64-es a bináris, amit fordítottam. (Nyilván, mivel az a használt OS is. Amióta tudok, azóta x86_64-et használok, de – meglepetés – a CentOS7-ből nincs is i686-os verzió!) Ez azért „probléma”, mert a 68K emulációból x86_64-re nincs elkészítve a JIT-es verzió. Persze a lassúság relatív:

Másfélszer gyorsabb még így is egy 68040/25MHz gépnél. De ennél ez gyorsabb is lehetne... :) Valahogy kellene egy i686-os verziót fordítani belőle, lehetőleg úgy, hogy a speciálisan használt könyvtárak statikusan legyenek hozzá linkelve. Na, ez egyelőre nekem nagy falat. (Mindig csak az a tanulás... :-| ) Mindenesetre emulátorom már van, majd csak el leszek vele valahogy...

Ha már emu. Egy kis „meglepetés”: az eddigi dolgokhoz nem kellett nvidia-driver. A rendszerben levő nouveau szépen teszi a dolgát. Erről először még itt a HUP-on olvastam valamikor jó régen (most így hirtelen nem is találom a hírt...), de úgy tűnik mostanra ért be annyira, hogy a gyári sofőrt el is felejthetem. (Még egy problémával kevesebb kernel-csere esetén.) Az mondjuk igaz, hogy egy régebbi (9600GT) videokártyát használok, de ez egyelőre rendben levőnek látszik.

További desktop-célú dolgok: kell az msttcorefonts, semmi extra telepítési probléma nincs. Aztán nem ártana valami médialejátszó... Audióra a DeaDBeeF-et használom, a sima, előre lefordított, statikusan linkelt verzió jól érzi magát az /opt alatt. Videóra jöhet a VLC, illetve néha azért jól jön az mplayer is. Ezekhez a dolgokhoz jól jön egy kis segítség a CentOS wiki-ből. (A keresgélés közben találtam utalást erre a nux-repo-ra, de ha nem látom a CentOS wiki-ben, nem biztos hogy merném használni. :) Alapból mindenesetre ki van kapcsolva.) A lista alapján feltelepült egy-két okosság is, például az IcedTea web-plugin is. Ezzel a verzióval működik az a webbank, amit használok, így a kézzel installált és frissített Java-plugintől is meg sikerült szabadulni. :)

Van képem meg hangom... De a hang az „érdekes”. Egyrészt beköltözött alapból CentOS7 alá a PulseAudio. Remek... Végül is működik (miután pár éve ki kellett cserélnem miatta az EMU10K1-es hangkártyám), de hang az csak az egyik csatornán szól. Ráadásul ugyanez van Fedora alatt is! Ami viszont nincs: pavucontrol. Valahogy kimaradt... A megoldás egy CentOS-os fórum: némi töltögetés meg telepítés után van hangerőszabályzóm... Azért úgy sejtem, ha nem Xfce-t akarnék használni, hanem megmaradtam volna a „gyári” GNOME / KDE vonalon (mindkettő „új” verzió, nem a világom...), akkor talán lenne valami mixerem alapból is. De a hang továbbra is féloldalas...

Miután a hangkártya-kimenet utáni hardverhiba ki lett zárva, előszedtem a jó öreg konzolos alsamixer-t. Vicces:

Igen, az alsa megörvendeztetett egy ilyen alapbeállítással, mindkét OS alatt. Gratulálok... :) Ezt korrigálva, már van normális hang.

Mi van még? Például kellene egy levelező is. Régen a KMail-t használtam, de voltak vele problémáim. Ez viszont jó régen volt, gondoltam adok neki újra egy esélyt. Hát, nem... Nincs KMail csomag. Valahogy kimaradt... Úgyhogy maradt az eddig úgy-ahogy bevált Claws Mail, legalább a levelek migrálását el lehet felejteni. (Sima copy, aztán megy minden, mintha mise történt volna.)

Vissza van a nyomtató: a yum install hplip-gui a gyógyír a dologra. A telepítés + konfigurálás után természetesen nem működik a nyomtatóm. :) Kell hozzá firmware, amit a hp-setup nevű util (hplip része) le is töltött. Hát akkor? :) A hplip része egy HP Device Manager névre hallgató eszköz:

Ezt elindítva lesz egy Download Firmware nevű pont. Na, az pontosan azt csinálja, hogy az eszközbe tölti le a firmware-t. Miután az megtörtént, utána – érdekes módon – egyből működik a nyomtatás. A szépséghiba csak annyi, hogy ezt minden kikapcsolt állapot után meg kell tenni, automatikusan nem történik meg, mint régen. A nyomtatót viszonylag ritkán használom, eddig még nem ért annyit a dolog, hogy utánanézzek a megoldásnak.

Lassan eljutok a történetben addig, ahol most tartok... Előző telepítésnél volt még egy szkájp installálásom, de azt kukáztam, amikor a kedves MS „bekeményített” a régi verziókkal kapcsolatban. Azóta a Jitsi-t használom, egy apró anomáliától függetlenül működik szépen. (A képernyő bal felső sarkában indulás után megjelenik egy „darab ablak”, benne az éppen ott levő képdarabbal. Nem lehet vele csinálni semmit, nem is akadályoz semmiben, csak ott van. Ez valószínűleg valamilyen Xfce ficsőr lesz, hasonlót tapasztaltam már másik programnál is néha, de eddig ritkán jött elő. Ez is képes eltűnni, szóval jó kérdés, hogy mi ez...)

Ami még vissza van: sok minden. :) Egyrészt hiányzik az avr-gcc, meg az összes kisegítő dolog hozzá. (Ezek eddig megvoltak az EPEL repóban, most fordíthatom majd ismét sk.) Aztán kell majd az avra, ez sem mai gyerek. Ráadásul az utolsó verzióban volt valami problémám a feltételes forgatással, szóval az még nem is jó. Az asl-t most felraktam, hogy a jó öreg vasaimhoz tudjak fordítani. :) Meg még ezer apróság, amik majd menet közben derülnek ki. („Ja, hogy ez sincs még felrakva...?” :) ) Ó, a „legfontosabbat” el ne felejtsem: nincs a networkmanager-hez az Xfce-ben semmilye applet, így a grafikus felületről nem tudom bekapcsolni a hálózatot. :)

Valami összegzés kellene ide a végére... A csere egyáltalán nem volt fontos. A CentOS6 a FAQ szerint 2020 November 30-ig kap frissítést, szóval akár még rá is értem volna. De azért a világ 6-os megjelenése óta nem állt meg, a frissebb alap meg sosem hátrány. Nagy átlagban rendesen működik a cucc (a Fedora-ról ugyanez elmondható, de ott más a cél úgyis), ami hiányzik, az meg majd szép lassan be lesz pótolva. Ha véleményt akarnék a 7-esről mondani, akkor talán egy kicsit félkésznek érzem az egészet. (Hogy ebből az Xfce-s mivolta mennyit számít, az jó kérdés, de szerintem benne van bőven.) Egyelőre marad, a marhaságokat majd megszokom, meg beszámolok a fejleményekről. :)

2015.01.30.

Az eltelt „néhány” napban történtek miatt célszerű kiegészíteni az eddigieket, mivel az ezer apróságból néhány dolog már meg is történt. Van network-manager-applet csomagban, valószínűleg nem pontosan ezen a néven kerestem, szóval a hálózat kapcsolgatása már megy GUI-ról is. (Igen, még mindig nem csatlakozok automatán! Direkt! :) ) Aztán felkerült pár csomag, amik most nem „vadászott” RPM-ből vannak, hanem magam forgattam. Ilyen lett (most is) az SDCC, de a hozzá szükséges gputils is saját fordítás, mivel (még?) nincs belőle csomag az EPEL-ben, mint régen. Aztán kellett az avra, eddig ebből nem volt csomagom (csak simán bemásoltam a /bin-be). Na, most már van... :) Ugyanebben a témában szükséges még az AVRDUDE is, ez is forgatódott. Amit viszont továbbra is a Fedora-ból vettem kölcsön, az a GtkTerm, a 21-es csomagja simán működik némi segítséggel. (Az előző verzió esetén is előszeretettel próbálgattam a Fedora különböző verziójú csomagjait, persze több-kevesebb sikerrel, de odafigyeléssel.) Ahhoz hogy a soros portot „mezei” felhasználóként is tudja kezelni, ahhoz a dialout csoporthoz hozzá kell adni a felhasználót. Illetve szeretne valamilyen lock fájlt is létrehozni, ehhez meg a lock csoporthoz kell hozzáadni. (De ezeket Fedora21 alatt is ugyanúgy meg kell tenni. CentOS6 alatt ez a lock csoportozás nem kellett még.)

A GRUB2 továbbra sem a kedvencem... A Fedora volt másodszor telepítve, így annak a boot-loadere az „aktív”. (Ha lehet így fogalmazni...) Emiatt a CentOS grub.cfg-jét töröltem, majd a Fedora (felcsatolt) partíción levő grub.cfg fájlt „be-symlink-eltem” a CentOS-os helyére. Ma volt „itt” is egy kernel update, úgy tűnik, hogy ilyenkor tényleg csak az emlegetett fájlt szerkesztgeti az update folyamat, bekerült az új bejegyzés. (Természetesen a sor elejére, lehet kézzel továbbra is szerkesztgetni a konfigurációs fájlt, mint a GRUB1 esetében. Csak itt sokkal ocsmányabb a szintaktika, nem kifejezetten „human-readable”.)

Két megoldandó feladatot látok még, amik nem lesznek annyira egyszerűek... Az egyik: néha jól jön a Wine. Ebből van az EPEL repóban csomag, csak az nekem nem jó. :) A CentOS7 csak x86-64 architektúrára jelent meg, nincs belőle i686-os verzió. Az EPEL-es Wine is x86-64-re van fordítva, aminek az a gondja, hogy nem futtat sima x86-os programokat. Pedig pont pár régebbi program esetében van esély arra, hogy használható lenne Wine segítségével, de azokból meg nem jellemző, hogy lenne x86-64-es verzió. Most – ha mégis nagyon kellene – megoldom a feladatot Fedora alatt, ott „teljes értékű” a csomag. Mindenesetre érdemes lenne valahogy CentOS7 alatt is megoldani ezt, de nem tudom mennyi esélyem van rá. :) A másik feladat az FS-UAE ugyanúgy i686-os verziója, a két téma szinte közös, ezekkel majd futkározok pár kört még, úgy hiszem...

Linkek:

  1. R.A.T.7 egér beállítása
  2. msttcorefonts telepítés
  3. FS-UAE, AMIGA emulátor
  4. Multimédia és egyéb desktop dolgok

balagesz

---

2015.01.11.
2015.01.30. Kiegészítések
2015.02.04. Javítás

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Még csak a Grub2 panaszaidnál tartok, majd olvaslak tovább.

Filerendszer: szerintem kiszúrtál magaddal az ext3-at illetően. Ext4 jobb, gyorsabb, és ráadásul már kidobták a kernelből a régi ext3 modult, manapság az ext3-at is ugyanaz a kód intézi, mint az ext4-et.

Grub2 nem fog újratelepülni kernel csere alkalmával, csak a grubby nevű jószág fogja a grub.cfg file-t módosítani. Ez meg egy text file, nem olyan nagy gond a módosítása. Ha nem remeg meg a kezed, te is belemódosíthatsz ebbe a file-ba annak ellenére, hogy a file azzal kezdődik, ne szerkeszd. Két ok miatt írja ezt. Egyrészt, ha módosítod, bukhatod a módosításaidat, amennyiben generáltatod vele a grub.cfg-t, hiszen akkor felülíródik. Másrészt, ha hibát vétesz, nem fog boot-olni a gép.

Ezen felül nincs a Grub2 az oprendszer filerendszeréhez kötve. A /boot gondolom, önálló fs, s a Grub2 ebben van. Ezen felül lehet rendszerindítóval rendszerindítót is tölteni, csak minek.

Olvaslak tovább...


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

"Ezen felül nincs a Grub2 az oprendszer filerendszeréhez kötve."

De, mert a standard grub2-install is az oprendszer filerendszeren levo /etc/grub.d alatti cuccokat hasznalja a generalashoz (es ez nem tevesztendo ossze a grubby-val, a grub2-install a grub2 csomag sajatja).

Valamint a kollega itt epp azt ecseteli, hogy jo lenne, ha nem kellene neki kezzel mokolnia, nyilvan, mert hibalehetoseg, meg mert amugy sem tudja letiltani a kernelfrissules soran automatikusan fellovodo grub konfig update-t...
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Az automatikus konfig generálás csak egy eszköz, nem muszáj használni. Valahogy csak meg kellett csinálni, használja az oprendszer eszközeit. Ugyanakkor a boot folyamathoz semmi szükség a grub.cfg-t generáló programra.


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

A boot-hoz nyilván nem kell a grub.cfg generátor, de akkor minek van az alapból egyáltalán telepítve? Már persze ha jól értem, és a továbbiakban a grub.cfg grubby-általi közvetlen matatása megy.

A grubhoz kitalálták, hogy konfig alapján scriptek generálják a konfigot. Másfelől olykor egyszerűbb a jelenlegi grub.cfg-t felhasználva egy akármilyen scripttel megoldani ezt. A grubby lényegében ezt csinálja, s szerintem nem része a grub2-nek, csak írtak egy ilyet Fedorához.

Mondom, ha biztos vagy a dolgodban, beleírhatsz a grub.cfg-be kézzel is. Ha elszúrod, legfeljebb nem boot-ol a gép, de vagy elindítod a grub interaktív felületéről, vagy live-ról szerkeszted, kijavítod a grub.cfg-t, szóval semmiképp sem zárod ki magad. Előtte csinálj róla mentést akár ugyanabba a könyvtárba például grub.cfg.orig névvel.


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

A grubby-ból van külön csomag, szóval gyanúsan nem része alapból a GRUB2-nek. Nézegettem én a grub.cfg-t, nem félek beleírni, csak rosszul vagyok ha ránézek. :-D Mindenesetre köszi az infókat, kezd egy kicsit világosodni.

http://www.gnu.org/software/grub/manual/grub.html


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

Az ext3-mal kapcsolatos dolgok körül amúgy is van egy nagy kérdőjel, szerencsére a "kiszúrást" eddig nem érzem. :) Ha a problémámat olyan kódrészlet okozta, ami ext3 esetén nem is fut, akkor már jó lehetek. De mondom: nem tudom egyértelműen gyanúsítani az ext4-et, túl kevés hozzá az adat. (Ha az elkövetkező három évben nem lesz ilyen problémám, akkor se jelenthető ki tutira, hogy az volt... :) )

A GRUB2-vel kapcsolatban - szerintem nem lesz újdonság - kissé előítéletes vagyok. :) De a "sírás" inkább az egész Linux-boot "ökoszisztémára" vonatkozik, egy viszonylag logikus és egyszerű dolgot sikerült a végletekig elbonyolítani, minden pozitív hozadék nélkül. (Itt is aláhúzom: szerintem.)

Ha jól értem, akkor a GRUB2 a saját konfiguráció generáló kódját csak az install során egyszer használta? A későbbi módosításokat már a grubby fogja csinálni, közvetlenül belematatva a /boot/grub2/grub.cfg fájlba? Mivel nem csináltam most külön /boot partíciót, így az esetleg működhetne, hogy CentOS alatt becsatolom valahova a Fedora partícióját (ennek a GRUB2-je van ugye most használatban), majd a CentOS grub.cfg-je helyére be-symlink-elem a Fedora-féle grub.cfg fájlt. Ekkor a CentOS-féle grubby kernel frissítéskor abban fog matatni. (Kézzel nem szívesen turkálnák benne; rendkívül ocsmány a szintaxis, hogy finoman fogalmazzak.) Mondjuk előkészítésnek most ha simán csak odamásolom az F21-es grub.cfg-t a megfelelő helyre, egyéb veszély nélkül ki lehet ezt próbálni. Mindjárt meg is teszem! :)

Nekem nincs bajom az ext4-gyel, használom egy ideje, nem volt még adatvesztésem.

Fedorán biztos, hogy csak a grubby piszkálja a grub.cfg-t. Onnan tudom, mert csináltam egy PowerOFF boot menüt, ami annyit csinál, hogy azonnal kikapcsolja a gépet, s ezt nem írja felül soha.

Szerintem fog menni a symlinkes megoldásod, egyedül az a szívás, hogy az új kernelt előre teszi a menüben, így a boot sorrend aszerint változhat, melyik kernel frissült utoljára. Ugyanakkor elég gyorsan átrakható a megfelelő blokk a grub.cfg-n belül oda, ahova szeretnéd, de a set default értékkel is operálhatsz.


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

A menüelemek oda-vissza vándorlása nem tetszik, de ezt az előző verziónál is kézzel raktam mindig helyre. Ha az új elemek legalább bekerülnek, akkor már örülök.

Azt a"PowerOFF" menüelemet elkérhetném? :) (Régen volt ilyen lehetőség valamerre (talán az UHU GRUB-ja tudta?), párszor használtam.)

Ha otthon leszek, pontosan bemásolom neked, de úgy emlékszem, a halt parancs a megoldás. Már úgy értve, a grub halt parancsa.


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

Aha, jól emlékeztem, egyetlen halt utasítás az egész. Íme:

### 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 'Power OFF!' {
    halt
}

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


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

Működik, köszönöm!

(A régi, UHU-féle megoldás valami olyasmi volt, hogy talán az F12 billentyűre jött egy kérdés, hogy "Kikapcsolás? Igen/Nem". Majd a választól függött a folytatás. Nem rémlik, hogy bárhol máshol láttam volna ilyet. :) )

Azért csináltam, mert volt régebben olyan gondom, hogy hibernálás esetén elvette ugyan a tápegység a tápfeszültséget, de kb. 1 másodperc elteltével visszakapcsolt. Így jól jött a menüben a kikapcsolás, hát beleírtam. Ez nem szabálytalan leállítás, hiszen nincs felcsatolt filerendszer, disk cache, effélék.


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

Mostanában ugyan nem játszottam el, de régebben többször is sikerült kikapcsolás helyett újraindítást választani. Ugyan nyomogathatnám ilyenkor a Power gombot is, de ez csak elegánsabb. :-D

Igen, kényelmesebb. Meg amíg megtalálja az ember az asztal alatt a gépen a kikapcsoló gombot, lehet, letelik a timeout, s visszaboot-ol a gép.


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

Most meglett, egy sima yum install network-manager-applet parancs felrakta. Alapból nem települt, én meg nem biztos, hogy ilyen néven kerestem. De legalább megoldódott ez is! (A hiányosságok tényleg nem nagyok, de a maradék is szépen lassan kopik.)

A nyomtatódra a megoldás szerintem a következő:

Terminálba root-ként a

hp-setup -a

Illetve Ha szereted hogy kérdez, a

hp-setup -i

lefuttatása.

--
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

A hp-setup természetesen meg is volt, azzal telepítettem a dolgokat. Le is töltötte a hozzá tartozó firmware-t (a HP szerveréről a HDD-re). Csak az a lépés marad ki, hogy a nyomtató csatlakoztatásakor azt automatikusan át is töltse a nyomtatóba. Ez CentOS6 alatt még ment automatikusan.

Ezt a GRUB2-es témát nem nagyon értem. GRUB2-t is telepítheted külön boot partícióra. Nekem pl. a 32GB-os pendrive-on (FAT32), van egy GRUB2 telepítés, semmi köze a gépen lévő oprendszerekhez. Néha, mikor elcseszek valamit, simán erről indítok. Ilyen szempontból ez lehet a merevlemez külön boot partíciója is.

+1