Hozzámkerült még jó pár éve egy VAXStation2000. A station a nevében jelzi, hogy ezt a DEC a munkaállomás piacra tervezte, kisebb, halkabb gépet próbáltak összerakni. Több kiépítésben is létezett, szerény személyemhez 6MB RAM-al egy RD54 MFM diszkkes modell került. Oprendszer tekintetében OpenVMS (akkor még simán VMS), ULTRIX (erről később) és NetBSD támogatott. Sajnos grafikus konzol nélküli, így kénytelen voltam első körben konzol kábelt gyártani neki. Szerencsére erről van leírás,

• vagy szétszedés után az alaplapon átjumpereljük és letiltjuk a grafikus módot, ezáltal a printer porton rátudunk kötni egy konzolt.
• Vagy, ami számomra barátságosabb megoldás volt, egyszerűen a DB9-es soros kábel csatlakozóján a 8-9-es kimeneteket összekötjük, jelezve, hogy ide kérjük a konzol kimenetét. 🙂

Miután a kábel elkészült indult is a gép:

Mi-micsoda? Az első sor mondja meg a procit (KA410-A) utána a PROM verzió (V1.2), majd elkezdi az eszközöket tesztelni. Ami fontos:

• ? – ha hibás az eszköz
• _ – ha nincs ilyen eszközünk
• * – sérült a ROM eszköz része
• . – minden ok

Majd  alá kiírja a hibákat. Ezt jelentik a betűk és számok a teszt során:[1]

Tehát ez alapján: nincs 8-plane grafikus eszközünk (2-plane, monochrome az integrált) és a két fenntartott értelemszerűen hiányzik. Ezenfelül kapunk egy figyelmeztető kódot az

• órára: 0040 0000.0005, az óra nincs beállítva 🙂
• serial line controller: 0080 0000.4001 nincs bedugva se egér se billentyűzet, valószínűleg az a baja
• SCSI-A: nincs bedugva semmilyen SCSI eszköz
• hálózat: nincs bedugva kábel

Úgy néz ki, hogy akkor semmi komoly baja nincsen. Ez megnyugtató. Lássunk egy részletesebb HW infót:

• ? – kisebb hiba
• ?? -nagyobb hiba
• * – valami gáz van a ROM azon részével ami kezelné

 

ULTRIX

Önmagam szórakoztatására egy kis wikipedia túrás, kis történelem, ha nem érdekel lehet ugrani tovább nyugodtan.

A DEC gépek számára a UNIX nem volt újdonság, hiszen az első UNIX-ot is egy PDP7-en használták. Alapvető környezete a UNIX-nak a PDP11 volt akkoriban. Ezt V7M-nek hívták vagy (V7M11) és a DEC UNIX csoportja az UEG (Unix Engineering Group) fejlesztette. Ellenben valamin jól összekapott a Bell Labs és a DEC a 70-es években, így nem voltak hajlandók 77-ben megjelenő új VAX architektúrájú gépeket venni, amúgyis benne voltak egy Interdata 8/32-re való portolásban. DEC így máshol próbálkozott a Bell Labs berkein belül és talált egy csoportot amelyik nem zárkózott el a portolási feladattól.   Akkoriban még nem volt a portabilitás elsődleges szempont (nagyjából az Interdata 7/32-re való portoláskor vált szemponttá), így nem volt triviális a portolás, amivel 1979 júniusára készültek el. Ez lett a UNIX/32V.

Ez egy nem túl jóra sikeredett port lett, bár alapvetően fontos lépcsőfoka volt. Pont a VAX újdonságának számító virtuális memória kezelését nem tudta kihasználni. Úgyhogy a Berkleys hallgatók újraírták a kernelt, ebből lett a 3BSD, másnéven Virtual VAX/UNIX vagy VMUNIX (Virtual Memory UNIX). Érdekesség, hogy a BSD kernelt elég sokáig, a 4.4BSD-ig (90es évek közepe), /vmunix-nak hívták.

Az első valóban natív VAX UNIX így 1984-ben tudott megjelenni, ULTRIX-32 néven. Ez a 4.2BSD forkja volt és képes volt VAX gépeken futni fordított formában, nem kellett a kernel forráskódjához hozzányúlni egy hardver konfiguráció során. Így ezt már kizárólag bináris formában terjesztették, forráskód nélkül.

