Diskinhalte archivieren und anschauen Vaxstation

    • Offizieller Beitrag

    Habe mir bei Ebay günstig eine externe Festplatte gekauft, die mit "Vaxstation DKB300" und Zustand unbekannt/ungeprüft beschriftet war.

    Das Gerät ist jetzt hier.

    Die Platte ist überraschender Weise in Ordnung. Sie wird von der Vaxstation erkannt (ist eine Quantum Lightning 730MB), aber kann nicht mit VMS 5.5 gemountet werden.

    Unter Linux geht das auch nicht. Zumindest Linux meint, es handele sich um ein "UFS" Filesystem, mounten geht aber trotzdem nicht.

    Das Image der Platte habe mich mit DD gesichert und dann die Platte an der VS mit Test 75 low level formatiert und anschließend nach Bad Blocks gesucht und initialisiert.

    Soweit alles gut.

    Kann ich mit dem DD Image vielleicht noch was anfangen? Was könnte das für ein Dateisystem sein? Einfach ein korruptes Files-11 oder was ganz anderes (Netbsd? ultrix?)

  • Meine Erfahrungen mit Linux UFS sind nicht sehr gut, aber ein Image einer Ultrix 4.5 für VAX CD konnte ich mounten. Was sagt denn `file` über das Image?


    Falls du es hochladen magst, sehe ich es mir gerne heute Abend an. Ich mag diese Art Rätsel :)

    Suche: SGI Indigo (gerne IP12), DEC/DIGITAL CRT Monitor und ein VT240 (inkl. Monitor).

  • Ich verwende für so was osxfuse unter macOS. Da kann ich so ziemlich alle UFS images mounten (versuche gerade, ein korruptes Solaris Disk Image zu reparieren). Die Magic-Nummern bei UFS sind etwas schwierig zu finden. Es gäbe am Ende eines Superblocks die Kennung 011954 (Geburtsdatum von Bill Joy, hex), danach könntest du suchen. Könnte aber auch von der UFS-Version abhängen, bin nicht sicher, ob das bei allen UFS-Versionen so verwendet wird.

    Der Bootblock hat auch eine Magic-Number irgendwo, fällt mir aber gerade nicht ein.

    Ein Hexdump der ersten ca. 9000 Byte könnte helfen (512 Byte Bootblock und danach 8192 Byte erster Superblock).

  • Bei Linux muß man i.a. den UFS Typ mit angeben, sonst passiert da nur eher zufällig was. "mount -t ufs" reicht also i.a. nicht, sonern muß noch mit "-o ufstype=xxx" ergänzt werden.


    Außerdem sollte man immer den "-r" Switch oder equivalent den "-o ro" Switch für Read-Only mit angeben.



    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    • Offizieller Beitrag

    Meine Erfahrungen mit Linux UFS sind nicht sehr gut, aber ein Image einer Ultrix 4.5 für VAX CD konnte ich mounten. Was sagt denn `file` über das Image?


    Falls du es hochladen magst, sehe ich es mir gerne heute Abend an. Ich mag diese Art Rätsel :)

    Aber sehr gern. Mach ich heute abend, bin in der Mittagspause auf der Arbeit...

  • Das Image hat laut fdisk eine DOS Partitionstabelle mit einer FreeBSD Partition:

    Code
    $ fdisk -l disk.img
    Disk disk.img: 699.1 MiB, 733061120 bytes, 1431760 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: dos
    Disk identifier: 0xb444a67a
    
    Device     Boot Start     End Sectors   Size Id Type
    disk.img1  *       32 1431743 1431712 699.1M a5 FreeBSD

    Das tool disktype erzählt uns noch ein klein wenig mehr, insbesondere den letzten Mountpoint:

    Code
    $ disktype disk.img 
    
    --- disk.img
    Regular file, size 699.1 MiB (733061120 bytes)
    DOS/MBR partition map
    Partition 1: 699.1 MiB (733036544 bytes, 1431712 sectors from 32, bootable)
      Type 0xA5 (FreeBSD)
      UFS file system, 0 KiB offset, little-endian
    UFS file system, 8 KiB offset, little-endian
      Last mounted at "/mnt/dka300"


    Die sysid 165 (oder 0xa5) wurde früher auch für NetBSD verwendet (vor Version 1.3.3), das passt aber nicht so ganz zu dem was wir mit strings auf der Platte finden:

    Code
    $ strings disk.img
    [...]
    /Makefile/1.2/Sun Jan 23 17:04:06 2000//Tnetbsd-1-5-RELEASE
    /romcalls.S/1.2/Fri Dec 17 07:33:20 1999//Tnetbsd-1-5-RELEASE
    /cvsroot/syssrc/sys/arch/newsmips/stand/common
    :pserver:anoncvs@anoncvs.netbsd.org:/cvsroot
    Nnetbsd-1-5-RELEASE
    [...]

    Zur zeit von NetBSD 1.5 wurde nämlich schon die neue sysid 169 verwendet.


    Wie auch immer, mal versuchen zu mounten (unter einem aktuellen Linux):

    Code
    # losetup -P /dev/loop0 disk.img
    # mount -t ufs /dev/loop0p1 -o ro,ufstype=44bsd /mnt
    mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0p1, missing codepage or helper program, or other error.

    Diverse andere ufstype Parameter habe ich auch versucht, aber bin damit nicht weiter gekommen. Keine Ahnung ob ich hier was falsch mache? Ein NetBSD 6 Image der gleichen Art konnte ich mounten (mit ufstype=ufs2.)


    Naja, an dieser Stelle habe ich halt mal ein NetBSD in der virtuellen Maschine gestartet, und siehe da: keine Probleme mehr, das mounten funktioniert. Und die sehr langweilige Lösung ist: es handelt sich um ein leeres Diskimage auf dem jemand den Quellcode von NetBSD 1.5 entpackt hat :rolleyes:


    Auch wenn das Ergebnis jetzt sehr langweilig war, würde ich ja zu gerne wissen ob und wie das mounten unter Linux geklappt hätte :nixwiss:

    Suche: SGI Indigo (gerne IP12), DEC/DIGITAL CRT Monitor und ein VT240 (inkl. Monitor).

  • Auch wenn das Ergebnis jetzt sehr langweilig war, würde ich ja zu gerne wissen ob und wie das mounten unter Linux geklappt hätte :nixwiss:


    Gib mal beim mount noch ein "-o loop" mit, vielleicht bringt das ja schon was.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Auch wenn das Ergebnis jetzt sehr langweilig war, würde ich ja zu gerne wissen ob und wie das mounten unter Linux geklappt hätte :nixwiss:


    Gib mal beim mount noch ein "-o loop" mit, vielleicht bringt das ja schon was.

    Die loop option für mount ist nur eine Abkürzung für den losetup Befehl den ich ja selber ausgeführt hatte. Ich habs aber auch ausprobiert um sicher zu sein und bin damit auch nicht weiter gekommen (gleiche Fehlermeldung.)

    Suche: SGI Indigo (gerne IP12), DEC/DIGITAL CRT Monitor und ein VT240 (inkl. Monitor).

  • Schon, aber das loop in Mount macht vielleicht z.B. noch automatisch ein "-c" für das aufgerufene losetup mit, einfach ungefragt. Ich habe das zumindest so einzeln mit den beiden Kommandos noch nie gesehen, dafür hat aber Loop Devive mit einfacher Angabe von -loop beim Mount Befehl bisher immer schön funktioniert.


    Ich habs aber auch ausprobiert um sicher zu sein und bin damit auch nicht weiter gekommen (gleiche Fehlermeldung.)

    So it goes ...


    Kann nicht immer klappen.


    Aber irgendwie, meine Erfahrung hier, bekommt man unter Linux alles einghängt, was irgendwie wie ein Dateisystem aussieht. Manchmal sind allerdings die Verrenkungen abenteuerlich.



    FreeBSD zum Beispiel unterteilt die "DOS Partitionen" dann nochmal in seine eigenen Partitionen. Dabei heißen die unter DOS laufenden "Partitionen" "Slice". Man kann also vier "Slices" auf so einer Platte haben, wenn sie einen normalen MBR Kopf/DOSPartitionstabelle hat - das was Dein fdisk da anzeigt ist also wohl eben genau ein "Slice". Dieses wiederum wird aber nach einem relativ vorgegebenen Muster dann noch in die "FreeBSD Partitionen" unterteilt - und nur diese kann man sinnvollerweise in einen Dateibaum einhängen.


    ab der Mitte ungefähr

    https://www.freebsd.org/doc/de…ok/disk-organization.html

    und unten im Bild ... Du würdest oben versuchen, die ada0s2 als Dateisystem einzuhängen, müßtest aber die ada0s2a benutzen.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    3 Mal editiert, zuletzt von ThoralfAsmussen ()

  • Für CD Images und sowas benutze ich normalerweise auch einfach nur mount cd.img /mnt und das funktioniert vollautomatisch.


    Der Vorteil an dem losetup Befehl hier ist, dass der mit -P die Partitionen des Images scannt und als loop0p1, etc. bereitstellt. Mit mount und loop option muss man dann selber den offset der Partition im Image angeben. Ist natürlich nicht schwer, aber der Grund weshalb ich den Weg über losetup hier einfacher fand. (Aber wie gesagt, beides versucht!)


    Hier was bei der NetBSD 6 VM Platte funktioniert hat:

    Der gleiche mount Befehl mit offset=$((32*512)) bei dem Image von Toshi liefert die übliche Fehlermeldung:

    Code
    # mount -t ufs disk.img -o ro,ufstype=ufs2,loop,offset=$((32*512)) /mnt
    mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.

    (Wobei ich hier für ufstype auch old und bsd44 versucht habe.)

    Suche: SGI Indigo (gerne IP12), DEC/DIGITAL CRT Monitor und ein VT240 (inkl. Monitor).

  • Falls noch nicht bekannt unter Debian10 kann man die Ultrix CD so mounten:

    Code
    $ sudo mount -t ufs -o ro,ufstype=sun,loop /dev/sr0 /media/cdrom
    $ cd /media/cdrom/
    $ ls -l
    insgesamt 2339
    drwxr-xr-x 2 root root    8192 Okt 21  1995 lost+found
    -rw-r--r-- 1 root root   18176 Okt 18  1995 ultrixboot
    drwxrwxr-x 5 root root     512 Okt 21  1995 VAX
    -rwxr-xr-x 1 root root 2353152 Okt 18  1995 vmunix
    $

    Liebe Grüße
    // Peter

  • Falls noch nicht bekannt, so kann man den passenden PAK für "lmf" für Ultrix 4.5 erzeugen:

    Code
    $ cc pakgen64.c -o pakgen64
    $ ./pakgen64 ULTRIX -p DEC -i DEC -a ALS-WM-93176-10007 -c K -N

    Das File "pakgen64.c" findet man schnell, wenn man danach sucht und das Ergebnis ist durchaus brauchbar:

    Code
    # lmf
    lmf> list
    Product                   Status                     Users: Total      Active
    
    ULTRIX                    active                            unlimited
    lmf>

    Liebe Grüße

    // Peter

  • Für Ultrix 4.5 gibt es von DEC einen Y2K Patch, was das System auch heute noch durchaus im Alltag benutzbar macht:

    Code
    # uname -a
    ULTRIX mvax3100 4.5 0 VAX
    # date
    Mon Aug  1 19:50:15 WET DST 2022
    #

    Damit ist es neben 2.11BSD, eines der wenigen historischen UNIX Systeme für DEC Rechner, die es ins 21. Jahrhundert geschafft haben.


    Liebe Grüße

    // Peter

  • Auch auf einer MicroVAX 3100 läuft DECwindows unter ULTRIX 4.5, wenn man xdm von den UNSUPPORTED Paketen nachinstalliert. Man muss sich mangels eingebauter Grafik Hardware zu der MicroVAX 3100 einfach mit einem X-Display über Netzwerk verbinden:

    Da werden Erinnerungen wach ;)


    Der OSF/Motif Window Manager ist allerdings ein bischen zickig mit der Maus. Unter Debian 10 funktioniert es mit Xephyr problemlos, unter Windows 10 hab ich die Maus nur mit Cygwin/X korrekt zum funktionieren gebracht, zum Beisiel mit VcXsrv hat es nicht funktioniert. Da kann man beim mwm weder die Fenster verschieben, noch die Größe ändern, der twm funktioniert auch mit VcXsrv unter Windows 10 einwandfrei.

    Liebe Grüße
    // Peter