Meg akartam nézni, hogy mennyivel jobban muzsikál a régi P4-es gépem egy SSD-vel, így a munkahelyről hazavittem egyet és elindultam, mint utólag kiderült, egy kalandos úton.Előre el kell mondjam, hogy a BIOS válógatós, ha SSD-kről van szó. Hazahoztam egy OCZ Agility 3 120GB-os SSD-t, de a BIOS nem látta. Ez egy ABIT IS7 alaplap a legújabb BIOS-szal és egy Intel ICH5 southbrige 2 SATA1 porttal. Amikor bebootoltam XP-be, vagy Linux-ba látszott az SSD, így biztos voltam benne, hogy nem az SSD, vagy a SATA vezérlő hibája. Egy ASUS P4P800SE alaplap látta ugyanazt az SSD-t a BIOS-ban, szóval a BIOS kellett a bűnös legyen. Így úgy döntöttem, hogy hazahozok egy tartalék Kingston V200 64GB-osat. Ezt látta a BIOS, így be tudok róla bootolni és megnézni hogy teljesít. Mindkét SSD SATA3-as.
Beraktam a gépbe az SSD-t és elővettem a GParted USB kulcsomat. Van egy Win98 is egy FAT16 partíción, lényegében csak történelmi okokból, XP egy extended partíción, és egy adat partíció adatoknak és néhány programnak, így legalább a Win98 és az XP partíciókat át kellett másolnom. A HDD 80GB-os, és majdnem teljesen tele van, így a mellett kellett döntenem, hogy az adat partíció marad a HDD-n, de ezzel nem lett volna probléma. Először átmásoltam a Win98 és XP partíciókat az SSD-re, amikor rájöttem, hogy az SSD-n nincs még MBR boot kód, így átmásoltam a teljes MRB szektort a HDD-ről az SSD-re, de így meg a GParted nem látott semmilyen partíciót az SSD-n. GParted, vagy Linux, biztos látta, hogy az extended partíció túl lóg a meghajtó méretén, és úgy döntött, hogy nem mutat semmilyen partíciót. Mindegy is, megcsináltam a paríciókat újra, lemásoltam a Win98-at és az XP-t, majd ezúttal csak a boot kód részét az MBR-nek. Egy megjegyzés, hogy a GParted MB határra igazította a partíciókat, ami miatt át akarta méretezni a FAT16 partíciót, amit meg nem tudott volna megcsinálni a nélkül, hogy FAT32-re konvetálja, ami miatt meg a DOS nem látta volna. Én ezt nem akartam, így nyomtam egy Cancel-t. Nem tudom e miatt-e, de mikor bebootoltam az SSD-ről azt mondta a gép, hogy nem találja az NTLDR-t (ebben a partíciós sémában ez a file a FAT16 partíción lakik). Nagyszerű… Bebootoltam GParted-dal megint, nyitottam egy terminált és dd-vel átmásoltam az első 20GB-ot a HDD-ről az SSD-re (dd if=/dev/sda of=/dev/sdb bs=1G count=20). Az első 20GB-ba beleesik a Win98 és XP partíciók, és az adat partíció eleje, csak hogy biztosra menjek. Ebben az esetben, mint fent említettem, GParted nem látja a partíciókat, de az fdisk igen. Elindítottam az fdisk-et, kilistáztam az aktuális partíciós listát, felírtam a kezdő és vég szektorszámokat, letöröltem az XP, adat és extended partíciókat, és létrehoztam az extended és XP partíciókat újra, de az extended paríció most már az SSD végéig ért. Igen, nyugodtan lehet törölni és létrehozni partíciókat fdisk-kel, sem adat sem boot szektor nem kerül felülírásra (egy megjegyzés, hogy ez a Linux-os fdisk parancs, nem a DOS/Windows-os). Az fdisk-et DOS kompatibilitási módra kellett állítanom, különben a partíciók nem ott kezdődtek volna, mint a törlés előtt (MB határra igazítás). Visszamentem a GParted-ba és örömmel láttam, hogy látja a két partíciót az SSD-n. Igazítottam (mozgatás) és átméreteztem az XP partíciót hogy a cluster-ek 4k határra essenek (keress rá a neten SSD-nek való partíció igazításra, hogy értsd miért csináltam) és hogy több helyem legyen. Matattam a BIOS-ban, hogy az SSD-ről bootoljak, és valószínűleg itt romlottak el a dolgok.
Nem emlékszem már a pontos lépésekre, de az SSD-ről nem indult el a rendszer, sőt olyan BSOD-dal szállt el, amit még sosem láttam (valami olyasmi, hogy Session Manager Instantiation error). Ez azt hiszem azért volt, meg az SSD-n a partíciókhoz nem ugyanazok a betűjelek voltak rendelve, mint a HDD-n és így az XP nem tudott dolgokat betölteni. Ezt az után helyre tudtam tenni, hogy az összezavartodott XP-t a HDD-n helyreraktam, olvass tovább. Úgy döntöttem megnézem a neten, ami azt jelentette, hogy visszamegyek a HDD XP-be és ekkor kezdődött a probléma. Valahogy a partíciók betűjelei megváltoztak, valószínűleg, amikor be akartam bootolni az SSD-ről és a HDD is csatlakoztatva volt, aminek az volt az eredménye, hogy egy végtelen login-logout ciklusba került a gép. Nagyszerű, nincs működő gépem. Elővettem a megbízható Nokia E90-es Communicator-t, és elkezdtem keresni. A legtöbb találat arról szólt, hogy az a aregistry beállítás, ami a userinit.exe-re mutat alapból valami vírus által olyan file-ra mutat, ami már nem létezik, így nem tudja a munkamenetet (session) elindítani a rendszer. Egy oldalon azt írták, hogy távolról csatlakozzak rá a registy-re, de mivel a felhasználómnak nem volt jelszava, így ez nem működött. Amígy egy offline registry editort kerestem (volt kéznél egy Windows 7-es notebook, amire rá tudtam kötni a HDD-t) egy nagyon ügyes megoldást találtam. A Windows 7 telepítő lemez Hibaelhárírás (? – recovery) menüpontjában lehet Parancssort futtatni, és regedit is van, már csak egy Windows 7 32 bites telepítő kellett, ami épp volt kéznél egy USB kulcson. Bebootoltam a telepítőbe, elindítottam a regedit-et, megnyitottam a releváns bejegyzést, és sajnálattal láttam, hogy az rendben van, nem ez a baj. De amikor bootolt a Win7 lemezellenőrzést végzett az adat partíció betűjelén, és letörölte a hiberfil.sys file-t. Várjunk csak… ennek nem ott kellene lennie, és ekkor jött a megvilágosulás. Megint megnyitottam a regedit-et, elmentem a HKLM\SYSTEM\MountedDevices kulcs alá, és töröltem a \DosDevices\ bejegyzéseket, és láss csodát, XP elindult, és rendesen működött. Ebből gondoltam, hogy az SSD-s XP-ben is biztos ez lehet a gond, töröltem a bejegyzéseket, kihúztam a HDD-t nehogy megint összezavarja a dolgokat (bár azt hiszem a törlés miatt ez nem történt volna meg amúgy sem) és bebootoltam az SSD XP-be. Leállítás, HDD-t visszadugtam, és még egy-két reboot után az adat partíció is azon a betűjelen volt, ahol kellett lennie.