Restore von DOS Image, erweiterte Partition(en) fehlt

sugram schrieb:
@fischfilet Die Kiste bootet ja, daß ist nicht das Problem
Ergänzung ()

Hier mal die Originale Plattengeometrie der alten Platten

Anhang anzeigen 1769496
Das ist doch schonmal gut, physikalisch werden alle Festplatten erkannt.

Was passiert denn, wenn du unabhängig von deinem Image einfach mal manuell per FDISK ein paar Partitionen anlegst? Funktioniert das dann über mehrere Laufwerksbuchstaben hinweg, wie gewohnt?

Falls ja, dann stimmt einfach was beim Erstellen/Rückspielen deines Images nicht.
 
DJMadMax schrieb:
Was passiert denn, wenn du unabhängig von deinem Image einfach mal manuell per FDISK ein paar Partitionen anlegst? Funktioniert das dann über mehrere Laufwerksbuchstaben hinweg, wie gewohnt?

Falls ja, dann stimmt einfach was beim Erstellen/Rückspielen deines Images nicht.

Wie weiter oben geschrieben, das klappt :-)
 
  • Gefällt mir
Reaktionen: DJMadMax
So, weil ich es einfach wissen wollte.

-> PC mittels DOS Netzwerkbootdiskette gestartet
-> Netzlaufwerk verbunden
-> die original Platte mittels Ghost 7.0 auf ein altes NAS gesichert.

Dann eine 80 GB Platte eingebaut (hatte keine kleinere mehr hier) und erstmal getestet ob die auch erkannt wird und ob DOS läuft -> klappt.
Ok, wieder von Netzwerkbootdiskette gestartet und das Image wieder zurückgespielt.

Reboot

-> Aber auch hier das gleiche Problem. Der PC bootet, aber D: E: usw. sind nicht vorhanden
-> hab mal im BIOS die Geometrie der 2GB Platte manuell eingetragen, aber dann findet fdisk keine Platte mehr.

So, ich denke genug für heute.
Dann richte ich das halt manuell alles wieder ein.
 
Ich habe es nun doch endlich erfolgreich hinbekommen.
Bei Ghost gibt es einen Schalter -ID der dann die Plattengeometrie nicht verändert.
Habe nun mit dieser Option Ghost gestartet und das vorherige Image zurück gesichert. Jetzt ist alles so wie es sein soll.
 
  • Gefällt mir
Reaktionen: mchawk777, recu und fischfilet
foofoobar schrieb:
Da steht nämlich CHS drin und keine Blocknummer:

Eine "Blocknummer" steht da auch nicht drin, sondern eine Sektornummer, bzw. eine Sektoroffset.
"Blocknummer" ist ein Begriff, der innerhalb der Partittionen bzw. Volumes verwendet wird.

 
  • Gefällt mir
Reaktionen: sugram
sugram schrieb:
Ich habe es nun doch endlich erfolgreich hinbekommen.
Schön, aber hat das einen Grund, dass du dich da mit MS-DOS 6.22 herumquälst? Warum genau diese alte Version? Warum nicht Version 7.10 oder gleich ein recht aktuelles FreeDOS?
 
Wie schon geschrieben, weil ich eine 1:1 Kopie angestrebt habe.
Und daher eben das mit DOS 6.22 gemacht. Da es danach nicht geklappt hat, war die Neugierde und "das muß doch irgendwie funktionieren", halt größer als alles andere.

Das ich jetzt ein anderes DOS nehmen könnte ist klar, aber wollte ich halt nicht, sondern da war der Ehrgeiz halt größer das es dann doch klappt.

Klar kann ich mit dem Wissen von jetzt auch ein anderes DOS nehmen und alles dann darauf aufbauen.
 
  • Gefällt mir
Reaktionen: fischfilet
OK. Aber mit dem alten DOS kann das so nicht klappen, das kennt nämlich kein LBA. Das neuere DOS schon. Das kann dann auch gleich FAT32.
 
Ja, das habe ich nun dank euch mittlerweile auch mitbekommen.
Also daß das alte DOS kein LBA kann.

Ich war halt der Meinung, machste nen IMAGE und alles gut, weit gefehlt.
Das mit dem LBA usw. wurde mir dann erst wieder bewußt, als ich das hier gelesen hatte.
 
  • Gefällt mir
