Zum Inhalt

Festplatten sichern mit BasicLinux (Hands-on)

📅 Erstellt: 20.08.2026 🔄 Aktualisiert: 01.09.2026

Hands-on Beitrag

Dies ist ein "Hands-on" Beitrag. Ich erarbeite mir hier die Lösung von Problemen Schritt für Schritt und beschreibe damit - meist chronologisch - den Ablauf. Das ist didaktisch nicht immer sinnvoll, erzählt aber eine "Story" und den Werdegang, auf dem es rechts und links auf Abwegen immer wieder was neues zu lernen gibt.
Der Beitrag unterscheidet sich also von einer kompakten, auf das Wesentliche reduzierte, logisch und didaktisch sinnvollen Anleitung! Eine eventuelle Aufarbeitung werde ich erst erstellen können, wenn ich alle Fallstricke und Sackgassen kenne. Bis dahin soll aber auch dieses Wissen hier nicht verloren gehen.

Ich beschreibe hier eine Sicherung einer ATA1-Platte, 102 MB, noch mit C/H/S angegeben aus einem Highscreen KOMPAKT Serie III 386-SX. Dort sind noch Central Point Software Programme, diverse Highscreen/Vobis eigene Programme drauf, die ich zur "Preservation" gerne sichern möchte bevor ich damit weiter rumgurke.

Da mein Ugreen USB -> IDE Adapter erst ab ATA-2/LBA-Standard mit IDE-Festplatten klarkommt kann ich am modernen PC nicht auf die alte IDE-Festplatte zugreifen und sie nicht direkt sichern.

Die besagte ATA1-Platte habe ich also einfach mal in meinen IBM Aptiva 486 gesteckt, am CD-ROM IDE Kabel anstatt angeschlossen. Das proprietäre BIOS des 486 konnte damit nichts anfangen. fdisk aus MS-DOS 6.22, sowie von FreeDOS ebenfalls nichts.
Einzig EZ-Drive hat die Platte zumindest sehen können, habe hier aber nicht weiterverfahren, da dies nicht zerstörungsfrei möglich gewesen wäre.

Also das Szenario ist: Die alte ATA1-Platte -> 486er eingebaut und auf dem 486er BasicLinux 3.50 Floppy Version gestartet.

Bezugsquelle

Von BasicLinux gibt es eine DOS-Version und eine Floppy-Version:

Ich habe beide Versionen probiert.

Floppy Version

Die Floppy-Version habe ich auf einen DOS-Rechner kopiert und von dort aus die Disketten erstellt nach deren Anleitung.

Erstellung

  1. Zwei Floppies in DOS erstmal formatiert mit: format a: /u um auch zu prüfen, ob die Disketten reibungslos formatieren
  2. Auf die zweite Floppy die DISK2.TGZ aus dem Floppy-Version Archiv raufkopiert
  3. Die erste Floppy mit fdimage disk1.img a:
  4. Den Rechner neustarten mit Diskette 1 zum Booten, eine Meldung erscheint wenn Diskette 2 eingelegt werden soll

Sicherung der Quellfestplatte

  1. Dann ist man auch bald im Linux-Prompt. Dort erstelle ich mir auf /mnt erstmal Verzeichnisse zum Mounten der DOS-Partition auf die ich sichern möchte: mkdir -p /mnt/aptiva_c
  2. Mit fdisk -l finde ich heraus wie die Partitionsschemen der Platten sind.
  3. Dann mounte ich - in meinem Fall /dev/hda1 - auf eben erstelltem Mountpunkt: mount -t vfat /dev/hda1 /mnt/aptiva_c
  4. Ich prüfe den Inhalt: cd /mnt/aptiva_c && ls -lah
    41b015870b3b82e169fa41b6d4f4004f.png
  5. Ist hier alles klar kann ich auch schon die Quellfestplatte sichern.
  6. Das mache ich einfach mit dd und zwar mit: dd if=/dev/hdc of=st3120.img bs=64k
  7. Nach ein paar Minuten ist der Prozess durch und ich prüfe mit ls -lah das fertige Image. 102 MB, passt.
    a6846eb8ffa6902818a1fa1f97eb3415.png
  8. Danach reboot eingeben, Diskette entfernen und wieder in DOS starten.
  9. Ich nutze Windows 3.x für TCP/IP Netzwerk und Ordnerfreigabe, daher starte ich auch Windows.
  10. Mit Linux verbinde ich mit altem SMB1 Protokoll auf den Windows 3.x Rechner und ziehe mir das Image runter.
    ❯ smbclient //IBM486/ARCHIVE -I 192.168.178.40 -N -p 139 --option="client min protocol=CORE" --option="client max protocol=LANMAN2"
Try "help" to get a list of possible commands.
smb: \> get st3120a.img
getting file \st3120a.img of size 106954752 as st3120a.img (713,1 KiloBytes/sec) (average 713,1 KiloBytes/sec)
smb: \>

Mit PeaZip öffne ich die .img Datei und siehe da:
4e6ed5ae8a7f4e1464e2bf9d4e1f36f5.png
Wunderbar!

DOS Version

Ja... RTFM gilt hier. Der Ordnername MUSS C:\BASLIN heißen. Bei weniger als 8 MB RAM muss Auslagerungsspeicher aktiviert werden, dazu muss zusätzlich die swap.zip (im o.g. Ordner) entpackt werden.

