solaris installation problem

    Quote from osf1g

    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).

    Die SS2 hat 50pol SCSI, keine native SCA80 Backplane, wie in der SS5. turbochannel nutzt wahrscheinlich einen simplen SCA80-auf-50pol Adapter. So einen nutze ich im PC für Solaris (2.4) auch. Die Adapter besitzen i.d.R. keine Terminierung (bei meinem zumindest), so dass die Busterminierung über das CD-ROM (letzter Teilnehmer am Kabel) realisiert wird. Alternativ hilft auch ein aktiver Terminator (Stecker).


    Bei der Platte und dem Adapter bitte ggf auch prüfen, dass nicht irgendwo ein Mini-Jumper/-Brücke für die Terminierung auf der Platte bzw Adapter (welcher?) gesteckt ist. Das darf bei der SS2 nicht sein. Wenn man die Option zum Betrieb für Single Ended bei der SCA80 hat, würde ich das auch aktivieren.


    Die RasterFlex-Treiber sollte/kann man i.d.R. erst nach Solaris-Installation, und VOR Einbau der RasterFlex aufspielen. Ich empfehle für die Installation daher einen Sun Referenz Framebuffer (BW2, CG3, CG6) oder serielle Konsole.


    ok probe-scsi-all

    ...zeigt auch das CD-Laufwerk, welches nativ 512-byte Blockgröße unterstützt auch an?


    ok boot cdrom -s

    ...bootet in den Single User Mode, sofern SCSI ID 6 beim CDROM und der Alias "cdrom" auf das korrekte Gerät zeigt.


    # format

    ...und Auswahl deiner Platte. wobei der i.d.R auch gleich die Geometrie (CHS) zu Beginn gezeigt wird, bzw steht die i.d.R. auch auf der Platte drauf. Ich empfehle ein LowLevel-Format der Platte, wenn du die eh nur in der SS2 oder einer anderen SPARC betreiben willst und noch Fremdbits drauf sind. Die SCSI-Platte lässt sich ohne Sun-spezifisches "Label" (VTOC) nicht in einem SPARC-System betreiben. Das muss also mindesten sichergestellt werden. Das gibt vor wie "groß" die Platte ist (Slice 2) und lässt Platz für benötigte Bootloader.


    Um die anschließbare Plattengröße zu zum Schluß etwas zu entkräften: in meiner SS2 werkelt eine 160GB SATA-Platte an einer Bridge, die von der Geometrie so modifiziert wurde, dass eine 2,1GB Platte (Label SUN2.1G) vorgegaugelt wird, nicht das dies zwingend nötig gewesen wäre. Man muss dafür sorgen, dass der Kernel unix bzw '/' (root, Slice 0) bei älteren Solaris-Releases innerhalb der ersten 1024C (0..1023) liegt.

    Quote from Zorro III

    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":

    Das würde nur mit dynamisch ladbaren Treibren funktionieren, da die Hardwareerkennung nur in der init-Funktion erfolgen sollte, die beim Laden des Treibers (das heisst, bei den frühen Solaris-Versionen und allen SUNOS) beim Laden des Kernels während des Bootens erfolgt. Ich weiss nicht, ab wann die bei Solaris verfügbar waren. Ich hatte Treiber unter SVR4.0 entwickelt, wo das noch nicht vorhanden war (war ich froh, als bei SVR4.2 die dazu kamen).

    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.

    Quote from osf1g
    Quote from Zorro III

    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.

    Langsam wird es echt frustrierend - seit drei Tagen sitze Ich daran. Wenn Ich ohne Framebuffer die CD boote, über die serielle Verbindung, bekomme Ich nur ein Stack Overflow in der Endlosschleife. Habe schon eine alte 50pin SCSI Festplatte eingebaut und drei CDs gebrannt, inmal Solaris 2.3 und zweimal 2.5.1, immer das selbe ergebnis. Meine DEC 3000 kam mit dem Laufwerk immer gut zurecht.

    Vielleicht sollte Ich es mal übers Netzwerk versuchen. Ist eine Installation über meinen Linux Rechner ohne weiteres möglich?

    Mit der Platte hat das nichts zu tun. Das tmpfs liegt im Speicher. Wie ich schon mal vorgeschlagen habe, würde ich mal einen memory test aus dem OpenBoot ausführen, ob es da nicht ein Problem gibt.

    Quote from osf1g

    Mit der Platte hat das nichts zu tun. Das tmpfs liegt im Speicher. Wie ich schon mal vorgeschlagen habe, würde ich mal einen memory test aus dem OpenBoot ausführen, ob es da nicht ein Problem gibt.

    'test /memory' testet immer nur das erste Megabyte, ist das richtig? Ich habe nun drei mal die Speicherriegel in Bank 0 getauscht, leider keine Verbesserung.


    Ein Satz von diesen Riegeln gab allerdings einen Bad Trap. Bei den anderen tritt das nicht auf.

    Dachte ich eigentlich nicht, dass da nur das erste 1MB getestet wird, kann das aber auch nicht sicher sagen.

    Nach dem mount error kannst du keine Eingaben mehr machen? Falls doch, solltest du dir mal die Datei /var/adm/messages anzeigen lassen.

    Quote from turbochannel

    Meine DEC 3000 kam mit dem Laufwerk immer gut zurecht.

    Der Yamaha CRW8824S unterstützt 512 Bytes als Blockgröße, was für Solaris nötig ist. Hast du den Jumper gesetzt? → https://www.manualslib.com/man…8824s.html?page=15#manual


    Zu Thema Installation über's Netz kann ich leider keine Kenntnisse oder Erfahrungen beisteuern, die Idee ist aber gut.

    Das mit dem Test lag am diag-switch? der auf false stand. Habe ihn auf true gesetzt und damit den RAM getestet der ein Bad Trap verursacht. Aber der Test beanstandet nichts. Auch die anderen Riegel sind laut dem Test ok, jedenfalls kommt keine Fehlermeldung.


    Der Jumper für 512 Bytes als Blockgröße ist gesetzt, wie gesagt, bootet die DEC 3000 von diesem Laufwerk auch.

    Der Panic deutet entweder auf ein Speicherproblem hin oder ein Problem mit der CPU. Ich würde das mal mit der minimalen RAM-Ausstattung nochmal testen und gegf. die Module durch tauschen. Wenn es bei allen Modulen auftritt, hat wohl die CPU einen Hau.


    Ich sehe grade dass das nur bei bestimmten Modulen auftritt. Dann würde ich die mal raus schmeissen und mit denen weiter testen, bei denen der Trap nicht auftritt.

    Warum zeigt "banner" im OBP 2.4.1 eine RAM-Größe von 40MB? Das sollte so nicht sein bzw widerspricht den Vorgaben. Sicher, dass es alles 4MB SIMMs sind. Mindestens 16MB RAM: 4MB SIMMs, je Bank 16 MB, 16x9, FPM, <=70ns. Bei einem der letzten Bilder war nur Bank 0 bestückt, d.h. vier SIMMs. Wie kann da 40MB rauskommen!? Hattest du vorher noch 1MB SIMMs zusätzlich installiert?


    Wieviel getestet wird ist im OBP beim Parameter selftest-#megs hinterlegt.


    Wenn Bank 0 korrekt bestückt wurde, sollte es so aussehen:



    BTW: das ISO von SunOS 4.1.1 Rev B funktioniert auf echter Hardware ohne Beanstandung. K.A. mehr, was bei der TME-Installation damals schiefgegangen ist. War wohl ein Layer-8-Problem.




    Edited once, last by escimo: ergänzt ().

    Like 1

    Die angegebenen Speichergrößen stimmen, Ich habe die Riegel nur ständig gewechselt.


    Gerade setze Ich mich mit der Netzwerk Installation auseinander, von Ubuntu 20.04. Ich habe schon mal von einer SGI workstation zur anderen über tftp und co. eine Irix Installation orchestriert, das ging gut, aber hierzu finde Ich nur ab Solris 8 beispiele im Internet. z.B. hier: https://znark.com/tech/solarisinstall.html


    Ich weiss nicht wirklich ob Ich alles richtig mache und meine nervlichen Kapazitäten sind etwas erschöpft. Mal sehen wie es weiter geht. Kann ne weile dauern.

    Na, ich weiß nicht ob da nicht das Solaris nicht schon richtig losläuft. Der Screen bei

    solaris installation problem

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


    Aber: das Laufwerk wird vorher korrekt angezeigt ( sd@6,0 ) und wenn dann was passiert, heißt das doch, daß das Booten prima geht.

    Und das würde natürlich wohl auch heißen, daß, ein korrekt installiertes Netzbooten, irgendwie in die gleiche Falle (Trap) rennen müßte.


    Für das RAM sagt SUN, daß die SUN bitte RAM Riegel mit der Nummer 501-1739 zu bekommen hat und das sind 30 Pin SIMMs mit 80ns und 4 MByte die in 4er Grüppchen eingebaut werden müssen. Das sollte man mal kontrollieren. Wenn da jetzt 70ns RAMs drin sind ist das sicher auch OK, aber 100ns werden nicht gut funktionieren.


    Wenn Du magst, schließ die mal an ein serielles Terminal an - da bekommst Du noch mehr Infos beim Hochfahren in den Boot-Prompt, etwa ob der MemoryController und die CPU Caches OK sind. Das sagen die normalerweise dort an aber nicht auf dem Bildschirm.

    Quote from ThoralfAsmussen

    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 mir mal den Speicher genau angesehen.


    Ich habe:

    8x toshiba THM91000AS-80 PN: 501-1697

    8x samsung KMM594000A-8 PN: 501-1739


    Ich mische die nicht innerhalb einer Bank und teste mit 4 Riegeln. Mit diesem CDROM Laufwerk habe Ich auch DIGITAL UNIX 4.0E auf der DEC3000 installiert. Vielleicht probiere Ich mal einen anderen Brenner. Das Image habe Ich von winworldpc. Auf meinem PC lässt sich die CDROM einwandfrei auslesen.

    Quote from turbochannel

    Ich habe:

    8x toshiba THM91000AS-80 PN: 501-1697

    8x samsung KMM594000A-8 PN: 501-1739

    Anscheinend ja doch, anders schafft man es nicht auf 40MB!


    https://dogemicrosystems.ca/pu…ms/Sun4c/MEM_Modules.html


    501-1697 : 1MB SIMM - FAIL :neinnein:

    501-1739 : 4MB SIMM - OK :thumbup:


    Ja, OK: <= 80ns 4MB SIMMs, NICHT 1MB SIMMs, die hier auch angegeben werden! Sonst kommst du nicht auf 16MB in einer Bank (zu 4 Slots)!


    Teste/Nutze einzig die 501-1739

    ok setenv selftest-#megs 32

    ok test /memory


    Installserver in VBox unter Solaris 10 Ein bissl zusammentragen/lesen muss man noch und es läuft bei mir ab Solaris 2.4 und aktueller

    https://sonnenblen.de/index.php/topic,6877.0.html

    Das die 1MB SIMMs mit SS2 nicht kompatibel sind wusste Ich nicht! Ich meinte auch, dass Ich die nicht innerhalb einer Bank gemischt habe. Dabei habe Ich die so ersteigert, mit diesem SIMMs eingebaut. Ok, dann werde Ich die nicht mehr einsetzen und das nochmal alles testen.


    Ansonsten werde Ich das mit dem Solaris 10 Server in VBox testen, danke für den Tipp.

    Kein Ding!


    Weitere Empfehlung: SIMM-Kontakte reinigen (Radiergummi-Methode bspw). Ggf habe die nicht vollen Kontakt.


    Was hat der Speichertest (32MB) ergeben?



    Auch scheint Solaris bereits auf der Platte installiert zu sein mit einigen Updates für den Kernel (PatchID 103640 Rev 12).


    * Die Platte hat ein valides Sun-Label (VTOC) mit format bekommen?


    * Die Slice 0 (root) ist <= 512 MB !?


    Größer geht i.d.R. nicht. Nicht probiert: Filesystem /platform auslagern unterhalb der ersten 512 MB der Festplatte, ab Cyl 0.


    Ein entferntes Kernel-Problem hatte mit der Ultra 80 bei Solaris 8 & 2.5.1 vor 12 Jahren - war letztlich ein defektes DIMM, hier: https://sonnenblen.de/index.ph…03.msg30686.html#msg30686


    Daher bitte möglichst sicherstellen, dass der verbaute RAM i.O. ist. Notfalls mal in einen PC reinstecken (CPU bis 20MHz) Auch eine anderes Solaris-Release kann dirchaus nützlich sein, zum Gegenprüfen.


    Da ich die selbe OPB-Version in einer SS2 habe, Speicher auch 32MB, nur die Vitec RasterFlex-HR aktuell net drin wollte ich es nachstellen. Fehlanzeige, kein BAD TRAP.


    Quote from turbochannel

    Das die 1MB SIMMs mit SS2 nicht kompatibel sind wusste Ich nicht! Ich meinte auch, dass Ich die nicht innerhalb einer Bank gemischt habe. Dabei habe Ich die so ersteigert, mit diesem SIMMs eingebaut.


    Die Tabelle sagt eigentlich nur - und ich hatte meine "Weisheit" mit den zulässigen Nummern auch nur von da, wobei es eher selten ist, daß da nur ein einziger Riegeltyp für eine Maschine angekreuzt ist - daß das der Riegel ist, den sie bei SUN verbaut, getestet und benutzt haben. Das schließt erstmal gar nicht wirklich aus, daß nicht was anderes technisch gleichartiges ( wichtig ECC ja oder nein, 80ns und kleiner ) auch funktionieren kann. Aber möglicherweise ist eben einfach für Tests und Neuaufbauten einfach sinnvoll, sich da an die Vorgaben zu halten.



    Ich bin ja auch nur wegen der 40MB stutzig geworden. Wenn Du genug Riegel für 32 MB hast, nämlich 2x 4x4MB von den 1739ern, dann bestücke mal die Bank 0 und 1 mit jeweils 4 davon - und wahrscheinlich gehts dann schon, auch von CD.


    Guck Dir mal das Gekrampfe an, was hier neulich mal mit der 3/80 zu lesen war. Das war auch so ein Aufbau, der nicht so ganz regelkonform war und mit irgendwelchen OpenBoot Versionen und Modifikationen auch mehr RAM zuließ, als da eigentlich ging - und dementsprechend läuft die Kiste dann eben mal und mal nicht und natürlich ordentlich nur, wenn sie exakt so aufgebaut wird, wie der Benutzer sich das ca. 1990 mal "hingezimmert" hat. Das macht aber heute irgendwie keinen Sinn, weil man da lieber mal auf bißchen was verzichtet und dafür geht es. Zu der Zeit war das evtl. die größte Anschaffung im "Institut" und mußte dann noch 5 Jahre benutzt werden, weil sie so obszön teuer war.

    Quote from escimo

    * Die Platte hat ein valides Sun-Label (VTOC) mit format bekommen?


    Das verstehe ich tatsächlich auch nicht - das kann doch eigentlich erst dann sinnvoll passieren, wenn der Installer mal losgelaufen ist, und soweit ist es ja noch gar nicht.


    Ich habe hier auch ein paar Platten, die sind ganz ordentlich installiert und einfach mit dem Installer "formatiert" und trotzdem meckert der dann beim echten Loslaufen daran rum, daß die Geometriedaten irgendwie nicht passen. Funktionieren tut es aber trotzdem. Das fand ich aber schon immer ein wenig seltsam und kann mir das nur so erklären, daß der gar nicht neu "labelt", wenn da schonmal was drauf war sondern evtl. nur die Größen der Partitionen ändert.

    Quote from Zorro III

    Ansonsten könntest du es auch mal mit Linux —z.B. Debian 3.0 aus 2002 —probieren


    Das ist auch ein gute Idee ! Eigentlich sollte die SUN schon Bescheid sagen, wenn was relevantes kaputt ist, aber die Linuxe testen halt evtl. auch bißchen anders. Eine weitere Alternative wäre NetBSD, das funktioniert auch schön auf SPARC, zumindest auf den älteren.

    Quote from ThoralfAsmussen

    Das verstehe ich tatsächlich auch nicht - das kann doch eigentlich erst dann sinnvoll passieren, wenn der Installer mal losgelaufen ist, und soweit ist es ja noch gar nicht.

    War Schwachsinn meinerseits. Ich bitte um Entschuldigung! - Ich habe mich verwirren lassen: turbochannel bootet ja von CDROM mit Kernel Version Generic_103640-12 (patched Kernel HW 4/97 oder 11/97). Ich boote von einem Originalmedium Solaris 2.5.1 (Sun Part# 704-5235-10 Rev. A, May 1996) und habe Kernel Version Generic (unpatched).


    In den Single-User-Mode booten, um format aufzurufen, bevor man die eigentliche Installation startet mit...

    ok boot cdrom -s

    Doch ich befürchte, das geht bei dieser Auswirkung dann auch nicht. Schon probiert?


    // RECOVER ON

    Es gab gar noch einen Sonderfall mit der Installation von Solaris 2.5.1 in Verbindung mit 256 MB RAM in einer SS20 (20 nicht 2). Da kommt man auch nicht in die Installation rein, weil der explizit nicht mit 256 MB RAM booten will. D.h., man musste RAM ausbauen, Solaris installieren, und danach konnte man den ausgebauten Speicher wieder einbauen. Irre. Ich finde den Post dazu leider nicht mehr. Sollte man bei einer SS2 wohl ausschließen. Oder hast du zufällig 16MB SIMMs verbaut? - Spaß, das kann die SS2 nicht adressieren. Da sind nur bis 128MB möglich. 8o
    // RECOVER OFF


    Ergänzung: es gehen auch SIMM von PCs, die innerhalb der Spezifikation operieren: 4MiB (9 Chips), 16x9, FPM, Parity, <=80ns -- aber bitte nicht mit 3 Chips!

    Edited once, last by escimo: Ergänzt ().

    Ich habe zwischendurch einfach die Festplatte (mit Solaris 7) von der kürzlich ersteigerten IPX in die SS2 eingebaut, um zu sehen ob überhaupt irgendwas funktioniert und Solaris bootet sogar. Mir fällt erst jetzt auf, dass das ja ein gutes Zeichen sein muss und es einfach am CDROM Laufwerk liegen muss.

    Auch wenn Ich die 1 MB SIMMs ganz raus lasse bekomme Ich den Bus error.


    Ich werde den RAM über die serielle Console testen, aber wie schalte Ich diese absolut lästige "Type ’go’ to resume" Sache ab? Irgendwie erscheint der meiste Text nicht.

    Quote from turbochannel

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

    Quote from turbochannel

    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.

    Quote from Zorro III

    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.

    Also die DEC3000 und Digital Unix brauchen ebenfalls ein CDROM mit 512 Byte-Blöcken. Wenn das an der Sparc verwendete CDROM nicht auch 512 Byte-Blöcke verwenden würde, würde es gar nicht so weit booten können. Ich würde daher das CDROM als Fehlerquelle hier ausschliessen.

    EDIT: das CDROM könnte natürlich dennoch irgendeinen Hau weg haben, aber die Blockgrösse stimmt zumindest.

    Quote from turbochannel

    Über der seriellen Verbindung erscheint ständig "Type 'go' to resume" alle ein bis zwei Zeilen. Der Computer ist kaum benutzbar dadurch. Wie stelle Ich das ab?

    Sieht so aus als würde ständig ein "break" gesendet, d.h. deine serielle Verbindung ist murks. Benutzt du das gleiche Kabel/Adapter wie bei der IPX? Da schriebst du ja auch was von Verbindungsproblemen.

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

    Like 1