Reaktionen: fischfilet
foofoobar schrieb:
@recu Dann hat SCSI wohl was komplett falsch gemacht, den da gibt es nur Blocknummern:

https://www.seagate.com/files/staticfiles/support/docs/manual/Interface manuals/100293068j.pdf (Seite 134)

Nein. Seagate spricht in dem Dokument von LBA. Der Begriff LBA ("logical block adress") ist genau definiert und jeder weiß genau, was gemeint ist.

"Blocks" ist unbestimmt. Schau' Dir einfach mal die Dokumentation des Linux-Befehls "badblocks" an.

Im Linux-Kontext wird bei Dateisystemen unter Blocks typischerweise ein Gruppe von Sektoren verstanden.
Bei NTFS wird glücklicherweise nicht von Blocks gesprochen sondern von Clustern.

Im MBR-Kontext werden neben der CHS-Adressierung Sektornummern bzw. Offsets verwendet.
"Sektor" ist im MBR-Zusammenhang ein eindeutiger Begriff.

Es ist schon sinnvoll eindeutige Begriffe zu verwenden, wenn sie denn schon existieren.

P.S:
In englischen Datenrettungsforen, wie z.B. auf Reddit (wo Backup-Prediger gleich gesperrt werden) schreiben die Frager oft von "drive" obwohl sie "disk" meinen. "Disk" ist das physische Gerät. Der Begriff "drive" ist ungenau, weil "drive" auch für die Bezeichnung von Partitionen verwendet, z.B. "c-drive".
 
sugram schrieb:
Ja, das habe ich nun dank euch mittlerweile auch mitbekommen.
Also daß das alte DOS kein LBA kann.
Ich wusste das auch erst im Laufe des Threads. DOS 6.22 ist schon zu lange her, da weiß man nicht mehr genau was es nicht kann. Ich konnte mich noch erinnern, dass es das DOS aus der Prä-Windows95-Ära ist und auch kein FAT32 kann. Das kann erst das MSDOS ab Windows 95 B.
Ergänzung ()

recu schrieb:
"Blocks" ist unbestimmt. Schau' Dir einfach mal die Dokumentation des Linux-Befehls "badblocks" an.
Was heißt hier unbestimmt? Je nach Kontext meint man damit einen Dateisystemblock, die kleinste ansprechbare Einheit in einem Dateisystem, oder eben einen Sektor (Block) des physikalischen Datenträgers.
Sowas wie /dev/sda nennt man ja auch "block device" und nicht "sector device".

recu schrieb:
Im Linux-Kontext wird bei Dateisystemen unter Blocks typischerweise ein Gruppe von Sektoren verstanden.
Bei NTFS wird glücklicherweise nicht von Blocks gesprochen sondern von Clustern.
Das ist Jacke wie Hose.
Microsoft erfindet gern mal einen eigenen Jargon für maximale Verwirrung.
 
Zuletzt bearbeitet:
fischfilet schrieb:
Was heißt hier unbestimmt?

Korrekt, danke, es muß stattdessen "doppeldeutig" heißen!

fischfilet schrieb:
Je nach Kontext meint man damit einen Dateisystemblock, die kleinste ansprechbare Einheit in einem Dateisystem, oder eben einen Sektor (Block) des physikalischen Datenträgers.
Sowas wie /dev/sda nennt man ja auch "block device" und nicht "sector device".

Gutes Beispiel, stimmt!


fischfilet schrieb:
Das ist Jacke wie Hose.

Sicherlich bist Du von Beruf kein Pilot.

fischfilet schrieb:
Microsoft erfindet gern mal einen eigenen Jargon für maximale Verwirrung.

Ja. In diesem Fall hilft es aber, weil der Begriff "cluster" im Dateisystemzusammenhang eindeutig ist.
 
recu schrieb:
Korrekt, danke, es muß stattdessen "doppeldeutig" heißen!
Hängt auch stark davon ab ob man mit Windows/DOS oder mit Unix sozialisiert wurde.

recu schrieb:
Ja. In diesem Fall hilft es aber, weil der Begriff "cluster" im Dateisystemzusammenhang eindeutig ist.