Az ULTRIX, 3 rendszerre volt elérhető, PDP11, VAX és a MIPS alapú DECStation munkaállomásokra és a szerver oldali párjára a DECSystemekre. Néhány apróbb névváltoztatás után a MIPS alapú rendszerek megjelenésével lett a végső elnevezés VAX/ULTRIX és RISC/ULTRIX.

Az idő előrehaladtával aztán kerültek bele a fejlesztések (TCP/IP, SMTP, MAIL11 protokollok). Eredetileg az UWS (Ultrix Workstation Software) volt az asztali környezet, ezt később váltotta a széles körben elterjedt X11, DECWindowsal.

Az utolsó verzió 95-ben jelent meg a 4.5-ös verzió.[2,3,4,5]

Boot fail

Sajnos a rendszer nem volt képes elindulni, gondolom a kernel sérült.

Ráküldtem egy TEST 71-et ami ellenőrzi a diszket, de nem lettem tőle beljebb. Miután utána sem indult el. 🙂

Még az is lehet, hogy ki lehetne bogozni pontosan mi a baja, de innentől nem igazán szerettem volna bántani az MFM winyót, amíg nincs egy full backupom róla.

Mentőkörnyezet

Szerencsére hálózati csatoló van rajta, látatlanban is azt mondtam, hogy hálózatról fog tudni bootolni, mégsem PC-ről beszélünk (kek). Nem olyan egyszerű azért, miután thin ethernet (10BASE-T) csatlakozó van rajta (de legalább ethernet).

Az elképzelés tehát a következő volt:

1. Hálózatról bebootol a VAXStation
2. Egy Linux/BSD szerver válaszol a kérésre
3. Elindul a VAX-on egy NetBSD
4. Hálózaton felcsatolok egy NFS megosztást
5. DD-vel leimageelem a diszket.

Amilyen egyszerűnek hangzik annyira volt összetett a dolog.

A mentőkörnyezet összeállítása

Tehát kell egy thin ethernet hálózat. Fiatal vagyok ehhez, én már a 90-es évek végén is fast etherneteztem, de nagyon nem sokban különbözik a kettő (de). Szerencsére nem vagyok az a kidobós fajta, így volt egy rakat 50Ω-os BNC kábelem, BNC T dugóm, csak a terminátor hiányzott. Miután észleltem (ez csak szebben hangzik mint, hogy nem értekhozzá és próbálkoztam), hogy közvetlenül nem lehet összedugni két kártyát, mindenképp kell T dugó és terminátor, így beszereztem gyorsan 4-et. Jó lesz tartaléknak.

BNC csatlakozós hálókártyát nem fogok találni ami egy mai modern géppel megy (meg hát van egy rakat ISA ethernet kártyám). Szerencsére volt a szekrényben egy P1-es gép, 32 mega RAM-al és egy ~500 megás winyóval. Ebbe raktam 2 NE kompatibilis hálókártyát és egy Debian Woody GNU/Linuxot (azért kettőt mert az egyik a thin ethernet a másik pedig a fast ethernet).

Hálózat konfiguráció Linux szerveren

Ha valakit érdekel itt HW konfiguráció: dmesg

Legelőször a hálókártyát kellett életre kelteni ISA/PNP természetesen nem működött rendesen, szerencsére volt lehetőség a kártyákat kézzel jumperelni, így mindkettőt felkonfigoltam, hogy ne ütközzen semmivel. Majd betöltöttem a megfelelő kernel modulokat (ne ftw).

/etc/modules-ba beírtam, hogy “ne”
/etc/modules.conf-ba pedig beállítottam a feljumperelt dolgokat, illetve, hogy a másik eszköz neve eth1 legyen:

Kézzel betöltés vagy reboot után lehet tetszőlegesen konfigolni a hálózatot, lesz 2 eszközünk. Ha megmódosítjuk az /etc/network/interfaces fájlt:

eth0: DHCP, eth1: static, az eredmény pedig alább:

Asztali gépemről mostmár elérem a szervert. Illetve thin ethernet hálózatunk is él.

Szoftverkörnyezet konfiguráció Linux szerveren

