Főleg céges környezet esetén örök érvényű mondás az “If it ain’t broke don’t fix it!”, vagyis ha valami működik, akkor azt nem kell megjavítani, ami a gyakorlatban inkább azt jelenti, hogy ahhoz nem nyúlunk hozzá – viszont ez egy idő után komoly problémákhoz tud vezetni, főleg a szoftverek fejlődésével.

Nemrég egy olyan esetbe futottam bele, ami nem egy mindennapos dolog, így szerintem biztosan lesznek, akik szintén érdekesnek fogják találni.

A környezet, ami miatt itt mindenképp Mac OS X 10.5.8 kellett

A problémát ebben az esetben az adta, hogy a kialakított szoftveres környezet a különböző alkalmazások és a hozzájuk tartozó bővítmények és kiegészítők miatt Mac OS X 10.5.8-at igényelt, és mivel több bővítmény és kiegészítő fejlesztője már megszűnt, így ezeket konkrétan nem is lehet a 10.5.8-nál újabb rendszeren használni, mert nem megfelelően, vagy pedig egyáltalán nem működnek. Korábban is minden egyes újabb Mac OS X verzió esetén frissítenie kellett ezeket a fejlesztőiknek. Ez tehát a probléma szoftveres oldala.

A dolog másik részét a hardver adja. A Mac OS X 10.5.8 nem telepíthető fel olyan Mac-re, amelyik már eleve legalább Mac OS X 10.6-tal érkezett, ezek pedig a Late 2009-es (és újabb) gépek, tehát idén gyakorlatilag már legalább 15 éves gépekkel kell számolnunk a 10.5-öt még támogató, Mid 2009-es és régebbi modellek miatt. A korukból adódóan ezeknél típustól függően elfordulhat például tápegység hiba, grafikus vezérlő hiba, és igazából bármi egyéb, alaplapi probléma is. Új alkatrészeket találni ezekhez már gyakorlatilag nem lehet, egy másik gépből kiszedett, bontott (vagy felújított) alkatrész pedig szintén kérdéses, meddig fog működni, pláne ismeretlen előélettel és használati idővel. Egy másik, használt gép beszerzése is csak időleges megoldást jelent, hiszen az is ugyanolyan idős, így bármikor bármi előjöhet rajta. Ezért az ilyen gépek javítása már nem tekinthető költséghatékonynak. No persze mint tudjuk, mint minden, ez is relatív…

Ebben az esetben az ügyfél több, 2008-as és régebbi évjáratú iMac-et használ(t), amelyek közül egymás után adták fel az egyes gépek, előjött táphiba, grafikus chip / grafikus kártya hiba, és alaplapi gond is. Egyes gépek egyszerűen használat nélkül, mindössze állásukban döntöttek úgy, hogy nem kapcsolnak be többet, de volt olyan is, hogy konkrétan mindössze csak az egyik asztalról egy másikra átrakva, vagy költözés közben, autóban a hátsó ülésen való szállítás után intettek búcsút, pedig semmi fizikai sérülés nem érte őket közben. Pár gép átmenetileg működőképessé volt tehető a másik gépekből kiszerelt alkatrészekkel, de ez is csak időleges megoldást jelentett.

Végül eljutottunk odáig, amikor gyakorlatilag az utolsó, még működő gép grafikus chip hibát produkált, ami ebben az esetben azt jelentette, hogy a kijelzett képen különböző grafikai hibák jelentek meg, például szükségtelen, zöld pixeles foltok egyes színeknél, ami legkevésbé sem hasznos például Photoshop vagy más képszerkesztők használata közben. Másik kijelzővel kipróbálva még rosszabb volt a helyzet, szürke csíkok jelentek meg stb., és mivel a grafikus chip a hiba oka, így persze külső kijelzővel is ugyanúgy megjelenne ez a hiba. Emellett egyébként a saját kijelzőjének a CCFL háttérvilágításából a felső rész már nem is működött, az alsó fényereje pedig jelentősen csökkent, így már ez is a gép csereérettségét mutatta. Ráadásul az érintett iMac-ben nem külön MXM-kártyán van a grafikus chip (GPU), így azt nem lehet egyszerűen kicserélni benne, csak forrasztással – de még ha lehetne is egyszerűen cserélni, a beszerelt alkatrész életkora és a chip típusa miatt ugyanúgy előjön majd a hiba előbb vagy utóbb.