Es wird ein "relatively clean DOS" erwartet, d.h. keine CONFIG.SYS, keine AUTOEXEC.BAT starten. Mit F5 kann man übrigens die Startsequenz bei MS-DOS überspringen.

Netzwerk

Netzwerk wird unterstützt indem man die Datei /root/netsetup seinen Gegebenheiten anpasst und dann ausführt.
Hier ein Beispiel:

insmod 3c509
udhcpc

In meinem Aptiva ist derzeit eine 3com Etherlink III verbaut (3c509). Ein Modul dafür ist aber standardmäßig nicht vorhanden, also werde ich es mir für Kernel 2.2.26 i386 extern besorgen müssen, auf die DOS Partition kopieren und von dort ins Linux System ins Verzeichnis /lib/modules/2.2.26/net:

mkdir -p /lib/modules/2.2.26/net
cp /DOS/pfad/zu/3c509.o /lib/modules/2.2.26/net

Ich brauche also defintiv ein Modul passend zu Kernel 2.2.26. Habe ich bisher nicht gefunden, aber das Modul für Kernel 2.2.16 aus Slackware 7.1 scheint zu funktionieren! Das habe ich hier besorgt: 3c509.o - 3c509.o

Wenn das Internet nun funktioniert kann man sich Pakete aus z.B. Slackware 4.0 installieren. Eine Mirrorliste findet sich hier: Slackware Mirrorlist
Aktuell (20.08.2026) funktioniert hier beispielsweise der ungarische HTTP-Mirror. Eine Liste aller Dateien für z.B. Slackware 4.0 befindet sich in der FILELIST.TXT

Die Pakete können mit dem Links Textbrowser heruntergeladen werden. Ich habe mir in meinem Heimverzeichnis ~, entspricht /root den Ordner software angelegt, dort speichere ich heruntergeladene Pakete.
Mit links also den Browser starten und Taste G lässt einen Link eingeben: http://mirror.slackware.hr/slackware/
Hat man Pakete heruntergeladen lassen sie sich per: pkg <paketname.tgz> installieren.

Hinweis für 386er Nutzer

Auf meinem 386SX funktionierte das Netzwerk mit Bordmittel udhcpc nicht, wahrscheinlich eine CPU-Diskrepanz, dass neuere Busybox und/oder die mitgelieferten Binaries nicht mehr alle abwärtskompatibel zur i386-Architektur sind.
Ich habe daher aus Slackware 4.0 die beiden Pakete tcpip1.tgz und tcpip2.tgz installiert. Sowie ein 2.2.19 no-smp3c509.o Modul. Da dd auch nicht geht, brauchen wir auch noch fileutls.tgz. Netcat will auch nicht, also auch das noch. Das habe ich in einer qemu-VM mit Original Slackware 4.0 selbst gebaut aus 1.10 Quellen...
Mit insmod 3c509 und Aufruf von dhcpcd ohne Optionen hat es funktioniert eine IP-Adresse zu ziehen und ins LAN und Internet zu kommen.
Ich habe außerdem noch ein Paket Kernelmodule für Netzwerkkarten gefunden: netmods.tgz.
Files: 3c509.o - tcpip1.tgz - tcpip2.tgz - fileutls.tgz - netmods.tgz - nc
Sollte das mit dhcpcd nicht klappen, kann man noch versuchen /etc/rc.d/rc.inet* zu löschen, ggf. vorher sichern.
In der /etc/rc folgendes eintragen: insmod 3x509, rm /var/run/dhcpcd-eth0.pid.
Danach sollte mit Aufruf von dhcpcd eine IP-Adresse gezogen werden und die 3Com unter eth0 auto-konfiguriert sein.
Es erscheint dann: eth0: Setting Rx mode to 1 addresses.
Das ist ein DIRTY FIX auf die schnelle, das kann und muss man ggf. anders und detaillierter konfigurieren. Hier heiligt aber der Zweck die Mittel.

Beispiel Workflow "deutsche Tastaturbelegung"

Ich schaue mir im Slackware 4.0 Verzeichnis in docs die Dokumentation Keyboard-and-Console-HOWTO an und stelle fest:

1.  Useful programs

  The following packages contain keyboard or console related programs.

  kbd-0.95.tar.gz contains loadkeys, dumpkeys, showkey, setmetamode,
  setleds, setfont, showfont, mapscrn, kbd_mode, loadunimap, chvt,
  resizecons, deallocvt, getkeycodes, setkeycodes.

Also ab geht's in die FILELIST.TXT und mit / (Slash) starten wir die Suche nach kbd.tgz (für das Binarypackage). Das liegt in a8, also auf in a8 und kbd.tgz herunterladen und später in der Shell mit pkg kbd.tgz installieren.
Jetzt mit loadkeys de-latin1-nodeadkeys die deutsche Tastaturbelegung aktivieren.

Tipp: Zum automatischen Laden beim Start von BasicLinux kann diese Zeile in /etc/rc eingetragen werden.

Sicherung einer Festplatte

Über Netzkatze 😺 - auf dem Ziel-PC zuerst starten (lauscht), dann den Prozess auf dem Quell-PC anstoßen.

Ziel-PC: nc -l -p 31337 | pv > festplatte.img
Quell-PC: dd if=/dev/hdc bs=64k | nc 192.168.178.X 31337

Ich musste auf meinem (Ziel-)PC noch den Port in der Firewall freigeben: sudo ufw allow 31337/tcp.

