Aktuelles
AmigaPortal.de

Wir würden uns freuen, dich als neues Mitglied begrüßen zu können. Melde dich noch heute an und werde Teil einer freundlichen Community deren gemeinsames Hobby der "AMIGA" ist. Hier kannst du dich in einer gemütlichen Atmosphäre mit anderen Usern zu vielen interessanten Themen rege austauschen oder andere an deinen Erfahrungen teilhaben lassen. Wir wünschen dir viel Spaß hier auf AmigaPortal.de

Alternative Bootdevices für Mac/EFIKA/Pegasos

Amigaharry

Kult Mitglied
Hinweis: Dieses Tutorium setzt die Kenntnis des Tutorials über Multibootsysteme, ebenfalls hier im Forum, teilweise voraus. Zumindest ist es für das Verständnis sehr hilfreich! Dieses Tutorium wurde nach bestem Wissen und Gewissen geschrieben - ich kann aber keine Garantie für daraus resultierende Fehler, Schäden, etc. übernehmen.

Wie im Tutorial "Multibootsysteme für Mac/Peg/Efika" bereits erwähnt, gibt es Situationen, in denen man ein Betriebsystem nicht auf die internen Datenträger schaufeln möchte. Das kann z.B. auf einem Powerbook oder Mini der Fall sein, wenn man ein weiters Betriebssystem (MOS oder MacOSX) nur selten nutzen will und die interne HD zu klein ist, man sich eine Neuinstallation nicht antun möchte oder das System zerschossen hat. Um besser zu verstehen, worum es hier geht, ist es sinnvoll sich das Multiboot-Tutorium einmal anzusehen (ich weis - viel zu lesen!). Zumindest sollte man wenigstens wissen was die OpenFirmware (OF) und ihre Konsole ist und was sie tut.
Bitte lest auch die Bereiche, die nicht euren Rechner betreffen - manches Allgemeingültige wird nicht bei jedem Gerät nochmals erklärt! Und ein bischen über den Tellerrand schauen, schadet auch nicht.

Der Weg, Betriebssysteme von externen Datenträgern oder Netzwerken zu laden/booten/hochfahren ist nicht immer einfach. Jedes System hat da so seine "Eigenheiten" - sehen wir uns das der Reihe nach an.

PowerMAC (G4/G5) (Firewire, USB, Network-Boot)

Powermacs mit Firewireport können zumindest MacOS und Linux von dort booten. MorphOS geht nicht, da der (Quark)Kernel keinen FW-Stack integriert hat. Dieser kann erst später nach, dem Hochfahren von HD gestartet werden (-> siehe Helios, der MOS-FW-Stack). Wir könnten zwar den Kernel booten, aber dann gehts nicht weiter.
Wenn MacOSX oder Linux auf dem externen FW-Datenträger richtig installiert wurde, dann taucht es im graphischen Multiboot-Mode (ALT beim Booten/Einschalten gedrückt halten) des Mac auf und kann von dort aus gestartet werden oder man zwingt den Mac gleich in den Target-Mode (T beim Booten gedrückt halten), wodurch er sofort von FW bootet. Bei den ALT-Tasten könnte es bei PC-Tastaturen Problem geben. Zum Glück geht das auch aus der OF-Konsole heraus:

> multi-boot [Enter]
> target-mode [Enter]

Nun hat aber nicht jeder eine FW-HD zur Verfügung (wobei die Dinger meist auch noch recht klobig daherkommen). Wäre doch fein von USB. z. B. einer Platte oder Stick booten zu können, oder? Wobei der Stick natürlich in der Geschwindigkeit nicht mit einer HD mithalten kann - aber wenn man's nicht dauernd braucht, reicht's auch.
Fein, - nur blöderweise hat Apple scheinbar etwas dagegen. Es gibt keinen USB-Eintrag im Multiboot-Mode und auch keinen Target-Mode dafür! Allerdings haben sich die Apple-Systementwickler eine Hintertür in der OF offen gelassen, und durch die werden wir gehen.

Die OF stellt ja zu (fast) allen wichtigen Devices des Mac ein Alias mit dem zugehörigen Hardwarepfad zur Verfügung. Bei den neueren OF-Versionen klappert die OF die USB-Ports ab und schaut nach, ob da was lesbares steckt. Die OF erkennt HFS, HFS+ und FAT Datenträger. Wenn was da ist, wird ein logisches Device ud zu diesem Port angelegt. Ältere OF-Versionen machen das jedoch nicht und haben in Bezug zu Sticks auch noch gewisse Einschränkungen - dazu später.