A lehetséges megoldás: virtuális gép

A fentieket elolvasva már biztosan többeknek eszébe jutott, hogy hát egyszerűen kell venni egy bármilyen, újabb gépet, arra pedig fel kell telepíteni a Mac OS X 10.5.8-at egy virtuális gépbe (virtual machine, VM), majd abba a Költöztető Asszisztens segítségével átvinni a működő 10.5.8-ról az adatokat, alkalmazásokat és beállításokat, és minden jó lesz!

No persze ha ez ennyire egyszerű lett volna, akkor itt véget is ért volna a cikk, ami aztán legkevésbé sem lett volna érdekes.

A csavart az adja a történetben, hogy a legtöbb virtuális gép már egyszerűen nem támogatja a sima 10.5.x telepítését, hanem a Mac OS X 10.5 Server kellene nekik, amihez persze nem lehet mostanában csak úgy hozzájutni. De tételezzük fel, hogy sikerült beszerezni a telepítőt, és az nem valami egzotikus formátumban van, hanem az adott virtuális gép által is támogatott, általában DMG vagy ISO fájlként.

Lássuk most a lehetséges opciókat a virtuális géphez, mert ezekből van több is, jelen esetben ezeket próbáltam ki:

• Parallels
• VMWare Fusion
• VirtualBox

Parallels • Némileg kényelmetlenné teszi a dolgot, hogy regisztráció, vagy például Google vagy Apple fiókkal való belépés nélkül még a próbaverziót sem lehet használni, hogy egyáltalán kideríthető legyen, elindul-e benne a sima Mac OS X 10.5 telepítő (tehát nem a Server verzió). Az ára sem túl barátságos, mert vagy éves szinten 99,99 euró az előfizetéses verziója, vagy pedig 129,99 euró a rendes megvásárlás, ez utóbbi viszont csak az adott főverziót tartalmazza, ez jelen esetben a 19.x, és utána a 20.x-et már nem kapjuk meg, míg az előfizetéses modellben mindig a legújabb verziót használhatjuk.

VMWare Fusion • A VMWare Fusion Player ingyenesen is használható, de ez is regisztrációt igényel, a Pro verzió pedig a fenti esetben semmi olyan pluszt nem adott volna, ami miatt muszáj lenne azt választani. Felhasználói szempontból pozitív, hogy a Player ingyenes, bár mivel itt üzleti felhasználás lenne, így ez valamelyest kérdésessé teszi a dolgot.

VirtualBox • Ez is ingyenes, és végül ez lett a nyerő, de persze alapból nem működött csak úgy, elég sok dolgot kellett állítani, mire sikerült a dolog, és még ennek ellenére is sokat kellett küzdeni vele, amiről részletesen alább.

Miért a VirtualBox lett végül a befutó?

A dolog oka prózai: a Parallels és a VMWare vagy eleve a Server verziót igényelte, vagy pedig még azt használva is egyszerűen kernel panic-kal leállt a telepítő már a bootolás során. Ez vagy kimerült abban, hogy verbose módban megállt a folyamat már a legelején, vagy pedig grafikusan indult, és pörgött az alma logó alatt körbe-körbe a folyamatjelző, de a végén áthúzott kört dobott – bármilyen beállítás mellett.