Und der Prozess läuft:
748262d28c592643dde303f3e3fca33d.png

Kleiner Exkurs DD Raw Image vs .VHD

Um die 386SX HDD ST3120A bequem zu bespielen habe ich eine Festplatte in 86Box erstellt mit den gleichen Parametern C/H/S 1027/12/17 ≈ 102 MB. Sogar das exakte Modell war auswählbar: [ATA-1] Seagate ST3120A.
Leider habe ich übersehen, dass man auch ein Rohdatenabbild (.IMG) hätte machen können, daher wurde es ein .VHD Container mit fester Größe.

Nunja, dafür können wir jetzt einen kleinen Exkurs machen, wie .VHD aufgebaut ist und ob/wie man das per DD wieder zurückschreibt auf Echt-Hardware.

VHD-Format

VHD (Virtual Hard Disk) ist ein Containerformat ursprünglich von Microsoft Virtual PC für virtuelle Festplatten als Abbild. Der Container enthält als "Fixed hard disk Image" (feste Imagegröße) 1:1 die Daten wie z.B. von DD einer echten Festplatte übertragen PLUS 511 bzw. 512 Bytes Metadaten am Ende der Datei.
Quelle: Wikipedia-EN

Hier das Format des Footer im VHD-Container:
dfd6cb0af92057958031469191f6d990.png
Quelle: Microsoft Corporation. 11 October 2006. - Virtual Hard Disk Format Spec_10_18_06.doc

Files:
* Virtual Hard Disk Format Spec_10_18_06.pdf
* Virtual Hard Disk Format Spec_10_18_06.doc

DD vs VHD die Dateien im Detail

Mit eza -lB können Dateien in Bytegröße angezeigt werden:

.rwxr-xr-x   106.954.752 marquisor 20 Aug 01:03 st3120a.img
.rw-r--r--   106.955.264 marquisor 22 Aug 15:02 ST3120A.VHD

Die .img ist die Originalsicherung der echten ST3120A und die .VHD das in 86Box erstellte Äquivalent.

Das Ende

Schauen wir uns die letzten 512 Bytes der VHD-Datei ST3120A.VHD also mal an:

❯ tail -c 512 ST3120A.VHD | xxd
00000000: 636f 6e65 6374 6978 0000 0002 0001 0000  conectix........
00000010: ffff ffff ffff ffff 321a 01e7 6d56 4844  ........2...mVHD
00000020: 000e 0000 5769 326b 0000 0000 0660 0000  ....Wi2k.....`..
00000030: 0000 0000 0660 0000 0400 0c11 0000 0002  .....`..........
00000040: ffff e6ed 479b ff9f c183 426f 9437 b72a  ....G.....Bo.7.*
00000050: 32c5 ffc6 0000 0000 0000 0000 0000 0000  2...............
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
000001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

Das sind die Metadaten des VHD-Containers. Irrelevant für ein echtes Rohabbild (.img).
Kann also weg.

Schauen wir den Übergang (Offset 000001ff) an, die letzten 1024 Bytes der VHD-Datei ST3120A.VHD:

❯ tail -c 1024 ST3120A.VHD | xxd
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
000001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000200: 636f 6e65 6374 6978 0000 0002 0001 0000  conectix........
00000210: ffff ffff ffff ffff 321a 01e7 6d56 4844  ........2...mVHD
00000220: 000e 0000 5769 326b 0000 0000 0660 0000  ....Wi2k.....`..
00000230: 0000 0000 0660 0000 0400 0c11 0000 0002  .....`..........
00000240: ffff e6ed 479b ff9f c183 426f 9437 b72a  ....G.....Bo.7.*
00000250: 32c5 ffc6 0000 0000 0000 0000 0000 0000  2...............
00000260: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
000003f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

Alles 0000, also unkritisch.

Schauen wir das Ende des Rohabbilds der echten Festplatte an st3120a.img:

❯ tail -c 512 st3120a.img | xxd
00000000: 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c  llllllllllllllll
00000010: 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c  llllllllllllllll
...
000001f0: 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c  llllllllllllllll

Auch nix wichtiges, aber hätte ja sein können...

Der Anfang

Aus reinem Interesse schauen wir mal auf den Anfang der VHD-Datei und des Rohdatenabbildes.

Der Anfang der VHD-Datei ST3120A.VHD:

❯ head -c 1024 ST3120A.VHD | xxd
00000000: fa33 c08e d0bc 007c 8bf4 5007 501f fbfc  .3.....|..P.P...
00000010: bf00 06b9 0001 f2a5 ea1d 0600 00be be07  ................
00000020: b304 803c 8074 0e80 3c00 751c 83c6 10fe  ...<.t..<.u.....
00000030: cb75 efcd 188b 148b 4c02 8bee 83c6 10fe  .u......L.......
00000040: cb74 1a80 3c00 74f4 be8b 06ac 3c00 740b  .t..<.t.....<.t.
00000050: 56bb 0700 b40e cd10 5eeb f0eb febf 0500  V.......^.......
00000060: bb00 7cb8 0102 57cd 135f 730c 33c0 cd13  ..|...W.._s.3...
00000070: 4f75 edbe a706 ebd3 becd 06bf fe7d 813d  Ou...........}.=
00000080: 55aa 75c7 8bf5 ea00 7c00 0055 6e67 816c  U.u.....|..Ung.l
00000090: 7469 6765 2050 6172 7469 7469 6f6e 7374  tige Partitionst
000000a0: 6162 656c 6c65 0046 6568 6c65 7220 6265  abelle.Fehler be
000000b0: 696d 204c 6164 656e 2064 6573 2042 6574  im Laden des Bet
000000c0: 7269 6562 7373 7973 7465 6d73 0042 6574  riebssystems.Bet
000000d0: 7269 6562 7373 7973 7465 6d20 6665 686c  riebssystem fehl
000000e0: 7400 0000 0000 0000 0000 0000 0000 0000  t...............
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
000001c0: 0100 060b d1fe 1100 0000 232f 0300 0000  ..........#/....
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.
00000200: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000210: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
000003f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

