Beiträge von Zorro III

    Mir fällt erst jetzt auf, dass das ja ein gutes Zeichen sein muss und es einfach am CDROM Laufwerk liegen muss.

    Mit diesem CDROM Laufwerk habe Ich auch DIGITAL UNIX 4.0E auf der DEC3000 installiert.

    Die Solaris-Installations-CDs sind in einer gewissen Weise speziell, und zwar — ich schreibe hier aus der Erinnerung, so dass ich möglicherweise nicht alle Details zu 100% korrekt wiedergebe — beinhalten diese mehrere architekturspezifische Partitionen sowie mindestens eine allgemeine, welche das eigentliche Installationssystem beinhaltet. Zuerst wird von einer der architekturspezifischen Partitionen der für das jeweilige System (in deinem Fall: SPARCstation 2 → Architektur sun4c) passende Kernel geladen und gestartet und dieser macht dann weiter und bindet u.a. die eigentliche Installationspartition ein. Und diese nutzt statt einem der üblicherweise auf CD-ROMs verwendeten Filesystemformate, welche alle auf einer Blockgröße von 2048 Bytes basieren, das für Festplatten gedachte UFS (https://de.wikipedia.org/wiki/Unix_File_System) mit 512 Bytes pro Block. Dafür muss das CD-ROM-Laufwerk zwingend entsprechenden Firmware-Support mitbringen, und dieser muss aktiviert sein (Jumper) und natürlich funktionieren (Firmware-Update?), denn beim Navigieren innerhalb des Dateisystems werden halt alle möglichen Blocks direkt angefragt und müssen vom Laufwerk korrekt herausgegeben werden. Wenn das Laufwerk denkt, dass die vom OS angefragte LBA auf 2048bpb-Basis zu interpretieren sei, wird es nicht die richtigen Daten liefern, und außerdem zu viele, was wiederum den Gerätetreiber dazu veranlassen könnte, etwas Dummes zu tun. Ein "bus error" klingt in diesem Zusammenhang nicht unrealistisch.


    Ich kenne weder Digital Unix noch die DEC3000, daher kann ich nicht beurteilen, ob die Tatsache, dass du das Laufwerk hierfür schon erfolgreich genutzt hast, den 512-Byte-Support einschließt oder ob dieser hier keine Rolle gespielt hat.

    zeigt doch eigentlich schon eine Kernel Meldung - und der Kernel teilt dann mit, daß er mit dem Memory unzufrieden ist.

    Woraus schließt ihr denn, dass mit dem Speicher etwas nicht stimmt? Natürlich nimmt man, um alle Möglichkeiten mal zu testen, auch mal RAM-Module raus, aber "bus error" hat per se nichts mit defektem Speicher zu tun, sondern mit der Ausführung von fehlerhaftem Code, welcher nicht mit dem erforderlichen "Alignment" auf eine Speicheradresse zugreift.


    Disclaimer: AFAIK

    Ich habe "damals" —Mitte der 1990er- bis Mitte der 2000er-Jahre — routinemäßig SCSI-Geräte¹ im laufenden Betrieb an-/ab-/umgehängt (u.a. weil ich Software für SCSI-Geräte geschrieben habe), wobei man natürlich wissen muss, was man tut, um das System nicht zum Absturz zu bringen. An die genauen Details, welche Kommandos da ggf. nötig waren, erinnere ich mich nicht, "drvconfig" könnte es gewesen sein, heutzutage ist es wohl "cfgadm":

    Du müsstest also, um die neue Hardware erkennen zu können, den alten Treiber ent- und wieder neu geladen haben. Wenn aber die Root-Partition auch auf einer SCSI-Disk lag, die den selben Treiber verwendet hat, dürfte das schwierig gewesen sein.


    EDIT: kann aber auch sein, dass spätere Treiber eine Funktion hatten, um die Hardwarekonfiguration neu einzulesen.

    Aber bei frühen Solaris- und allen SunOS-Versionen kann man definitiv während des Betriebs keine SCSI-Geräte hinzufügen.

    Du hast recht, ich hatte einen eigenen dynamisch ladbaren Gerätetreiber (unter Solaris; bei SunOS 4 musste der noch eincompiliert werden, und da ging wirklich nichts dynamisch), und es handelte sich bei mir in der Tat nicht um Festplatten, sondern um optische Laufwerke (CD-R, MO, Phase Change) und Medienwechsler, die von den Systemtreibern ignoriert wurden. Und ich hab auch nicht an dem SCSI-Bus, an dem die aktive Systemplatte hing, einfach so im Betrieb meterlange Kabel angesteckt und abgezogen, da wären dann garantiert etliche Bits gestorben. :D Dafür hatte man halt zusätzliche Hostadapter in der Maschine.


    Begonnen habe ich damals unter SunOS 4.1 und bin dann direkt auf auf frühe Versionen von Solaris 2 um- und beim Stande von Solaris 2.7 irgendwann aus der Materie wieder ausgestiegen. Schon möglich, dass es zunächst nicht ging, externe Festplatten im Betrieb dazuzuschalten, irgendwann ging das aber wohl auch, denn ich hatte eine für Sicherungszwecke und bin mir recht sicher, für deren An- und Abklemmen nicht extra gebootet zu haben. Es könnte sein, dass ich das auf meinem Entwicklungssystem auf eine unkanonische, nicht von Sun empfohlene Weise getan habe, aber der Hardware hat sowas jedenfalls nicht geschadet.


    Cool, dass es hier noch Leute gibt, die sich aktiv mit dieser alten Hardware befassen, dann findet sich für das wenige SCSI-Zeug, welches ich aufbewahrt habe, ja vielleicht noch ein Liebhaber.

    Vielen Dank für eure Hinweise und Tipps! Dass man von Linux aus direkt auf das Dateisystem der (ausgebauten) SCSI-Platte zugreifen und auch komplette Images hin- und herkopieren kann, finde ich ausgesprochen interessant, das könnte mir für Schritt 2 sehr helfen:


    Meinen A3000 habe ich mit eben dieser Platte drin bis ca. Mitte der 90er in Studium und Beruf als primären Rechner genutzt, bevor ich mir meine erste SUN SPARCstation gekauft habe und der A3000 im Keller gelandet ist. Somit ist da noch immer viel an privaten Daten drauf, welche ich da mal alle runterholen möchte, um den Rechner mit Platte ggf. später mal weitergeben zu können. (Wenn denn alles dann noch läuft — dass da ein alles zersetzender alter Akku auf meinem A3000-Mainboard sitzt, weiß ich erst seit gestern...)

    Während des Betriebs kann man bei Solaris, zumindest unter Solaris 10, keine Platten dazu hängen. Es gibt Kommandos bei Solaris, beim Booten nach neuer Hardware zu suchen. Ich würde auch keine SCSI-Geräte während des Betriebs an oder abhängen. Ich denke nicht, dass das elektrisch problemlos wäre.

    Ich habe "damals" —Mitte der 1990er- bis Mitte der 2000er-Jahre — routinemäßig SCSI-Geräte¹ im laufenden Betrieb an-/ab-/umgehängt (u.a. weil ich Software für SCSI-Geräte geschrieben habe), wobei man natürlich wissen muss, was man tut, um das System nicht zum Absturz zu bringen. An die genauen Details, welche Kommandos da ggf. nötig waren, erinnere ich mich nicht, "drvconfig" könnte es gewesen sein, heutzutage ist es wohl "cfgadm": https://docs.oracle.com/cd/E23…-1459/devconfig2-120.html


    Aber egal, die Frage ob der Fehler vom Speicher oder irgendeiner anderen Hardwarekomponente kommt, ist erstmal die primäre, also alles rausnehmen, was zum Booten von der Installations-CD nicht unbedingt nötig ist, und gucken, wann/ob der Fehler verschwindet. Die CD selbst am besten auch mal gegen eine andere austauschen.


    Nachtrag: ¹) Die Rede ist hier von externen und entsprechend für Hotplug konstruierten internen SCSI-Geräten; der interne SCA-Stecker, der in meiner SPARCstation 5 für Festplatten drin war, gehörte dazu. Da turbochannel ebenfalls von SCA schrieb, nehme ich an, dass das bei seiner SPARCstation 2, welche ich nicht kenne, ebenfalls so ist. Wenn nicht, dann besser nicht "hotpluggen" (und natürlich auch dann nicht, wenn's nicht nötig ist).

    Möglicherweise liegt es ja gar nicht an der Festplatte. Dass bei einer nicht initialisierten HD die "magic number" nicht stimmt, sollte ja nicht unüblich sein, und dass kein Treiber für den Framebuffer zur Verfügung steht, stört im Textmodus auch erstmal nicht.


    "bus error" ist dann aber definitiv nicht schön, und der Rest ("tmpfs mount failed" und dass alles hängt) könnte die Folge davon sein.


    Nimm mal die Platte raus und boote erneut, um zu sehen, ob der "bus error" dann genauso kommt. Von der CD sollte sich ja auch ohne HD booten lassen, und SCSI-Platten könnte man zur Not auch im laufenden Betrieb anstecken, das dürfte elektrisch ungefährlich sein (externe SCSI-Geräte sind ja ebenfalls hotplug-fähig), man muss dann halt nur das laufende System dazu kriegen, die neu hinzugefügte Hardware auch zu erkennen. Da gab es unter Solaris irgendeinen Befehl für, der mir aber gerade nicht einfällt.


    Nachtrag: Ich erinnere mich aus meiner eigenen SPARC-Zeit (ich hatte mal eine SPARCstation 5) noch daran, dass die bei CD-ROM-Laufwerken recht wählerisch waren, und zwar weil die Standard-Blockgröße von CDs halt 2048 Bytes beträgt, aber 512 Bytes pro Block erwartet wurden. Daher mussten es spezielle sein mit einer speziellen Firmware, und ich hab extra Geld dafür ausgeben müssen damals für ein originales von Sun. Ist dein CD-ROM-Laufwerk original?

    Muss die Festplatte erst formatiert und gelabelt werden? Aber wie?

    Was sagt denn "probe-scsi-all"? Ist die Festplatte aus Sicht der Bootumgebung überhaupt vorhanden? Und hast du auf der SPARCstation 2 ansonsten noch irgendein laufendendes System, oder ist das eine komplette Neuinstallation auf einer genullten Platte?

    Nutzt hier von euch jemand einen Amiga-Emulator? Ich hab mir gestern RetroArch 1.8.9 mit P-UAE auf meinem MacBook Pro (15" aus 2016 unter Mojave) installiert und würde gerne den dd-Abzug der 400MB-SCSI-Festplatte meines A3000 damit zum Laufen kriegen.


    Noch weiß ich nicht, wie genau ich da vorgehen muss —die üblichen Beschreibungen gehen alle in Richtung Emulation von Diskettenspielen, was bei mir auch schon funktioniert — falls also jemand Erfahrungswerte beisteuern kann, immer gerne her damit!


    Und falls es wen interessiert, kann ich anschließend auch davon berichten ob/wie es geklappt hat.