Szintén kényelmetlen volt, hogy az egyes VM-ek csak adott formátumú lemezképeket támogatnak, így az egyiknél például a DMG nem volt megfelelő, a másiknál a Server verzió csak .toast formátumban volt elérhető, így azt előbb át kellett konvertálni DMG-be, vagy találni belőle egy ISO-t.

A VirtualBox piszkálása, hogy egyáltalán működjön

Az első, és legfontosabb lépés az volt, hogy a virtuális gép létrehozása után át kellett állítani, hogy milyen processzor látszódjon a virtuális gépben futó Mac OS X számára. Ehhez Terminalban az alábbi parancsot kellett lefuttatni:

/Applications/VirtualBox.app/Contents/MacOS/VBoxManage modifyvm Leopard --cpu-profile 'Intel Core2 T7600 2.33GHz'

Ebben a parancsban a Leopard a létrehozott virtuális gép neve, ha más nevet adtunk meg neki, akkor értelemszerűen azt kell beírni helyette. Itt igazából lehet próbálkozni más processzortípusokkal is, de az előbbi parancsban találhatóval rögtön működött a dolog, a virtuális optikai meghajtóba felcsatolva a telepítő DMG-t, és elindítva a VM-et, már bootolt is a telepítő, és gond nélkül végigment a telepítés.

Nagyon fontos, hogy ezek után semmit ne állítsunk a processzor esetén a virtuális gép beállításaiban a VirtualBoxban, mert az felülírja a processzortípust is, és akkor nem fog betölteni a rendszer, csak ha visszaírjuk azt a fenti paranccsal.

Igen ám, de az egyetlen képernyőfelbontás, ami ezután elérhető volt, az 1024×768, ami nem igazán ideális, ha az eredeti gép egyébként egy 20″-os iMac, ráadásul épp grafikai vagy kiadványszerkesztő appokat szeretnénk használni:

Ugyanis hiába tesszük teljes képernyősre a virtuális gép ablakát, a felbontása marad 1024×768, tehát középen, kicsiben látszik majd a megjelenített kép, nem lesz belőle az új host gép által már egyébként támogatott felbontás. Ebben az esetben egy 16″-os, retina kijelzős gépen így mutat 100%-os méretben mindez teljes képernyőre állítva:

Felskálázni persze lehet, de az csak felnagyítja a megjelenített képet, a felbontás marad, így még a minőség is romlik, ez itt a 275%-os méret (a cikk egyéb képei 200%-os méretre állítva készültek):

Ez csak a probléma egyik része volt. Ott volt ugyanis egy másik, sokkal égetőbb kérdés: egy az egyben át kellett vinni az adott felhasználó minden adatát, alkalmazását, beállításait a virtuális gépbe. Azt gondolnánk, hogy ez nagyon egyszerű: mindössze csatlakoztatni kell USB-n keresztül a költöztetni kívánt gépből kiszedett, jelen esetben SSD-t a host gépen keresztül a virtuális géphez, és majd a Költöztető Asszisztens mindent megold.

Sajnos a gyakorlatban ez nem ment ilyen könnyen: a felcsatolási kísérlet minden esetben hibát dobott, amit elvileg azzal lehetett orvosolni, ha maga a VirtualBox már eleve rootként van elindítva – amire remélhetőleg többen is rögtön felszisszennek. Ez egyrészt nem lett volna kifejezetten életszerű és célszerű, még ha teljesen figyelmen kívül is hagyjuk az esetlegesen ebből adódó problémákat, másrészt sikerült olyasmibe belefutni, hogy bár a virtuális gép felcsatolta az SSD-t, de egyúttal megállt a billentyűzet és az egér, és ezt semmilyen beállítással próbálkozva sem sikerült valamiért kicselezni.

A host gépről drag-and-drop módszerrel nem lehetett semmit sem áthúzni a virtuális gépbe (ami egyébként sem oldotta volna meg az egy az egyben való költöztetés kérdését), és a host gépről megosztott meghajtóként sem volt hajlandó valamiért látni a VM a kiindulási gép SSD-jét.