Der Anfang des Rohabbilds der echten Festplatte st3120a.img:

❯ head -c 1024 st3120a.img | xxd
00000000: fa33 c08e d0bc 007c 8bf4 5007 501f fbfc  .3.....|..P.P...
00000010: bf00 06b9 0001 f2a5 ea1d 0600 00be be07  ................
00000020: b304 803c 8074 0e80 3c00 751c 83c6 10fe  ...<.t..<.u.....
00000030: cb75 efcd 188b 148b 4c02 8bee 83c6 10fe  .u......L.......
00000040: cb74 1a80 3c00 74f4 be8b 06ac 3c00 740b  .t..<.t.....<.t.
00000050: 56bb 0700 b40e cd10 5eeb f0eb febf 0500  V.......^.......
00000060: bb00 7cb8 0102 57cd 135f 730c 33c0 cd13  ..|...W.._s.3...
00000070: 4f75 edbe a706 ebd3 becd 06bf fe7d 813d  Ou...........}.=
00000080: 55aa 75c7 8bf5 ea00 7c00 0055 6e67 816c  U.u.....|..Ung.l
00000090: 7469 6765 2050 6172 7469 7469 6f6e 7374  tige Partitionst
000000a0: 6162 656c 6c65 0046 6568 6c65 7220 6265  abelle.Fehler be
000000b0: 696d 204c 6164 656e 2064 6573 2042 6574  im Laden des Bet
000000c0: 7269 6562 7373 7973 7465 6d73 0042 6574  riebssystems.Bet
000000d0: 7269 6562 7373 7973 7465 6d20 d094 a71a  riebssystem ....
000000e0: 7400 0000 0000 0000 0000 0000 0000 0000  t...............
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
000001c0: 0100 060b d1fe 1100 0000 232f 0300 0000  ..........#/....
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.
00000200: 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c  llllllllllllllll
00000210: 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c  llllllllllllllll
...
000003f0: 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c  llllllllllllllll

Der ultimative Vergleich

Der Vergleich geht auch wesentlich komfortabler mit vbindiff:
527310aeea1a9b07b06e26474eb3dbeb.png
4 Bytes Unterschied, warum gerade das Wort fehl, ich habe keine Ahnung, soll mir aber auch egal sein.

Quintessenz

Da am Ende der VHD-Datei 512 Bytes Metadaten sind, beim Übergang keine Daten, beim Image der echten Platte auch nix wichtiges und überhaupt aus Prinzip der Sache der 1:1 Kopie mit DD über netcat gestreamt nicht mehr Daten geschrieben werden können als Platz auf dem Ziel ist:
Die Daten aus der Datei ST3120A.VHD können mit DD exakt wie ein Rohabbild auf die Original Festplatte übertragen werden.

Mal was abschneiden

Da mein innerer Monk damit aber unzufrieden ist, und wir noch was lernen wollen, kopieren wir jetzt die VHD-Datei in eine .img-Datei und schneiden einfach 512 Bytes ab.

Datei kopieren:
cp ST3120A.VHD st3120a_to_386sx.img

512 Bytes abschneiden:
truncate -s -512 st3120a_to_386sx.img

Ergebnis:

 106.954.752 st3120a.img        (Original)
 106.955.264 ST3120A.VHD        (Neu bespielt)
 106.954.752 st3120a_to_386sx.img   (Kopie der neu bespielten, 512 Bytes abgeschnitten)

Ja? Wurde wirklich das Ende abgeschnitten? Überprüfen wir den Kopf:

❯ head -c 512 st3120a.img | xxd
00000000: fa33 c08e d0bc 007c 8bf4 5007 501f fbfc  .3.....|..P.P...
00000010: bf00 06b9 0001 f2a5 ea1d 0600 00be be07  ................
00000020: b304 803c 8074 0e80 3c00 751c 83c6 10fe  ...<.t..<.u.....
00000030: cb75 efcd 188b 148b 4c02 8bee 83c6 10fe  .u......L.......
00000040: cb74 1a80 3c00 74f4 be8b 06ac 3c00 740b  .t..<.t.....<.t.
00000050: 56bb 0700 b40e cd10 5eeb f0eb febf 0500  V.......^.......
00000060: bb00 7cb8 0102 57cd 135f 730c 33c0 cd13  ..|...W.._s.3...
00000070: 4f75 edbe a706 ebd3 becd 06bf fe7d 813d  Ou...........}.=
00000080: 55aa 75c7 8bf5 ea00 7c00 0055 6e67 816c  U.u.....|..Ung.l
00000090: 7469 6765 2050 6172 7469 7469 6f6e 7374  tige Partitionst
000000a0: 6162 656c 6c65 0046 6568 6c65 7220 6265  abelle.Fehler be
000000b0: 696d 204c 6164 656e 2064 6573 2042 6574  im Laden des Bet
000000c0: 7269 6562 7373 7973 7465 6d73 0042 6574  riebssystems.Bet
000000d0: 7269 6562 7373 7973 7465 6d20 d094 a71a  riebssystem ....
000000e0: 7400 0000 0000 0000 0000 0000 0000 0000  t...............
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...