Damit kann man von ud aus der OF-Konsole heraus booten was man will (wie der Datenträger partitioniert/formatiert und bespielt sein muss siehe Multiboot-Tutorial)!

Beispiel MorphOS:

> boot ud:,\boot.img ramdebug BD=USB_System [Enter]

Das lädt nun das boot.img (also den MorphOS-Kernel) vom Stick und startet dann das System vom Device USB_System (das ist der Device-Name des Sticks, wie er in HDConfig vergeben wurde - NICHT der Name beim Formatieren! Nach dem Namen kommt KEIN ":" ). Ramdebug lenkt die Debugausgabe ins RAM: um.

Beispiel OSX:

>boot ud:,\\:tbxi [Enter]

Das bootet MacOSX vom USB-Stick. Logischerweise dürft ihr den Stick niemals rausnehmen, solange das Betriebssystem aktiv ist (macht man nur einmal - dann fängt man mit dem Einrichten wieder von vorne an!)

Soweit so gut. Aber was macht man mit einem Mac der ud nicht anlegt? Da müssen wir uns dann die USB-Ports mit ihrer Hardwareadresse direkt ansehen - man muss den Richtigen zuerst einmal finden!

In der Tabelle der Devicealiase werden aber bei jedem Mac die USB-Ports aufgelistet (z.B. Powerbook 15")
pci0 /pci@f0000000 agp /pci@f0000000 pci1 /pci@f2000000 pci2 /pci@f4000000 uni-n /uni-n ui2c /uni-n/i2c ui2c-serial /uni-n/i2c/cereal keyboard /pseudo-hid/keyboard mouse /pseudo-hid/mouse sound /pseudo-sound eject-key /pseudo-hid/eject-key nvram /nvram enet /pci@f4000000/ethernet fw /pci@f4000000/firewire cpu0 /cpus/@0 cpu1 /cpus/@1 pci /pci@f2000000 usb-2a /pci@f2000000/@15 usb-2b /pci@f2000000/@15,1 usb-2c /pci@f2000000/@15,2 mac-io /pci@f2000000/mac-io@17 mpic /pci@f2000000/mac-io@17/interrupt-controller scca /pci@f2000000/mac-io@17/escc/ch-a sccb /pci@f2000000/mac-io@17/escc/ch-b ki2c /pci@f2000000/mac-io@17/i2c ki2c-serial /pci@f2000000/mac-io@17/i2c/cereal via-pmu /pci@f2000000/mac-io@17/via-pmu rtc /pci@f2000000/mac-io@17/via-pmu/rtc pi2c /pci@f2000000/mac-io@17/via-pmu/pmu-i2c wireless /pci@f2000000/mac-io@17/@30000 cb /pci@f2000000/cardbus@14 fan /uni-n/i2c/i2c-bus@0/fan usb0 /pci@f2000000/@15 usb1 /pci@f2000000/@15,1 usb2 /pci@f2000000/@15,2 hd /pci@f4000000/ata-6@d/disk@0 cd /pci@f4000000/ata-6@d/disk@1 first-boot /pci@f4000000/ata-6@d/disk last-boot /pci@f4000000/ethernet screen /pci@f0000000/ATY,JasperParent@10/ATY,Jasper_A@0

An der Adresse des PCI-Busses ( /pci@f2000000) hängen alle i/o-Geräte. Diese Firmware legt zumindest bereits fixe Adresspfade an - das macht es leichter. Das PB hat nur 2 USB-Ports. Der 3. und 4. ist intern verwendet (einer zur Kommunikation mit der AGP-GRA-Karte). Grundsätzlich muss man sich nun auf einen bestimmten Port beschränken - ich nehme immer den linken bei Powerbooks. Jetzt muss man rausfinden welcher (usb0, usb1, usb2, usb3) das ist. Am einfachsten gehts, wenn man einen Stick in den linken Port steckt und versucht den Inhalt zu lesen. Aber Achtung: manche OF-Versionen mögen keine Sticks mit >4GB und/oder für USB3 geeignete Sticks. Gut geht's mit einem älteren, FAT-formatiertem Stick. Diese Einschränkung gilt auch für USB-HDs: Es können meist nur Partitionen <2GB (bzw. <4GB) gelesen werden. Scheinbar wurden die neuesten Entwicklungen immer "on the fly" in die OF-Versionen eingepflegt. Bitte vorerst auch nur Sticks mit 1 Partion verwenden und irgendwelche Dateien aufspielen - das erleichtert das Suchen sehr.
Wichtig: Der Stick muss schon beim Einschalten eingesteckt sein - sonst sieht ihn die OF nicht und erkennt auch keinen Wechsel (interessantes "Feature" und sogar für was gut -> siehe weiter unten).
Also Stick einstecken, einschalten und in die OF-Konsole gehen und alle Ports ausprobieren:
>dir usb0/disk@1:,\ >dir usb1/disk@1:,\ >dir usb2/disk@1:,\

Und jetzt hoffen, das was angezeigt wird (hoffentlich das Verzeichnis) und nicht nur "no such device" ausgegeben wird. Kommt nur ein schlichtes "OK" zurück, ist da was, aber er kann's nicht lesen. Kommt "dir method failed" habt ihr einen Syntax-Fehler oder ihr versucht ein nicht lesbares Gerät auszulesen. Bei "can't open DIR device" steckt in dem Port nichts.
Im Fall dieses PB ist der linke Port usb0 (äquivalent zu usb-2a). Somit würde die Bootsequenz, analog zu oben, so aussehen (MorphOS):

> boot usb0/disk@1:,\boot.img ramdebug BD=USB_System [Enter]

Was aber, wenn gar kein USB-Eintrag in devalias auftaucht (auch das gibts)? Dann muss man sich den Hardware-Baum in der OF ansehen.
Das geht mit Eingabe von

> dev / ls [Enter]

Jetzt kommt folgende Liste (nur auszugsweise dargestellt, da sehr lange):
. ------ ------ ff9e0e30: /ATY,sensor-parent@3 ff9e0fe8: /gpu-sensor@6,0 ff97fed0: /pci@f2000000 ff9822b0: /mac-io@17 ff983740: /interrupt-controller@40000 ff9839b8: /gpio@50 ff983f78: /modem-reset@1d ------ ------ ------ ff9a11c0: /pci106b,4318@11 ff9a14a8: /cardbus@14 ff9a52e8: /usb@15 ff9e25a0: /disk@1 ff9e2988: /device@2 ff9e2b38: /keyboard@0 ff9e2e78: /mouse@1 ff9adc60: /usb@15,1 ff9e13b8: /device@1 ff9e15b0: /keyboard@0 ff9e18f0: /mouse@1 ff9e1c28: /device@2 ff9e1e48: /keyboard@0 ff9e2188: /mouse@1 ff9e2430: /interface@2 ff9b65d8: /usb@15,2 ff9810d8: /pci@f4000000 ff9b6af8: /ata-6@d ff9b9ce0: /disk ff9ba348: /firewire@e ff9c9a98: /ethernet@f ff9e4698: /ethernet-phy

Hier sieht man schon wo die USB-Ports liegen. Und man sieht auch gleich, das usb1 (usb@15,1) intern für Tastatur und Maus (Trackpad) verwendet wird.
Unser Pfad lautet jetzt:

> boot /pci@f2000000/usb@15/disk@1:,\boot.img ramdebug BD=USB_System [Enter]

Bitte beachtet das dieser Adresspfad hier nur exemplarisch (hier für ein 15" PB) ist, und bei eurem Mac ganz anders lauten kann!
 
Zuletzt bearbeitet:

Amigaharry

Kult Mitglied
Anlegen eines eigenen Devicealias:

Es wäre sehr mühsam das alles beim Booten jedes mal neu einzugeben. Ok, im textbasierten Bootmenü (siehe Tutorial Multiboot) wäre das zwar egal, aber es gibt noch andere Gründe dafür, ein eigenes Devalias anzulegen.
Dafür stellt die OF den Befehl devalias zur Verfügung:

> devalias ud /pci@f2000000/usb@15/disk@1

erzeugt nun das logische Device ud, welches auf den linken USB-Port zeigt - und zwar immer nur auf den linken Port. Man kann natürlich auch eine Forth-routine schreiben, die sich selber den belegten Port sucht und dann darauf ud erstellt, aber das ist nicht gerade ein kleiner Aufwand. In den neueren OF ist das (und einiges anderes) ja enthalten - deswegen sind sie auch schon 8MB groß (vergl.: das Kickstart am Amiga ist gerade einmal 512KB und mit allen Erweiterungen im RAM immer noch kein MB!)
In der Tabelle der Umgebungsvariablen (wir erinnern uns: > printenv ) sollte ud jetzt unten auftauchen.
Damit kann, ganz normal wie oben beschrieben, von ud gebootet werden.

Einen Haken hat die Sache aber noch: Das ist nicht permanent - nach dem Ausschalten ist es weg! Aber dafür gibts zum Glück das Non-Volatile-RAM (das ist NICHT das PRAM!). Und auch das ist von der OF aus erreichbar - sogar mit einfachem Editor. Allerdings muss man auf den meisten Macs das NV-RAM überhaupt erst einmal aktivieren. Das macht man wiederum mit einer Umgebunsvariable:

> setenv use-nvramrc? true

Dann noch einen Cold-Reboot. Damit ist es eingeschaltet. Jetzt müssen wir unser devicealias von oben, mittels dem eingbauten Editor da eingeben:

> nvedit ; Editor starten
devalias ud /pci@f2000000/usb@15/disk@1 ctrl+c ; Editor beenden
>nvstore ; permanent speichern

Zum Testen ohne Neustart:

> nvrun

Bei manchen PB (oder auch anderen Macs?) gibts Probleme beim Booten von OSX aus der OF-Konsole heraus - sie finden den Bootloader nicht, obwohl er tbxi-signiert ist. Diese Signatur kann man mit der Amiga startup-sequence vergleichen, nur das hier nicht der Name selbst zählt, sondern eine Art Protectionbit gesetzt wird. Die OF klappert dann die angegebene Partition nach so einem signierten File ab und startet es (so funktioniert auch die MOS-LiveCD bzw. die Auswahl von MorphOS im graphischen Multiboot-Menü).

Der für OSX zu startende Bootloader heist BootX und liegt in den Coreservices der OSX-Installation. Der direkte Aufruf lautet nun

boot ud:,\system\library\coreservices\bootx

Damit kommt der "Apfel" und der rotierende Wartering und dann sollte irgendwann auch der Finder auftauchen. Kann bei langsamen Sticks schon eine Weile dauern....
Und jetzt kommt die Geschichte mit dem permanent angelegten ud-Device zum Tragen: OSX erwartet, das von einem vorhandenem logischen Device gestartet wurde. Ein direktes booten über den Hardwarepfad mit

> boot /pci@f2000000/usb@15/disk@1:,\system\library\coreservices\bootx

ist zwar syntax- und logikmäßig richtig, führt aber nach kurzer Zeit zu einem Sperrsymbol am Bildschirm - und das wars dann. Es wird explizit das Booten von einem logischen Device vorausgesetzt, also so wie oben mit ud beschrieben. Ist logisch, wenn man weis, das der Kernel wärend des Hochfahrens Daten an das Device zurückschreibt.

Noch ein Wort zu den USB-Sticks: Ältere Macs sind unglaublich wählerisch. Viele Sticks waren nicht zur Zusammenarbeit zu bewegen, was vermutlich an der "Firmware" der Sticks liegt. So betrifft das fast immer Sticks, welche USB3-fähig waren (also zu "modern") oder auch manchmal wenn die Partitionen größer 4GB (FAT, HFS) waren. Für MacOSX müssen aber in jedem Fall Sticks in der Größe 16GB aufwärts verwenden, um eine vernünftige Minimalinstallation mit ein paar Arbeitsprogrammen, unterzubringen. Da aber so ein Stick bei der Installation gleich in HFS+ angelegt wird, entfällt die 4GB Grenze.

Es gibt noch einen Trick, um zumindest fürs Testen einen unwilligen Stick zum Arbeiten zu überreden. Man braucht dazu aber wenigstens einen anderen, funktionierenden Stick im selben Dateisystem. Die OF dieser alten Macs ist bei den USB-Ports scheinbar nicht sehr intelligent: Sie bemerkt einen Wechsel des USB-Sticks "on-the-fly" nicht. D.h. man steckt den funktionierenden Stick ein und bootet in die OF-Konsole. Dann wechselt man ihn gegen den nicht funktionierenden aus und hat plötzlich auch Zugriff darauf. Das eignet sich aber wirklich nur für Tests - sonst wird man zum "Stick-Jokey".


Booten von Netzwerk

Natürlich können die Macs auch von Netzwerk mittels tftp-Server gebootet werden (gibts für Amiga und MOS-Rechner im Aminet und natürlich auch für Windoof-und-was-weis-ich-noch-für-Kisten). Einfach auf einem weiteren Rechner den tftp-Server installieren, in dessen Root-Verzeichnis das boot.img des jeweiligen zu bootenden MAC kopieren.

boot enet:192.168.xxx.yyy, boot.img BD=USB_System Die IP ist die Adresse des Servers im Netz.

Diese Sequenz holt sich das Boot.img vom tftp-Server und muss aber dann von einem eingesteckten USB-Stick das MorphOS-System booten, da der MOS-Kernel keinen TCP/IP-Stack integriert hat. Wo der Stick steckt ist jetzt unerheblich - der MOS-Kernel, sobald aktiv, klappert alle Ports ab.
Leider ist mir kein install.img (wie beim Efika) bekannt, welches zum Kernel auch gleich eine minimale MOS-Umgebung mitlädt. Ich weis auch (noch) nicht, wie man so eines zusammenstellen kann.

Wie man MacOSX oder Linux via Netz booten kann ist in den jeweiligen Dokumentationen zum Betriebssystem enthalten. Dies ist nicht trivial, da hier nur minimale Systemumgebungen geladen werden können, von denen aus dann das System eingerichtet und installiert werden kann.

Noch ein Hinweis zu MacOS9, welches auf den G4 (G5?) auch noch läuft: Das parallel zu installieren und aufzurufen, ohne das es zu Problemen/Kollisionen kommt, ist eine ganz andere Nummer! Es gibt in den Weiten des Netzes viele Anleitungen und Hinweise zu OS9. Die Gefahr sich bei einem Multibootsystem, vielleicht noch auf einer Platte, das System zu zerschießen, ist aber groß!
Edit: Man kann mit MOS beginnen, aber gleich von Anfang an müssen alle Partionen für die verschiedenen OSe festgelegt werden. Dann kann man ein System nach dem anderen draufspielen.
Da unter OS9 die LiveCD nicht funktioniert, kann man das von OSX aus machen (https://www.mactechnews.de/forum/di...-auf-Mac-mini-G4-late-2005-booten-335943.html)

Pegasos (kombinierter Netzwerk/USB-Boot)

Der Pegasos kann nicht von USB booten. In einem Auszug des Hardwarebaums sind die Ports zwar sichtbar, aber können nicht angesprochen werden.

Auszug aus device-tree des PEG2 (SmartFirmware V1.3):
------------------- >cd /pci@80000000 >ls host@0 firewire@1 isa@C ide@C,1 usb@C,2 usb@C,3 other@C,4 sound@C,5 pci1106,3068@C,6 ethernet@D ok .properties name "pci" device_type "pci" #address-cells 0x3 (3) #size-cells 0x2 (2) clock-frequency 0x1FCA055 (33333333) ranges [0x30 bytes] [000] 01000000 00000000 00000000 FE000000 [010] 00000000 00010000 02000000 00000000 [020] 80000000 80000000 00000000 40000000 8259-interrupt-acknowledge 0xF1000CB4 (-251654988) reg 80000000:40000000 pci-bridge-number 0x0 (0) bus-range 0:1 -------------------

Man kann zeigen, das die Adressen stimmen und auch am Port was erkannt wird, aber es kann, aus welchen Gründen auch immer, nicht gelesen werden. Vermutlich ist für die USB-Ports kein Filesystem vorhanden (obwohl das zuständige "deblocker-package" zumindest vorhanden ist). Jedenfalls konnte ich bisher keinen Datenträger zum Laufen bringen (SFS, FFS, FAT) - gäbe also noch viel zu tun......

Hat man sich aus dem Peg hinausgesperrt (z.B. System zerschossen) und zudem noch ein defektes DVD, ist guter Rat teuer (ist mir passiert). Gut, man kann jetzt eine HD an einem anderen Rechner einrichten und einbauen oder das defekte DVD wechseln. Aber natürlich passiert sowas immer am Samstagabend und wenn gerade kein 2. MorphOS-Rechner verfügbar ist und ich hatte auch keinen Bock das Ding wieder einmal zu zerlegen. Wenn man sich allerdings die "packages" im Devicetree der OF genauer ansieht, sticht einem sofort das tftp-Package ins Auge. Und ein weiterer Blick in die Devicealiase zeigt ein logisches Device eth. Na, damit lässt sich schon einmal was machen - nämlich den Kernel von MorphOS laden und starten. Und sobald der MOS-Kernel aktiv ist, werden auch sämtliche USB-Ports aktiviert und erkannt. Damit kann man dann dort mit einem USB-Stick weiterbooten. Da man bei einem Netboot dem Kernel keine Argumente mitgeben kann (also z.B. BD=USB_System oder BM), muss dieser Stick allerdings eine hohe Bootpriorität haben, damit er auf jeden Fall zuerst gebootet wird (also Prio 20). Jetzt sollte auch klar sein, warum man so nicht von einem ISO-Abbild booten kann.
Bemerkung: BM würde übrigends das Early-Startup-Menü, ähnlich wie beim Amiga, aufrufen. Es sollte auch durch drücken einer SHIFT-Taste, von F1 (nur PS2 Tastatur) oder der linken Maustaste (nicht Mac) aufrufbar sein, klappt aber bei der Vielfalt an Tastaturen/Mäusen nur selten.

Also analog zum Mac oben bootet man von einem tftp-Server mit

> boot eth:192.168.xxx.yyy, boot.img IP ist wieder Server-IP.

Dann startet der Kernel und bootet vom eingesteckten Stick weiter.

Für Linux gibt's sog. Installationsimages, welche den Kernel und eine minimale Installationsumgebung enthalten. Diese kann analog gebootet werden. Anleitung dazu bei der jew. Distributions-Dokumentation.
 
Zuletzt bearbeitet:

Amigaharry

Kult Mitglied
EFIKA (USB und Netzwerkboot)

Auch am EFIKA wird Netzwerk -Boot (von tftp-Server) direkt von der Firmware und MorphOS unterstützt und zwar mit einem Install.img:

> boot eth:192.168.xxx.yyy, install.img Die IP ist wieder die Server-IP.

So einfach kann's auch gehen! Naja, jedenfalls fast. Das Install.img kann man mittlerweile nicht mehr von der MorphOS-Webseite runterladen (wer's braucht -> PN), statt dessen gibts ein SD-Card/USB-Image. Dieses erzeugt aber nur mittels Windoof-PC eine bootfähige MOS-Installation auf einem USB-Stick - macht Sinn, wenn man keinen anderen MOS-Rechner hat. Diese ist aber 400MB groß (also das volle ISO) und würde sowieso nicht ins RAM des EFIKA passen - für Netboot also zu vergessen.
Jedenfalls lädt das install.img den Kernel und eine kleine, rudimentäre MOS-Umgebung (nur 12MB!!) zum weiteren Einrichten/Installieren.

Aber auch von USB gehts einfach - und da kann man eine komplette Installation hochfahren:

<boot hd0:0 boot.img BD=Stick ; Stick muss in einem der beiden USB-Ports, direkt am Board stecken (keinem externen HUB)

Jetzt ist es aber so, das der EFIKA nicht gerade mit Ports gesegnet ist und man ziemlich sicher einen Hub verwenden wird. Aber auch das kann die Firmware des EFIKA abbilden. Anbei ein Beispiel mit einem zusätzlichem 4-fach-HUB am internen Port 1, in dem ein HID-Interface für eine Funkmaus, ein 16GB Datenstick und dann noch der Bootstick stecken. Am internen Port 2 steckt eine USB-Kabeltastatur.

Efika_ENV.jpg

Erklärung:

ide und hd (wieder äquivalent): interne HD
(usb) keyboard ist selbsterkärend am 2. internen Port
Dann der hub@1 am 1. Port (scsi@1 ist die Maus und taucht hier nicht auf - wird ja in der OF nicht unterstützt)
scsi und hd0 zeigen auf den 16GB Datenstick (-> scsi@2)
scsi0 und hd1 zeigen auf den Bootstick (->scsi@3)
eth und screen sind selbsterklärend bzw. interessieren hier nicht.
Btw: Wäre am 2. internen Port nicht ein Keyboard, sondern ein Datenträger eingesteckt, bekäme er die Adresse scsi@0

Hier würde man mit

> boot hd1:0 boot.img BD=USB_System

booten. Auf dem Stick ist in dem Fall nur eine SFS-Partition mit dem Namen USB_System, in der boot.img und MOS-System abgelegt sind.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Das war ein kleiner Exkurs in die Möglichkeiten der OpenFirmware (SmartFirmware) zu den nicht so üblichen Bootdevices.
Da es vermutlich noch einige Firmwareversionen (beim MAC) da draussen geben wird, die sich noch mehr anders als die hier beschriebenen verhalten, kann dieses Tutorium naturgemäß nicht alle Eventualitäten abdecken. Sollte also sowas auftauchen, wäre es wünschenswert, wenn hier darüber berichtet werden würde.

In dem Sinne:

========================================= Remember, when computing was fun? =============================================


Wer Rechtschreibfehler gefunden hat, darf sie behalten. Inhaltliche Fehler bitte melden!
 
Zuletzt bearbeitet:
Oben