Ezeket a problémákat első körben elvileg a VirtualBox Guest Additions-szel lehetne orvosolni – viszont ennek sajnos egyik verziója sem támogatja a Mac OS X 10.7 előtti rendszereket (a 6.0.0-s előtti Guest Additions-ben meg eleve nincs is Mac-es telepítő), így az a 10.5.8-cal sem volt opció:

Erre a problémára később lett egy kifejezetten egyszerű megoldás, de ameddig ez nem volt meg, mást kellett kitalálni.

Time Machine mentés hálózati meghajtóra

Az 1024×768-as felbontás kérdését egyelőre figyelmen kívül hagyva az első és legfontosabb az volt, hogy valahogy egyáltalán átkerüljön minden adat, alkalmazás és pláne beállítás a virtuális gépbe, így akkor néztünk egy Time Machine mentést, amit egy hálózati meghajtóra kellett megtenni, hiszen USB-n nem volt hajlandó értelmes módon felcsatolni egy meghajtót sem a VM.

Itt következett a következő csavar: rávenni az eredeti gépet, hogy hajlandó legyen a szervizben lévő NAS-ra menteni. Némi masszírozás után végre ez elindult, viszont mivel majdnem 200GB-nyi adatról van szó, így nyilván eltartott egy ideig.

Ahhoz, hogy a mentés visszaállítható legyen, a virtuális gépet frissíteni kellett a Mac OS X 10.5 legutolsó változatára, illetve fel kellett tenni minden egyéb, elérhető frissítést is, hogy azok miatt ne legyen gond, hiszen a forrás gép is frissítve volt. Ez egyébként igazán pozitív, hogy az Apple még az ilyen régi rendszerekhez is odaadja az azokra elérhető frissítéseket. (Ha ugyanezt mondjuk egy Windows-zal kellett volna megpróbálni, ott régebbi rendszereken általában már nincs is lehetőség frissítéseket letölteni a Windows Update-ről.)

Ezt követően rá kellett venni a virtuális gépet, hogy egyáltalán lássa a NAS-t és azon a Time Machine-t, majd pedig ez megjelenjen a Költöztető Asszisztens alatt is, mint lehetséges forrás – és mindezt egy olyan felhasználó alól kellett elindítani, amelyik nem létezett az eredeti gépen, mert ilyen régi rendszeren nem volt hajlandó az aktuálisan bejelentkezett felhasználót egyszerűen csak felülírni. (Ha nem sikerült volna sem a Time Machine mentés, sem annak a visszaállítása a NAS használatával, akkor még mindig ott lett volna az opció kölcsönkérni valakitől egy bármilyen generációs Time Capsule-t, amivel mintegy “kötelező” lett volna mennie.)

A visszaállításnál ugyan be volt állítva, hogy mindent állítson vissza, de valamiért az adott felhasználó saját mappáját mégsem írta felül egy az egyben, hiányoztak például az Asztal, Dokumentumok, Letöltések mappák tartalmai, így azokat manuálisan kellett visszamásolni, ami újabb időt vett igénybe.

A felbontás nagyobbra állítása

Mivel az 1024×768-as felbontás semmi esetben sem volt használható opció, így ezzel mindenképpen kellett kezdeni valamit. Azt gondolnánk, hogy a VirtualBox Guest Additions majd mindent megold, de ahhoz ugye Mac OS X 10.7 is kellett. A megoldás végül sokkal egyszerűbb lett, de erről majd később, hiszen időben is később sikerült rájönni, hogyan lehet kicselezni.

Lemásolva a már elkészített, és a felhasználó adatait és beállításait is tartalmazó virtuális gépet, adtam egy próbát annak, hogy frissítsük 10.7-re a meglévő rendszert. A 10.7-es telepítő appnak viszont már legalább 10.6 kell, hogy egyáltalán elinduljon, és így az egyébként futó rendszerből lehessen a telepítést indítani, ezért előbb akkor adni kellett neki egy 10.6-ot, majd miután az települt, még jöttek a frissítések.