Passt.

Zurück zum Original

Die Datei kopiere ich dann jetzt mit umgekehrter Methode - Netzkatze 😺 - wieder zurück.

Ich baue die Platte wieder an den 2. IDE-Kanal des 486er:
IDE-Kabel vom 486er CD-ROM abgeklemmt -> HDD angeklemmt, Strom nicht vergessen!
DOS des 486 starten, Startdateien umgehen mit F5 und BasicLinux von DOS aus booten.

In Linux lade ich die deutsche Tastaturbelegung:
loadkeys de-latin1-nodeadkeys

Sowie den Netzwerktreiber (Kernelmodul) und den DHCP-Client:
insmod 3c509
udhcpc

Mit ifconfig finden wir die IP-Adresse des 486ers raus: 192.168.178.40.
Und mit fdisk -l überprüfen wir nochmal welche Festplatte wir hier beschreiben wollen.

ACHTUNG

Hier unbedingt darauf achten, die korrekte Platte zu wählen, sonst wird die Bootfestplatte des 486er überschrieben!

Diesmal netcat auf dem 486, das ist jetzt der Ziel-PC zuerst starten (lauscht), dann den Prozess auf dem Quell-PC anstoßen.

Ziel-PC: nc -l -p 31337 > /dev/hdc
Quell-PC: dd if=st3120a_to_386.img bs=64k | nc 192.168.178.40 31337

Diesmal gibt es leider keine Progress-Anzeige, pv hab ich auf dem 486er Linux nicht, das hier soll als Bild reichen:
803a88b76909b0ac3126cdf57bde4710.png

Der Sende-PC vermeldet nach ca. 10 Minuten:

❯ dd if=st3120a_to_386sx.img bs=64k | nc 192.168.178.40 31337
1632+0 Datensätze ein
1632+0 Datensätze aus
106954752 Byte (107 MB, 102 MiB) kopiert, 572,172 s, 187 kB/s

Feddich.

Auf dem 486er beenden wir jetzt auch den Lauscher, dazu drücken wir jetzt Strg+C und führen zweimal sync aus und damit ist das Image jetzt wohl auf der 386er Platte.

Prüfung

Auch hier können wir wieder prüfen, was am Anfang und Ende der Platte ist.

Die Macht der Quersumme

Oder: Wir machen eine Stichprobe.
Da auf dem 486er nur eine rudimentäre Busybox-Umgebung läuft sind die Befehle sehr begrenzt. head und tail gibt es zwar, ist aber ohne einen Hexdumper wie xxd oder hexdump nicht sinnvoll nutzbar. Es zerstört sogar die Kommandozeile, da Sonderzeichen ausgegeben werden ohne die Pipe an entsprechendes Programm.

Daher nehmen wir folgenden Trick, wir nehmen einfach die ersten XXXX Bytes und vergleichen die Quersumme.

Auf dem 486er (die ersten 1024 Bytes):
dd if=/dev/hdc bs=1024 count=1 | md5sum:

1+0 records in
1+0 records out
2ace894a4702d3ef9bb2b90096e94712 -

Auf dem Quell-PC:
dd if=st3120a_to_386sx.img bs=1024 count=1 | md5sum

1+0 Datensätze ein
1+0 Datensätze aus
1024 Byte (1,0 kB, 1,0 KiB) kopiert, 5,2651e-05 s, 19,4 MB/s
2ace894a4702d3ef9bb2b90096e94712  -

Das geht natürlich auch mit 1 MB usw., habe ich geprüft, gleiche MD5 472070b42ea6413ecfde77950fecefc0.

Gut, zusammenpacken, Ende!

/<#>poweroff
The system is going down NOW !!
Sending SIGTERM to all processes.
Sending SIGKILL to all processes.
The system is halted. Press Reset or turn off power
Power down.

b279b22bd2036364a1add5c04a0f44d9.png

Ob die Festplatte dann im 386SX läuft werde ich die Tage sehen. Jetzt mache ich mir erstmal ein Bier auf. Prost!

Einen Tag später...

Ja, es hat geklappt! Die Festplatte hat im 386SX auf Anhieb gebootet und auch Scandisk lief fehlerfrei durch. 👍

Image auf einen größeren Datenträger bringen (DOS)

Achtung

Das BIOS des Zielrechners MUSS mit der Größe des neuen Datenträgers umgehen können, sonst ist die folgende Anleitung hinfällig! Es wird früher oder später zu Datenverlust kommen. Vgl. Noch ein Kommentar zur 504 MB-Grenze
Ist das nicht der Fall MUSS eine Software wie Ontrack Disk Manager oder EZ-Drive für ein Dynamic Drive Overlay verwendet werden, um die BIOS-Grenzen aufzuheben.