Alapból nem fog a VAX gépünk TCP/IP-t beszélni, saját DECnet protokolon próbál tájékozódni. Bootkor ezt MOP-nak hívják (Maintenance Operation Protocol), ez DECNet-be a PhaseII-vel jött be.[6]

MOPD

Szerencsére létezik MOP-ot kiszolgáló daemon linux alá a mopd. Egy apt-get install mopd segítségével fel is rakhatjuk. Annyi trükkje van, hogy az hálózati interfaceünk amire rákötöttük a VAX gépet az mindenképp ALLMULTI-ban legyen, ne dobálja el a nem neki szóló broadcast MOP ethernet csomagokat.

Fixen bevan drótozva, hogy a /tftpboot/mop/ alatt fogja keresni a boot fileokat. Létrehozás után mehetnek is be ide. A “baj”, hogy a legutolsó MOP boot file lassan eljöhet velünk sörözni (2002 júliusi). Annyiban nem probléma, hogy ez csak a kezdő “lökést” adja meg, a lényeg úgyis a kernel. NetBSD1.5.3-as boot.mop fájlt tudjuk használni (boot.mop).

A MOP a MAC cím nevű fájlt fogja kérni a daemontól (.SYS kiterjesztéssel, csupa kisbetű). Jelen esetben ezt a fájlt fogja keresni: 08002b0827b9.SYS

Úgyhogy csináltam egy symlinket a letöltött mop fájlra.

A syslogba logol, de indíthatjuk kézzel is -d kapcsolóval, és akkor látjuk, hogy mit csinál.

DHCPD

Ha ez betöltött, szüksége lesz a gépnek egy IP címre. Felraktam egy DHCP szervert és a hostot bekonfigoltam, hogy fix ip-t kapjon. Kb. ez kell:

filename igazából nem lényeges, be van drótozva, hogy milyen fájlokat keressen (netbsd.vax, netbsd, netbsd.bak ha jól emlékszem).

NFSd

Szükség van a kernelre illetve a binárisokra amivel el tud indulni a gép. Ezt fogja megkapni NFS-en keresztül. /etc/exports-ba felvettem egy megosztást:

NetBSD v?

NetBSD8.1 kapásból elhasalt a kernel betöltésekor. Így visszafele lépkedtem, hogy mi az ami működik még. NetBSD8.1->NetBSD5.0-ig nem voltam túl sikeres. Felületesen végignéztem a levlistákat, a hiba gyaníthatóan az, hogy nem fér bele a memóriába, amikor pedig a végére ér, kezdi előlről, felülírva a már betöltött adatot. A legutolsó működő ami elindult nekem a 4.0.1-es verzió volt. 2007 nem is volt olyan régen… 🙂 Így tehát felmásoltam az /exports/vax/netbsd/root/ alá a kernelt, átneveztem netbsd.vax-ra majd bemásoltam ide mellé a binárisokat. Ez lesz a root partíciónk.

A következőkre lesz szükség ha ezzel megvagyunk:

• SWAP fájl létrehozása: dd if=/dev/zero of=/export/vax/netbsd/root/swap bs=4096 count=4096
• hozzuk létre a console devicet: mknod /export/vax/netbsd/root/dev/console c 0 0

Diskless NetBSD indítás

Ilyen egy full boot.

A boot esa0-val hálózatról tudunk bootolni. Sajnos a /dev könyvtárt nem csinálja meg és nekem nem is volt ott a MAKEDEV script. Ez okozott pici fejtörést, de találtam egy MAKEDEV scriptet, amit bemásolva, megfuttatva, létrejöttek az eszközök (helyi mirror: MAKEDEV).

DD

Sajnos binárisok nagyrésze segfaultol, de szerencsére a dd az működött. Gyorsba meg is futtattam a következőképp (az eszköz nevéről picit később):

bs=blocksize, 512, igazából 256 a blokkméret fizikailag, de így is ment.

• noerror: menjen tovább hiba esetén, ez musthave nekünk, teli leszünk bad sectorral
• sync: a hibás részeket töltse ki nullával, elméletileg itt jöhetne képbe a blocksize, mert így a létrejött fájl jó méretű lenne.

Kész is az image:

🙂 Na már csak megkéne nézni mi is van rajta.