Az összes frissítést tartalmazó 10.6-on pedig már el is indult a 10.7 telepítője, és miután frissült a rendszer, már a VirtualBox Guest Additions is telepíthető volt. No persze itt derült ki, hogy igazából hiába: az elérhető felbontás ugyanis valamiért továbbra is csak az 1024×768 volt, semmi egyéb. Ráadásul ez eleve nem is lett volna megoldás még akkor sem, ha segít a felbontáson, mert több telepített alkalmazás sem indult el a 10.7-tel, mert azokat is frissíteni kellett volna, ez pedig nem volt opció.

Ekkor sikerült megtalálni az alábbi parancsot, ami igazából arcpirítóan egyszerűen vágja ketté ezt a gordiuszi csomót:

VBoxManage setextradata "Leopard" "VBoxInternal2/EfiGraphicsResolution" "1920x1080"

Itt hozzátenném, hogy persze kínosan ügyelni kell arra, hogy az idézőjelek véletlenül se a “szebbre” formázottak legyenek, hanem az eredeti (magyar kiosztással ⇧2), formázatlan változat, illetve szintén formázottá szokott kerülni a felbontási értékek közötti x is, úgy viszont nem lesz megfelelő a parancs. (Ezt egyébként manuálisan is át lehet írni a virtuális gép beállításait tartalmazó fájlban.)

Ezt értelemszerűen leállított virtuális gép esetén adjuk csak ki, majd utána újból elindítva azt a felbontás már a bootolás során is azonnal a megadott értéken lesz – és utána a Mac OS X beállításaiban is csak ez az egy felbontás fog látszani, tehát dinamikusan nem tudjuk menet közben változtatni, de ebben az esetben nem is volt erre szükség.

Nincs Quartz Extreme – 128MB VRAM-nál több beállítása

128MB VRAM (video RAM) elvileg elég lehet majd a virtuális gépnek, de ha a fizikai gép egyébként annál többel rendelkezik, akkor azt érdemesebb megemelni. Ez viszont nem segít majd azon, hogy sajnos a Quartz Extreme támogatás hiányában a grafikus felület gyorsítás nélküli, így akadozni fog. Ezen a jelek szerint semmit sem segít, ha a VitualBoxban a grafikus beállításokat módosítjuk, vagy bekapcsoljuk a 3D gyorsítás támogatását. Így nem biztos, hogy van érdemi haszna, de ártani nem árthat, ha a VRAM-ot az alapból elérhető, maximum 128MB-ról megemeljük, amit az alábbi paranccsal tehetünk meg, 256MB-ig:

VBoxManage modifyvm "Leopard" --vram 256

Ezután egyébként a virtuális gép beállításaiban is már 256-ig látszódik majd a VRAM csúszkája, de utána ezt már nem szükséges ott átállítani.

Összegezve

A fenti eset sajnos jól vázolja azt, hogy mennyire fontos, hogy naprakészen tartsuk az általunk használt környezetet, mert különben előállhat olyan helyzet, amikor már nincs se előre, se hátra, ha régi gép javíthatatlan, új gépre váltani pedig a szoftveres környezetünk miatt nem kifejezetten opció, mert például megszűnt az általunk használt, egyébként fizetős és így regisztrációt igénylő kiegészítő fejlesztője, és emiatt persze a mögöttes szerverek is, tehát legálisan már aktiválni sem tudnánk a megvásárolt szoftvereinket és azok esetleges bővítményeit.

Itt most szerencsére sikerült egyfajta áthidaló megoldást találni, de a grafikus gyorsítás hiánya nem eredményez jó felhasználói élményt, a virtualizálásból pedig további, jelenleg még nem ismert, egyéb problémák is előállhatnak.