Szenario: Ich habe von einer 540MB ein DD Rawimage gezogen, welches ich ggf. nach Bearbeitung in 86box auf einen anderen, größeren Datenträger überspielen möchte. Hier habe ich eine 2 GB MicroSD-Karte ausgewählt. Die macht wenigstens keinen Lärm. Die betreibe ich dann in einem IDE -> SD-Adapter.

Das ganze ohne viel nachzudenken, erstmal die 540 MB auf die mSD-Karte bringen:
dd if=ST3660A_386SX.img of=/dev/sdf bs=4M status=progress conv=fsync

Jetzt kommen wir aber schon zu einer Eigenart von MS-DOS, das oben genannte DD Rawimage ist eine primäre Partition mit Laufwerk C:.
Eine weitere primäre Partition (wie in anderen Betriebssystemen wie Win9x+ oder Linux) wird von MS-DOS kein Laufwerksbuchstabe zugewiesen.
Ich muss dafür - wie in alten Zeiten - erstmal eine erweiterte Partition anlegen und darin eine logische Partition, die dann von MS-DOS den Laufwerksbuchstaben D: erhält.

Wir starten cfdisk /dev/sdX - bei mir momentan /dev/sdf - und schauen uns das mal an:
3a5bdc658354aa620108570178bbbb99.png
Beim freien Bereich eine "Neue" Partition erstellen, Partitionsgröße in dem Fall 1,3G automatisch festgelegt = der ganze Rest der mSD-Karte und wählen danach "Erweitert" - Container für logische Partitionen aus.
Dann ergibt sich ein weiterer freier Bereich:
2a58dfc2f7a8b760cb7bbab1fd79f5ef.png
Auch hier wieder eine "Neue" Partition erstellen mit maximaler Größe (1,3G), Partitions-Typ 6 (FAT16) und "Schreiben" das ganze auf die Platte:
2066e26c6d414bfe754c02f99a9cd328.png
Mit yes bestätigen und dann auf "Ende".
Jetzt kann die Karte verwendet werden.

Ein Kommentar zu Flashspeicher und Misalignment

Ich habe jetzt eine mSD-Karte, also einen Flashspeicher verwendet. Diese richtet man auf Grund ihrer Schreibtechnik exakt an Sektorgrenzen - 8 x 512 Bytes = 1 Page - aus. Da hier aber bereits eine "krumme" Verschiebung vorliegt (Start bei Sektor 63 - Page 8) und eine Größenveränderung und/oder ein Verschieben der Partition auf Grund von MS-DOS Eigenheiten ungünstig wäre, belassen wir es dabei.

Technisches Geplänkel

Der alte DOS-Standard lässt Laufwerk C: bei Sektor 63 (31,5 KiB) beginnen. Modernes Flash-Speichermedium (wie z.B. eine mSD-Karte) ist intern jedoch in 4-KiB-Blöcken (Pages) organisiert.
Da Sektor 63 (\(63 \times 512 = 32{.}256\)) nicht glatt durch 4 KiB (\(32{.}256 \div 4{.}096 = 7{,}875\)) teilbar ist, verschiebt sich das Raster: Jeder 4-KiB-Block des Dateisystems liegt exakt auf der Grenze zwischen zwei physischen Speicherzellen.
38d11b81f23899ad2ce4059f97d3a9a0.png
Quelle: Thomas-Krenn Wiki

  • Write Amplification (Schreib-Vervielfachung): Ändert DOS auch nur ein einziges Byte auf C:, muss die Controller-Logik der SD-Karte immer zwei physische Blöcke (Page 8 und Page 9) auslesen, im Speicher anpassen und beide neu schreiben. Das bremst Schreibzugriffe ab und erhöht den Verschleiß auf C:.
    Bei größeren Dateien fällt dieser Effekt prozentual kaum noch ins Gewicht: Der Versatz zieht sich zwar durch die gesamte Datei, beim fortlaufenden Schreiben entsteht jedoch insgesamt nur eine einzige zusätzliche Flash-Page als Überhang.
    Beispiel: Eine 640 KB (655.360 Bytes) große Datei (160 Pages groß)
    Der Controller füllt nacheinander die überschneidenden Blöcke auf. Es werden die Pages 1 bis 161 beschrieben -> 161 statt 160 Pages (+0,625 % Overhead)
  • Sauberes Alignment auf D:: Weil cfdisk die logische Partition D: an einer 1-MiB-Grenze (Sektor 2.048) ausrichtet, schließen alle Blöcke auf D: perfekt bündig mit den internen Flash-Pages ab. Schreibzugriffe treffen dort immer exakt eine Page.
  • Windows Swap & TEMP verlegen: Wenn du in der AUTOEXEC.BAT den Pfad SET TEMP=D:\TEMP setzt und unter Windows 3.11 die permanente Auslagerungsdatei (386SPART.PAR) auf D: anlegst, leitest du fast die gesamten Schreibprozesse des Systems auf die perfekt ausgerichtete Partition um. C: bleibt unangetastet als weitgehend read-only Systembereich erhalten.

Dass cfdisk an 1-MiB-Grenzen ausrichtet kann man hier direkt überprüfen:
87c9b77015d3a6e712b64350f8c91eaf.png
Kontrolle: \({1{.}062{.}912} \div {1{.}024} = 1{.}038\)

Noch ein Kommentar zur 504 MB-Grenze