Ist auch eher ein Windowism, im Unix Umfeld ist mir das nie begegnet, hängt wahrscheinlich mit dem ganzen diesebezüglichen hysterischen Gezappel im Windows/Dos Umfeld zusammen, im Unix-Umfeld war das immer wesentlich sauberer wegabstahiert. Beispiele:
-b block-sizeSpecify the size of blocks in bytes. Valid block-size values are 1024, 2048 and 4096 bytes per block. If omitted, block-size is heuristically determined bythe filesystem size and the expected usage of the filesystem (see the -T option). If block-size is negative, then mke2fs will useheuristics to determine the appropriate block size, with the constraint that the block size will be at least block-size bytes. This is useful forcertain hardware devices which require that the blocksize be a multiple of 2k.
https://linux.die.net/man/8/mkfs.ext4

-b block_size_options
This option specifies the fundamental block size of the filesystem. The valid block_size_options are: log=value or size=value and only one can be supplied. The block size is specified either as a base two logarithm value with log=, or in bytes with size=. The default value is 4096 bytes (4 KiB), the minimum is 512, and the maximum is 65536 (64 KiB). XFS on Linux currently only supports pagesize or smaller blocks.
https://linux.die.net/man/8/mkfs.xfs

Und auch hier (1986) wird nur von Blocks geredet:

https://archive.org/details/DesignUNIXOperatingSystem/page/n5/mode/2up
https://archive.org/details/DesignUNIXOperatingSystem/page/324/mode/2up
 
Zuletzt bearbeitet:
foofoobar,

die von Dir zitierten Beispiel für Blöcke ist das, was bei NTFS Cluster sind:
Typischerweise Zweierpotenzen von Sektoren.

In Deinem xfs-Beispiel steht: "fundamental block size of the filesystem." Die Blöcke, also die kleinsten Bausteine von Dateisystemen sind typischerweise 2er-Potenzen von Sektorgrößen (mit positivem Exponenten), also 512 Byte (nie kleiner), 1024, 2048, 4096, 8192 etc.. groß, bei einer zugrundeliegenden Sektorgröße von 512 oder auch mal 4096 Byte.
Der MBR kennt die Blöcke in den Dateisystemen nicht, er muss sie auch nicht kennen. Dateisystem sind eine Ebene oberhalb der Partitionsstruktur einzuordnen.

Der MBR kennt aber die logische Portitionsgröße, die ihm die Festplatte an ihrer Schnittstelle meldet. Das ist die Sektorgröße. Die Einheiten des MBR sind neben CHS-Parametern Sektoren bzw. Sektoren-Offsets.
 
Zuletzt bearbeitet:
Um die Verwirrung zu komplettieren: In der Microsoft-Welt wird das nicht nur Cluster genannt; scandisk und auch chkdsk sprechen in der Zusammenfassung nach einer Dateisystemüberprüfung von Zuordnungseinheiten.
 
recu schrieb:
Der MBR kennt aber die logische Portitionsgröße, die ihm die Festplatte an ihrer Schnittstelle meldet. Das ist die Sektorgröße. Die Einheiten des MBR sind neben CHS-Parametern Sektoren bzw. Sektoren-Offsets.
Man definiert einfach die Größe als Eigenschaft eines Blocks anstatt für alles mögliche neue Namen einzuführen. Damit können auch dumme Computer ganz wunderbar umgehen.
 
foofoobar schrieb:
Man definiert einfach die Größe als Eigenschaft eines Blocks anstatt für alles mögliche neue Namen einzuführen.
Ein Cluster ist die kleinste adressierbare Festplatteneinheit bei Windows-Betriebssystemen, hab ich mal gehört.

Und seid froh, daß ihr nichts mit CP/M zu tun hattet.
Da waren sogar die Sektorgrößen variabel.
Wenn man eine Diskette bekam, mußte man wissen, wie die initialisiert worden war mit Blöcke/ Spur und Spuranzahl.

Hatte man die Daten nicht, durfte man raten.
Später gab es eine Diskettenstartroutine, die das selber ermittelte (CP/A) und die Raterei war vorbei.

Auch bei den 3,5 Zoll Disketten hatte man teilweise noch abweichende Formate (2,88 MB / 36 Sektoren /Spur), aber da hatte sich die einheitliche Sektorengröße von IBM (512 Byte) schon durchgesetzt.
 
  • Gefällt mir
Reaktionen: sugram und AndreasF1975
Oktober 2026
Zurück
Oben