Próbálkozások

Részletekbe nem megyek bele csak levonom a tanulságokat. Azonfelül, hogy baromira nem értek a fájlrendszerekhez és nem is találtam rendes dokumentációt (jelen esetben az UFS-ről) amiből megérteném anélkül, hogy forráskódokat böngésznék vagy kiolvasnám a fél internetet. A lényeg, hogy attólmég, hogy valami UFS nem mindegy, hogy NetBSD, FreeBSD, stb., vagy jelen esetünkben ULTRIX-os UFS. Nem is a fájlrendszer a probléma hanem inkább a BSD particiókkal.

BSD sliceok/BSD particiók

MBR-hez hasonlóan 4 particióra tudja felosztani a diszket a BSD, ezeket sliceoknak hívjuk. Sok esetben, főleg régi rendszereknél, illetve ahol nincs nagyon értelmezve, nem kerül kialakításra MBR-es BSD sliceok hanem a BSD particiókat közvetlenül a diszkre írja. Ezek a BSD particiók kapnak egy betűt, amivel lehet őket hivatkozni. Szépen, sorban, a, b, c, d, stb. Itt érdemes megjegyezni, hogy bár nem kötelező de az alábbi kiosztást szokták használni:

• a: root partició
• b: swap
• c: teljes slice-ra mutató logikai partició
• d és annál feljebb pedig tetszés szerinti felosztás

Tehát egy BSD alatt formázott diszk az alábbi módon nézhet ki:

rd0s0a ahol

• rd0: eszköz neve és sorszáma
• s0: a slice sorszáma
• a: BSD partició neve

Nyilván ha a BSD particiókat közvetlenül írjuk ki a diszkre slice nélkül akkor nincs sliceunk, tehát akkor ilyet kapunk:

rd0a

Ugye a korábbi dd parancs ezért lett rd0c-vel paraméterezve. Az RD0-ás eszköz teljes tartalmát adta vissza.

FreeBSD alatt próbálkoztam a legtöbbet, itt csak a root particiót sikerült felcsatolnom a többire hibát írt, ami mindösszesen 8mb, így sejtettem, hogy van még legalább egy másik is :).

Először próbálkoztam testdiskel, miután a BSD particiók közvetlenül vannak a diszkre rakva, nincs MBR particionálás/sliceolás (van ilyen szó?), vagy akármi értelmezhető a testdisk számára, így megtalálni megtalálta, de nem tudta helyreállítani.

Ezután próbáltam a scan_ffs programmal, ami megtalálta ugyancsak, disklabel számára értelmezhető formába rakta, de miután kiírtam a diszkre ugyancsak nem tudta olvasni, sőt ilyenkor már a root-ot sem, ami mondjuk érthető, egy FreeBSD-s bsdlabel-t rárak, azt nem biztos, hogy szeretni fogja.

Végül megpróbáltam ráengedni egy fsck-t, de ez nem is igazán értette, hogy mit akarok. Nem tetszett neki az ULTRIX-os UFS.

Próbáltam aztán byte szinten végignyálazni a diszk imageet, keresni az UFS magic byteokat, abból következtetni a helyére a diszkben, esetleg átírogatni, átmozgatni byte szinten, de ehhez azért jobban kell ismerni a felépítését, hogy kézzel kitudjak javítani egy diszket. Legvégső esetben akár ez is lehetett volna de először gondoltam megpróbálkozok egy natív ULTRIX-szal.

Megoldás

Az eredeti ötlet ezek után az volt, hogy feltelepítek egy ULTRIX-ot. Létrehozok egy ugyanekkora diszk imageet, leformázom majd így megpróbálom kézzel byte szinten összegyúrni. Gyakorlatilag az üres keretet feltöltöttem volna a dd-zett image adataival.

SIMH emulátorba raktam fel egy ULTRIX-ot (ultrix4.5 konfig fájl), aminek odaadtam a létrejött diszk imageet. Arra gondoltam, hogy azért megnézem mit szól hozzá, netalán még be is tud bootolni róla a SIMH (nem). Az SIMH/ULTRIX telepítés  egy érdekes dolog, erről lehet majd később fogok írni. Nem bonyolult, kb. next next finish, de azért érdekes.[7]