Ich habe irrtümlicherweise im alten 386SX-BIOS die C/H/S der Festplatte Seagate Medalist ST3660A eingetragen: 1057 / 16 / 63.
Das BIOS unterstützt aber maximal 1024 / 16 / 63 (nehme ich an).
Unter MS-DOS wurde aber für 1057 formatiert. Da ich die Platte aber nie ganz befüllt habe, hat sich das nicht kritisch bemerkbar gemacht.
Wie dem auch sei, die 2 GB mSD-Karte überschreitet definitiv die 504 MB-Grenze, also werde ich nun Ontrack Disk Manager oder EZ-Drive nutzen, damit ist die BIOS-Einstellung sowieso obsolet.
Ich trage die 504 MB Höchstwerte im BIOS ein: 1024 / 16 / 63 und werde dann weiterverfahren.

Datenverlust!

Ein Dynamic Drive Overlay = DDO benötigt den Master Boot Record (MBR) und die ersten Spuren/Sektoren der Festplatte, um seinen eigenen Boot-Code und die Partitions-Übersetzung vor dem eigentlichen Betriebssystem zu laden.
Das Overlay wird IMMER auf einer leeren, unformatierten Festplatte eingerichtet, bevor Partitionen erstellt und das Betriebssystem installiert wird.
Auf Festplatten, die bereits Daten beinhalten, die man behalten will, wird es also zwangsläufig zu einem kompletten Datenverlust kommen!

Ontrack Disk Manager

Ontrack Disk Manager Boot.png

Der Ontrack Disk Manager ist neben anderen tollen Funktionen hauptsächlich dazu da die lästige, alte BIOS-Grenze von Festplatten zu umgehen. Dazu wird ein eigener Bootcode - ein Dynamic Drive Overlay (DDO) - in den MBR und die Spur 0 des Datenträgers installiert, der diese Grenzen aushebelt.
Dieses DDO lädt beim Booten einen eigenen Treiber in den RAM, der sich vor dem Betriebssystem in die BIOS-Routinen einklinkt und die Adressierung erweitert.

Szenario

Ich habe mit Ontrack Disk Manager v9.57 auf dem 386SX eine mSD-Karte (im SD -> IDE Adapter) konfiguriert mit drei Partitionen:
C: ca. 400 MB, D: ca. 1.200 MB, E: ca. 350 MB.
Testweise habe ich danach auf C: MS-DOS 6.22 installiert.
Ich möchte nun die Daten meiner Festplatte Seagate Medalist ST3660A, von der ein DD Rawimage erstellt wurde auf diese mSD-Karte übertragen.

Workflow Linux

Ich stecke die mSD-Karte in den Kartenleser und zunächst einmal lege ich davon eine Sicherung an. Die Karte hat ja so erstmal funktioniert mit dem DDO frisch installiert. Die mSD-Karte läuft bei mir unter /dev/sdf.

Sicherung der mSD-Karte:
dd if=/dev/sdf of=ontrack_mSD_2G.img bs=4M status=progress conv=fsync

Achtung

Prüft genau mit welchen Laufwerken Ihr arbeitet, es kann im schlimmsten Falle zu komplettem Datenverlust auf dem falschen Laufwerk kommen, wenn man hier nicht genau acht gibt!

Quellfestplatte - Rawimage einbinden

Das DD Rawimage von dem kopiert werden soll wird schreibgeschützt eingehangen.
Dazu erstellen wir erstmal den Mountpunkt:
mkdir -p ~/mnt/img_c

Dann erstellen wir ein loop-Device für das Image:
losetup -fP -r ST3660A_386SX.img

Und mounten es schreibgeschützt am dafür erstellten Mountpunkt:
sudo mount -o ro /dev/loop0p1 ~/mnt/img_c

Zielfestplatte - Start-Offset(s) der FAT16 Partition(en)

Da Linux im MBR nur den Ontrack-Container (Typ 54 / OnTrackDM6) sieht, müssen wir die echten FAT16-Bootsektoren der einzelnen virtuellen Laufwerke (C:, D:, E:) finden.

Dazu habe ich ein Python-Suchskript verwendet find_fat16.py: - find_fat16.py

#!/usr/bin/env python3
import sys
import os


def scan_fat16_sectors(device_path):
    if not os.path.exists(device_path):
        print(f"Fehler: Gerät '{device_path}' wurde nicht gefunden.")
        sys.exit(1)

    print(f"Scanne Datenträger '{device_path}' nach FAT16-Bootsektoren...\n")
    print(f"{'Sektor':>10} | {'Offset (Bytes)':>15} | {'Offset (MiB)':>12}")
    print("-" * 45)

    sec = 0
    found_count = 0
    chunk_size = 65536  # 64 KB Puffer für schnelle I/O

    try:
        with open(device_path, "rb") as f:
            while chunk := f.read(chunk_size):
                for i in range(0, len(chunk), 512):
                    sector_data = chunk[i:i+512]

                    # Validierung: 512 Bytes, Boot-Signatur 0x55AA und "FAT16"-String bei Byte 54-62
                    if (len(sector_data) == 512 and
                        sector_data[510:512] == b"\x55\xaa" and
                        b"FAT16" in sector_data[54:62]):

                        offset_bytes = sec * 512
                        offset_mib = offset_bytes / (1024 * 1024)
                        print(f"{sec:>10} | {offset_bytes:>15} | {offset_mib:>9.2f} MiB")
                        found_count += 1

                    sec += 1

    except PermissionError:
        print("\nFehler: Keine Leserechte! Bitte führe das Skript mit 'sudo' aus.")
        sys.exit(1)
    except Exception as e:
        print(f"\nFehler beim Lesen des Datenträgers: {e}")
        sys.exit(1)

    print("-" * 45)
    print(f"Scan abgeschlossen. {found_count} Bootsektor(en) gefunden.\n")


if __name__ == "__main__":
    if len(sys.argv) != 2 or sys.argv[1] in ["-h", "--help"]:
        print(f"Nutzung: sudo python3 {sys.argv[0]} /dev/sdX")
        sys.exit(1)

    scan_fat16_sectors(sys.argv[1])

Die Ausgabe:

❯ find_fat16.py /dev/sdf
Scanne Datenträger '/dev/sdf' nach FAT16-Bootsektoren...

    Sektor |  Offset (Bytes) | Offset (MiB)
---------------------------------------------
       126 |           64512 |      0.06 MiB
    374052 |       191514624 |    182.64 MiB
    782334 |       400555008 |    382.00 MiB
    979902 |       501709824 |    478.47 MiB
   3128958 |      1602026496 |   1527.81 MiB
   3326526 |      1703181312 |   1624.28 MiB
---------------------------------------------
Scan abgeschlossen. 6 Bootsektor(en) gefunden.

Das geht übrigens genauso - "Linux: Everything is a File" - mit dem DD Rawimage!

Nun muss man das leider etwas interpretieren, ich sprach von DREI Partitionen. Ich habe allerdings etwas rumgespielt mit der mSD-Karte und vorher eine andere Partitionsaufteilung gewählt. Da ich zur Formatierung immer "Fast Format" gewählt habe, sind also noch Restsignaturen vorhanden, die im Betrieb völlig unkritisch wären.
Die erste Partition C: liegt jedenfalls am Sektor-Offset = 126.
Da diese ca. 400 MB groß ist liegt der Start der D: Partition bei Sektor-Offset = 782.334.
Die D: Partition habe ich auf ca. 1.200 MB Größe gesetzt, daher liegt der Start der E: Partition auf Sektor-Offset = 3.128.958.

Zusammenfassend:

Laufwerk Startsektor Offset (Bytes) Offset (MiB) Part.größe (MiB)
C: 126 64.512 0,06 MiB 382 MiB
D: 782.334 400.555.008 382,00 MiB 1.146 MiB
E: 3.128.958 1.602.026.496 1.527,81 MiB 348 MiB
ENDE 3.842.048 1.967.128.576 1.876,00 MiB -

fdisk -l /dev/sdf gibt u.a. aus:
Festplatte /dev/sdf: 1,83 GiB, 1967128576 Bytes, 3842048 Sektoren

Zielfestplatte - Partitionen unter Linux einbinden (R/W)

Ich erstelle mir Ordner für die drei Partitionen:
mkdir -p ~/mnt/sd_c ~/mnt/sd_d ~/mnt/sd_e

Laufkwerk C: mounten (Offset 64.512):
mount -t vfat -o loop,offset=64512,uid=$(id -u),gid=$(id -g) /dev/sdf ~/mnt/sd_c

Laufwerk D: mounten (Offset 400.555.008):
mount -t vfat -o loop,offset=400555008,uid=$(id -u),gid=$(id -g) /dev/sdf ~/mnt/sd_d

Laufwerk E: mounten (Offset 1.602.026.496):
mount -t vfat -o loop,offset=1602026496,uid=$(id -u),gid=$(id -g) /dev/sdf ~/mnt/sd_e

Daten übertragen

Nochmal zur Übersicht, wir haben jetzt:
Quelle: ~/mnt/img_c die Quellfestplatte, das Image ST3660A_386SX.img
Ziel: ~/mnt/sd_c ~/mnt/sd_d ~/mnt/sd_e die Ziel-Laufwerke der 2 GB mSD-Karte

Mit rsync schaufeln wir jetzt die Daten Quelle -> Ziel auf die Partitionen:
rsync -aHAX --progress ~/mnt/img_c/ ~/mnt/sd_c/

Wichtig

Bitte exakt die / Forward-Slashes bei rsync beachten! Ein Weglassen führt zu einer anderen Ordnerstruktur sowohl von der Quelle aus, als auch auf dem Ziel!

Erklärung rsync:
* -a: Archiv-Modus, d.h. rekursiv, Zeitstempel, Zugriffsregeln/Attribute, Links, Spezialdateien
* -H: Hardlinks
* -A: Access Control Lists erhalten
* -X: Erweiterte Attribute erhalten

Alle Datenträger und Images sauber abmelden

Damit die Daten auch sicher alle geschrieben wurden, wird sauber abgemeldet:
sudo umount ~/mnt/sd_c ~/mnt/sd_d ~/mnt/sd_e ~/mnt/img_c

Und noch das Loop-Device entfernen:
losetup -d /dev/loop0 2>/dev/null || true

Jetzt kann die Festplatte im 386SX verwendet werden. Ich habe das ausprobiert und es geht tatsächlich! Scandisk keinerlei Fehler. 🥳

Workflow Windows

Für Windows habe ich zufällig etwas auf Github entdeckt: Ontrack Volume Mounter GUI, zu finden hier -> Github.
Selbst ausprobiert habe ich es noch nicht, macht aber laut Beschreibung und Screenshot einen brauchbaren Eindruck.