Innentől kezdve felgyorsult a folyamat. Megkapta az imageet, simán engedte mountolni a root-ot, szólt, hogy sérült a fájlrendszer, fsck szépen javítani is tudta. Lássuk mit szól a másik particióhoz, hiszen a root FreeBSD alatt is ment. Egy fsck után már fel is csatolta, láttam a tartalmát.

Ez simábban ment mit gondoltam.

hálózat+tar

A korábbi konfig fájlban van egy ilyen sor:

set XQ MAC=08-00-2b-04-14-02
attach XQ0 eth2

Ez engedélyezi az ethernet eszközt, az attach pedig összeköti a fizikai eszközünkkel. Amennyiben nem Linux alatt futtatjuk a SIMH-t úgy a SIMH konzolba a show xq eth parancsot futtatva lekérhetjük, hogy melyik eszközünkhöz milyen eth név tartozik:

1. ha jól értelmezem a doksit a hálózat működéséhez kell pcap driver telepítve legyen. Nálam alapból fenn volt a WireShark, szóval ez nem tűnt fel.
2. igen, a cikk írása és a telepítés között eltelt időben változott a hálózati interfaceek listája nálam, eth2 akkor nem a VBOX_NatNetwork volt.
   Ha helyesen állítottunk be mindent akkor ULTRIX alatt adnunk kell egy IP címet:

Ha ezt a két sort felvesszük az /etc/rc.local fájlba akkor minden induláskor beállítja. Aktuális beállításunkat a netstat -i  parancssal tudjuk lekérni:

A SIMH-t futtató gépem nem igazán akart kommunikálni a SIMH-ban futó ULTRIX-szal, így a VBOX-ban futó Linuxos NFS szervert nem tudta felcsatolni magának. De a fizikailag különálló eszközöket elérte. Így gyorsan csináltam az OpenBSD-t futtató laptopomon egy NFS szervert. Fontos, hogy az /etc/hosts fájlba fel kellett venni az NFS servert, különben nem volt hajlandó felcsatolni:

Majd lehetett csatolni:

A jó öreg tar is pöröghetett már rá:

 Zárszó

Egyik legizgalmasabb hobbiprojektem ez volt jó ideje. Látszólag menthetetlen dolog volt de a végére összejött. Igaz szerencsém volt, hogy valóban olvasható volt a diszk tartalma valamennyire. Valószínűleg nem lett volna ennyire egyszerű ha valóban szektoronként kell végignézni az imageet.

Következő lépés lehet, hogy helyreállítsam és működőképesre varázsoljam a telepített ULTRIX-ot. Esetleg az image fájlt sikerüljön elindítani SIMH-ban. Érdekessége volt az /usr/users könyvtár tartalma:

A

• hve: Horst von Eicken CERN alkalmazott,
• dietrich: Dietrich Wiegandt a CERN-ből
• blake:  J.D. Blake, ugyancsak CERN alkalmazott ennyit találtam róla.
• antoniop: Antonio Pastore, neki egy forráskódját is megtaláltam betarolva. 🙂

Miután volt egy ELTE matrica a gép elején és látva a rengeteg CERN alkalmazott nevét, él a gyanú bennem, hogy a gép 91 körül került Magyarországra a ludens VAX9000-es clusterrel egyidőben, Úgy tudom, hogy anno tőlük szerezték be. Ellenben úgy látszik nem igazán használták itthon, ha még odáig sem jutottak el, hogy letöröljék róla a usereket, vagy legalább újakat hozzanak létre rajta.

Hardware pr0n

Források

1)http://antinode.info/dec/vs3100_diag.html
2) https://en.wikipedia.org/wiki/Ultrix
3) https://en.wikipedia.org/wiki/Unix
4) https://en.wikipedia.org/wiki/Version_7_Unix
5) https://en.wikipedia.org/wiki/Berkeley_Software_Distribution
6) https://en.wikipedia.org/wiki/DECnet
7) http://gunkies.org/wiki/Installing_Ultrix_4.5_on_SIMH
8) http://vaxarchive.org/hardware/vs2000/index.html
9) https://www.netbsd.org/docs/network/netboot/intro.vax.html
10) http://gunkies.org/wiki/Netbooting_a_VAXstation