Intenso Memory Center 6TB - Partitionen nicht mehr erkannt

[Von K. (klausewitz)]

Hi zusammen,
gleich vorne weg: mir ist klar, daß ich auf eigenes Risiko gebastelt 
habe.

Ich habe ein Memory Center 6TB, welches teilweise schon mit Daten 
befüllt ist. Da mich die (nicht überschreibbare) Spindown-Funktion nach 
3min in meiner Anwendung sehr gestört hat, habe ich die Firmware der 
USB-Bridge nach der Anleitung von Hardkernel 
(https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update) 
aktualisiert. Um die Daten nicht zu gefährden, habe ich während des 
Flashvorgangs eine alte Platte eingebaut.
Allerdings wird die Original-Platte nach dem Update zwar korrekt 
erkannt, aber die Partitionierung etc scheint hinüber. Vermutlich 
emuliert die USB-Bridge andere Sektorgröße.

Jetzt dachte ich: OK, dann back to the roots...
Nur habe ich das Problem nach dem Rückspielen der backup-Firmware von 
oben immer noch.
Bislang habe ich noch nicht schreibend auf die Platte zugegriffen - ich 
habe also noch einen Funken Hoffnung (außer die USB-Bridge schreibt von 
sich aus)

Hat jemand von Euch eine gute Idee?
Wenn es wirklich eine doofe Sektor-Emulation ist: Gibt es ein Tool unter 
Linux, mit dem man solche Verquirlungen zumindest lesen kann (=> Rettung 
auf neue Platte [die ich dann kaufen würde])?
Was macht man eigentlich, wenn so eine Platte mal am USB kaputt geht? Am 
PC auslesen geht ja dann auch nicht mehr.

Vielen Grüße und einen guten Start ins Neue Jahr!
Andreas

P.S. Platte hängt eigentlich am BananaPi (Armbian) oder Raspberry. Auf 
dem PC habe ich Linux Mint.

[Roland E. (roland0815)]

Vermutlich ist die SATA-Verschlüsselung aktiv oder so. Den Schlüssel 
hast du gequirlt.

Neu Partitionieren und Backup einspielen...

[Von K. (klausewitz)]

Roland E. schrieb:
> Vermutlich ist die SATA-Verschlüsselung aktiv oder so. Den Schlüssel
> hast du gequirlt.
>
> Neu Partitionieren und Backup einspielen...

Hi Roland,

SATA-Verschlüsselung? Dazu habe ich im product brief von JMicron nichts 
gesehen. Warum sollte der verschlüsseln?
Hast Du ein Datenblatt o.ä.?

Ich hoffe immer noch, daß es nur ein Interpretationsfehler mit 
Sektorgröße ist. Hoffnung stirbt zuletzt :(

Die Ausgabe von

lsblk -t

 liefert folgendes:

NAME        ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED       RQ-SIZE  RA WSAME
sda                 0   4096      0    4096     512    1 mq-deadline      60 128    0B
└─sda1              0   4096      0    4096     512    1 mq-deadline      60 128    0B

Außerdem sehe ich mit dmesg beim Anstecken der Platte etwas bislang 
unbekanntes:

[sda] Optimal transfer size 33553920 bytes not a multiple of preferred minimum block size (4096 bytes)

VG Andreas

[Von K. (klausewitz)]

Hi,
sorry, wenn es jetzt etwas gestückelt kommt. Vielleicht kann der eine 
oder andere noch etwas zu meinem Lernprozeß beitragen.
Oder irgendjemand hat in Zukunft man ein ähnliches Problem und sieht 
direkt, was (schief) ging. ;)

Habe mir mal den Anfang der Platte mit dd in eine Datei geladen und mit 
einem Hex-Editor angeschaut. Der Anfang schaut gar nicht mal so übel 
aus.

MBR:
Bei 0x00 habe ich bis 0x4a was drinstehen. Danach bis 0x1b7 nur noch 0. 
Das müßte eigentlich der Bootloader sein.
Danach eine Datenträgersignatur von genau 4 Byte.
Danach 2 Bytes 0. => paßt
Ab 0x1BE soll die Partitionstabelle kommen. Da stehen auch Werte !=0.
Ab 0x1FE habe ich die Signatur 55 AA => paßt.

GPT-Header finde ich in den ersten 100MB des Dumps nicht.

Partitionstabelle besteht aus:

00 04 05 00 83 FE FF FF 00 01 00 00 00 1D 54 57

Der Rest sind 0er.
Die erste 0 paßt, die CHS-Adressierung kann ich nicht beurteilen (doof, 
wenn das der Knackpunkt ist), 83 lt. Wikipedia Linux-Partition => paßt
Danach wieder CHS-Adresse.
Anzahl der Sektoren in der Partition 1D 54 57 wäre bei 4096Byte/Sektor 
7,3TB - das erscheint mit etwas viel für eine 6TB Platte!?!
Bei 512Byte/Sektor wäre etwas zu wenig. Ursprünglich war 1 Partition auf 
der Platte, die von vorne bis ganz hinten ging.

Bei 0x100478 finde ich das Linux Disklabel (Zufall?) und ein paar Bytes 
später den Mount-Pfad (?). Zwischen der Partitionstabelle und 0x100401 
stehen nur 0er

Jetzt mal eine blöde Frage:
GPT-Header finde ich ja nicht. Müßte der nicht bei 0x0200 oder 0x1000 
(=Beginn 2. Sektor) kommen? Also da, wo die ganzen 0er stehen?

VG Andreas

[Von K. (klausewitz)]

ein letztes Update für heute (falls überhaupt noch jemand mitliest ;) )

Habe mir mal einen Dump von meiner Seagate-Platte angeschaut. Disklabel 
und Mountpoint stehen da exakt an der gleiche Stelle. Die Partition 
scheint also prinzipiell noch da zu sein.
Unterschiede habe ich bei fdisk -l festgestellt. Intenso hat Disklabel 
type: dos, Seagate Disklabel type: gpt.
Und bei der Seagate finde ich auch den GPT-Header bei 0x200.

Was zu der Frage führt: wo kommt der neue MBR her? Schreibt Linux was 
direkt beim Einstecken (ohne mounten?)

Wenn ich die Tage mal so richtig Mut habe, versuche ich einfach mal den 
ersten Sektor mit der Partitionstabelle zu überschreiben. Entweder ich 
sehe die Partition wieder oder ich habe halt alles geschrottet...

VG Andreas

[Uli S. (uli12us)]

Beschaff dir eine weitere Platte, die minimal so gross ist, wie das was 
drauf war. Dann benutze einen partition Manager z.b. EaseUS Partition 
Master, der ist normalerweise in der Lage,  selbst zerschossene 
Partitionen zu lesen. Dann kopiere alles auf die neue Platte. Dann 
kannst du ja mit der eh schon kaputten Platte deine Experimente weiter 
treiben.

[Norbert (der_norbert)]

Von K. schrieb:
> Außerdem sehe ich mit dmesg beim Anstecken der Platte etwas bislang
> unbekanntes:[sda] Optimal transfer size 33553920 bytes not a multiple of
> preferred minimum block size (4096 bytes)

2^25 - 2^9
Seltsam. Könnte das die Größe eines ›Shingles‹ sein?

[Stephan S. (uxdx)]

Von K. schrieb:
> Was zu der Frage führt: wo kommt der neue MBR her? Schreibt Linux was
> direkt beim Einstecken (ohne mounten?)

Linux schreibt - im Gegensatz zu Windows und Mac - nichts auf 
Datenträger, wenn man sie anschliesst.

[Thomas S. (Firma: Chipwerkstatt) (tom_63)]

Von K. schrieb:
> Wenn ich die Tage mal so richtig Mut habe, versuche ich einfach mal den
> ersten Sektor mit der Partitionstabelle zu überschreiben. Entweder ich
> sehe die Partition wieder oder ich habe halt alles geschrottet...

Wen Du dies tust, ist die Partition über 'normale' Wege nicht mehr 
erreichbar. Du wirst kaum das Installationsschema so hinbringen, wie es 
war. Außer es wurde ursprünglich mit GPartet erstellt. Denn dies richtet 
die Partition nach Cylinder aus, und nicht nach Sektor. Du solltest den 
ersten Daten/Partitionsektor suchen, und schauen, ob der Eintrag der 
Partitionstabelle (4 Einträge) passt. Sektor-genau !!!

Du müsstest erstmal in der Partitionstabelle schauen, ob die Einträge 
zum Anfang der Partition passen. Ich hatte es mal, dass hier durch 
'hartes Ausschalten' der Eintrag nicht mehr passte. Ich wusste aber 
zufällig wo die Partition wirklich anfing, stellte dies in der 
Part-Tabelle wieder richtig, und alles war wieder okay.

Was mich wundert, Linux erstellt eigentlich immer eine 'Swap-Partition'. 
Diese sollte nach der Linux-Partition, bzw am Ende der Platte liegen.

Desweiteren kann es sein, dass der erste 'Superblock' defekt ist. - 
Keine Sorge, der ist X-mal als Kopie vorhanden. Superplock-Kopie dann 
wieder an den ersten Platz kopiere, alles wieder gut.

Es gibt Tools (R-Studio) die finden die Daten auch ohne 
Partitionstabellen, Superblock's. Dafür scannt die Software die 6TB ab, 
und bringt Dir ALLE Daten wieder, sofern nicht drauf geschrieben wurde. 
Dann ist halt der Bereich 'futsch', der beschrieben wurde.

Wir reden hier von Extf4 ?

[Von K. (klausewitz)]

Hi Stephan,
hi Thomas,
erstmal alles Gute im Neuen Jahr!

> Linux schreibt - im Gegensatz zu Windows und Mac - nichts auf
> Datenträger, wenn man sie anschliesst.
Das dachte ich mir so auch. Als einzige Ausnahme würde ich Desktop-Linux 
sehen. Cinnamon mountet Datenträger beim Einstecken automatisch. Könnte 
mir vorstellen, daß er auch automatisch ein Recovery versucht, wenn das 
gefundene Dateisystem nicht "clean" ist.

> Wir reden hier von Extf4
ja, ext4.
Auch nur die eine Partition, weil die externe Platte nur ein Datengrab 
ist und auch nicht immer angeschlossen. Daher würde swap keinen Sinn 
machen.

Meine Idee mit der neuen Partitionstabelle + GPT ist nicht, mich da mit 
fdisk oder gparted rumzuschlagen. Da ist mir zu viel "magic" drin bzw 
ich nutze die zu selten, um ungewolltes Eigenleben auszuschließen.
Meine Idee war eher, mit die ersten xx kB von der Seagate-Platte zu 
nehmen und dort den Endsektor anzupassen. Der Anfang der Partition ist 
ja bytegenau identisch, sonst hätte ich das Label nicht an exakt der 
gleichen Position gefunden. Oder habe ich da einen Denkfehler?
Also mit dd die Seagate-Platte auslesen (habe ich ja schon für die 
Analyse), die End-Sektor-Bytes anpassen und mit dd auf die 
Intenso-Platte schreiben. Halt wirklich nur die ersten xx kB 
überschreiben, nicht gleich alles.

Habe mich noch nicht entschieden, ob ich dd nehme oder was fix selbst 
baue. Was macht denn das Gerät /dev/sda, wenn ich nur ein paar Bytes am 
Anfang schreibe und dann die Geräte-Datei schließe? Ein truncate macht 
ja prinzipiell keinen Sinn - setzt er noch ein Sonderzeichen danach auf 
die Platte? Hoffe ich nicht, aber auch noch nicht ausprobiert...

Aber um die Backup-Platte zum Testen komme nicht drum herum. Daher wird 
sich das ganze wahrscheinlich noch bis Februar verschieben müssen. :(

VG Andreas

[Bauform B. (bauformb)]

Von K. schrieb:
> Was macht denn das Gerät /dev/sda, wenn ich nur ein paar Bytes am
> Anfang schreibe und dann die Geräte-Datei schließe?

Falsche Frage :( Und wieso sda? Bootest du von nvme oder sowas?

Hast du schon probiert, die Partition am PC zu mounten? Also

mount -o ro,offset=0x100000 /dev/sdxyz /mnt

[Von K. (klausewitz)]

Hi Bauform,
sda macht durchaus Sinn, weil ich wie oben schon geschrieben eigentlich 
auf dem Bananapi unterwegs bin und da die SD-Karte nicht sd_ heißt.
Am PC (auch Linux) möchte ich momentan lieber nichts experimentieren, 
weil Cinnamon besagten Auto-Mount mitbringt - das ist mir viel zu viel 
Magie im Hintergrund. So ein recht rudimentäres System ohne 
auto-irgendwas ist mir da lieber.

Mount könnte ich tatsächlich mal probieren. Die Idee ist so naheliegend, 
daß ich nicht drauf gekommen bin. :(
Mit ro dürfte er ja eigentlich auch keinesfalls schreiben, oder? Auch 
kein fsck etc.
Und dann damit die Daten kopieren, die (hoffentlich) noch erreichbar 
sind.

VG Andreas

[Bauform B. (bauformb)]

Von K. schrieb:
> Am PC (auch Linux) möchte ich momentan lieber nichts experimentieren,
> weil Cinnamon besagten Auto-Mount mitbringt - das ist mir viel zu viel
> Magie im Hintergrund. So ein recht rudimentäres System ohne
> auto-irgendwas ist mir da lieber.

Guter Plan!

> Mit ro dürfte er ja eigentlich auch keinesfalls schreiben, oder? Auch
> kein fsck etc.

fsck nicht, dazu müsste die Platte in /etc/fstab drin stehen. Dank USB 
musst du ja nicht booten, damit entfällt auch das Risiko.
Allerdings: u.U. macht ext4 journal replay. Normalerweise will man das, 
auch wenn man nur lesen will. Aber man kann dem Block Device selbst 
einen Schreibschutz verpassen:

blockdev --setro /dev/sdxyz

https://unix.stackexchange.com/questions/190012/how-do-i-prevent-ubuntu-from-writing-anything-to-an-external-harddrive

[Thomas S. (Firma: Chipwerkstatt) (tom_63)]

@klausewitz

Sind Dir die Daten 'wichtig'? - dann ohne Schreibversuche mit z.B. 
R-Studio versuchen die Daten zu lesen. Sind alle Sektoren lesbar, ist 
das Wiederherstellen mit R-Studio ein 100% Erfolg. Einzig Umlaute in 
Dateinamen werden falsch interpretiert. Aber das wäre das geringste 
Übel.

Hinweis: Wenn Du die Platte stundenlang an einem Linux-PC hast, kann es 
sein, dass Linux das Desaster merkt, und 'selbständigt' versucht die 
Superblock's wieder zu synchronisieren. Meist klappt das auch, kann aber 
auch schiefgehen.

Mit R-Studio kannst Du übrigens an jeder beliebigen Stelle der HDD 
schreiben was Du willst.

[Norbert (der_norbert)]

Thomas S. schrieb:
> Hinweis: Wenn Du die Platte stundenlang an einem Linux-PC hast, kann es
> sein, dass Linux das Desaster merkt, und 'selbständigt' versucht die
> Superblock's wieder zu synchronisieren. Meist klappt das auch, kann aber
> auch schiefgehen.

Nun, dieses Timeout würde mich interessieren.
Also wirklich interessieren.
Wann greift das?
Halbjährlich, Vierteljährlich, Täglich oder gar garnich? ;-)

[Bauform B. (bauformb)]

Maximal wenige Sekunden: normalerweise läuft bei jedem booten ein fsck 
und normalerweise macht der das. Jedenfalls gibt es mit bookworm und 
sysv-init entsprechende Meldungen, auch in /var/log/fsck/

Edit: oder solange, bis ein USB-Wackelkontakt das Filesystem ruiniert ;)

[Norbert (der_norbert)]

Bauform B. schrieb:
> Maximal wenige Sekunden: normalerweise läuft bei jedem booten ein
> fsck
> und normalerweise macht der das. Jedenfalls gibt es mit bookworm und
> sysv-init entsprechende Meldungen, auch in /var/log/fsck/

Das finde ich insofern verblüffend, als das ich hier eine Festplatte mit 
händisch zerstörtem ersten Superblock problemlos extern anstecken kann 
ohne das auch nur das Geringste (schreibend) passiert.

Nun ist mein System auch nicht auf alles Mögliche an Auto-Gimmiks 
eingerichtet, daran mag es liegen.
Dranstecken heißt hier einfach nur: Dranstecken.

[Bauform B. (bauformb)]

Norbert schrieb:
> Das finde ich insofern verblüffend, als das ich hier eine Festplatte mit
> händisch zerstörtem ersten Superblock problemlos extern anstecken kann
> ohne das auch nur das Geringste (schreibend) passiert.

Ja, natürlich, es sollte wohl heißen:
"normalerweise läuft bei jedem booten ein fsck und normalerweise macht 
der das, wenn die Platte in /etc/fstab eingetragen ist."

Was bei einer regelmäßig benutzten externen ja leicht sein kann.

[Thomas S. (Firma: Chipwerkstatt) (tom_63)]

Norbert schrieb:
> Nun, dieses Timeout würde mich interessieren.
> Also wirklich interessieren.
> Wann greift das?

extf4 hat eben einen Journaling-Mechanismus, der bei jedem Dateizugriff 
das Journaling aktualisiert. Deshalb kann Linux zumindest extf4 (extfs3 
wohl auch schon ?) Schäden im FS durch z.B. hartes Ausschalten 
aufspüren, und meist wieder reparieren. Dies erledigen zum einen die 
mehrfachen Kopien vom Superblock. Zum anderen scannt Linux in 
Intervallen das Medium auf Fehler. Wann die passiert, steht evtl. in der 
fstab, oder ist ein Cron-Job. Korrigiert mich da, wenn ich falsch liege.

Dazu muss natürlich das Journaling auch 'eingeschaltet sein'.

[Norbert (der_norbert)]

Thomas S. schrieb:
> extf4 hat eben einen Journaling-Mechanismus, der bei jedem Dateizugriff
> das Journaling aktualisiert.

Das ist mir alles seit sehr, sehr langer Zeit bekannt.
Ich war nur verblüfft über die Meinung, das bei einem ›*RO*‹ Device eine 
der Partitionen plötzlich und automagisch beschrieben werden soll.

Obwohl, magisch wäre da ja schon eine zutreffende Bezeichnung.

Wenn man allerdings - und ich weiß beim besten Willen nicht warum man so 
etwas tun sollte - aber wenn man nun einen automount Mechanismus und 
dann noch als RW konfiguriert hat…

[Ob S. (Firma: 1984now) (observer)]

Thomas S. schrieb:

> extf4 hat eben einen Journaling-Mechanismus, der bei jedem Dateizugriff
> das Journaling aktualisiert.

Das ja. Ist allerdings keinesfalls ein Alleinstellungsmerkmal, das 
konnte z.B. NTFS schon vor 30 Jahren, also lange vor ext4.

> Deshalb kann Linux zumindest extf4 (extfs3
> wohl auch schon ?) Schäden im FS durch z.B. hartes Ausschalten
> aufspüren, und meist wieder reparieren.

Reparieren aber nur in dem Sinne, dass das FS wieder konsistent wird. 
Das heißt aber NICHT, dass:

1) zuletzt geschriebene Änderungen im reparierten Ergebnis ankommen
(Normalfall ist das Gegenteil)
2) Dass der Inhalt des reparierten Filesystems auch aus Sicht von 
Anwendungen konsistent ist (logische Folge von 1)

Das allerdings gilt natürlich auch nicht nur für ext4 sondern auch für 
NTFS. Gleiche Konzepte führen halt zu gleichen Ergebnissen.

> Dies erledigen zum einen die
> mehrfachen Kopien vom Superblock.

Nein. Das ist was völlig anderes, das gab es auch schon viel früher, 
also z.B. bei ext2 oder sogar schon den diversen FAT-Varianten. Das hat 
nix mit mit dem Journaling zu schaffen. Das ist Redundanz auf einer viel 
primitiveren Ebene.

[Harald K. (kirnbichler)]

Ob S. schrieb:
> Reparieren aber nur in dem Sinne, dass das FS wieder konsistent wird.

Das aber bedeutet, schreibend auf die Festplatte zuzugreifen. Den 
Widerspruch zu "ro" (read-only) erkennst Du dabei nicht?

[Bauform B. (bauformb)]

Naja, die Grenze zwischen Technik und Magie...
man mount sagt z.B.:

-r  Mount the filesystem read-only. A synonym is -o ro.

  Note that, depending on the filesystem type, state and kernel
  behavior, the system may still write to the device. For example,
  ext3 and ext4 will replay the journal if the filesystem is dirty.
  To prevent this kind of write access, you may want to mount an ext3
  or ext4 filesystem with the ro,noload mount options or set the
  block device itself to read-only mode, see the blockdev(8) command.

[Norbert (der_norbert)]

Bauform B. schrieb:
> man mount sagt z.B.:

›mount‹ kann _evtl._ schreiben, aber NUR wenn man für das darunter 
liegende Device Schreiboperationen überhaupt zulässt. Aber das wurde 
bereits von einem Vorredner genügend dargelegt.

[Ob S. (Firma: 1984now) (observer)]

Norbert schrieb:

> ›mount‹ kann _evtl._ schreiben, aber NUR wenn man für das darunter
> liegende Device Schreiboperationen überhaupt zulässt.

Und welches Device, was grundsätzlich zum Zugriff auf HDDs/SSDs 
ausgelegt ist, erlaubt keine Schreibzugriffe? Das wäre ein armseliges, 
für praktische Zwecke unbenutzbares Device.

Ausnahme wäre: forensische Zwecke. Deswegen gibt es tatsächlich solche 
Devicetreiber. Aber sicher nicht in Standard-Kernels von der Stange...

[Norbert (der_norbert)]

Ob S. schrieb:
> Und welches Device, was grundsätzlich zum Zugriff auf HDDs/SSDs
> ausgelegt ist, erlaubt keine Schreibzugriffe? Das wäre ein armseliges,
> für praktische Zwecke unbenutzbares Device.

Das ist einfach, das beantworte ich.
Standard Debian, Standard Kernel: jedes armselige Device welches mit 
›blockdev‹ in den RO Modus versetzt werden kann.
Also 'ne ganze Menge…
Danach ein mount ro,norecovery … fertig.

[Ob S. (Firma: 1984now) (observer)]

Norbert schrieb:

> Das ist einfach, das beantworte ich.
> Standard Debian, Standard Kernel: jedes armselige Device welches mit
> ›blockdev‹ in den RO Modus versetzt werden kann.

Hmm...

Und wie genau macht das jezt der TO? Und zwar bevor der erste 
Zugriff auf das Device erfolgt?

[Norbert (der_norbert)]

Ob S. schrieb:
> Und wie genau macht das jezt der TO? Und zwar bevor der erste
> Zugriff auf das Device erfolgt?

Von K. schrieb:
> P.S. Platte hängt eigentlich am BananaPi (Armbian) oder Raspberry. Auf
> dem PC habe ich Linux Mint.

Ein Armbian ist ein Debian. Also macht er's so wie er's zuvor am 
Raspberry oder am PC mit Mint geübt hat.

Im schlimmsten anzunehmenden Fall kann er ja zuvor eine Sicherung 
durchführen.
Obwohl, so etwas machen wir ja im 21. Jahrhundert nicht mehr. Da 
operieren wir erst einmal bei Windstärke acht in der Kiesgrube am 
offenen Herzen. ;-)

[Von K. (klausewitz)]

Hi zusammen,
bitte entschuldigt die späte Rückmeldung. War unter der Woche beruflich 
eingespannt und hatte abends keinen Nerv mehr für solche Experimente.

1.) Platte an BabanaPi angesteckt

2.) /dev/sda blockdev auf read-only gesetzt. Vielen Dank für diesen 
Befehl, den kannte ich noch nicht

3.) Partition manuell mit offset ro gemounted (wie oben vorgeschlagen)

4.) ich sehe meine Dateien!!! :)

5.) aktuell ziehe ich alles runter, was geht. Muß das ein bißchen 
Stückeln, weil ich keine 4TB (Datenmenge) am Stück irgendwo frei habe. 
Aber alles besser als nichts. Mal gespannt, ob noch Lesefehler kommen...

VG Andreas

[Frank K. (fchk)]

Von K. schrieb:

> 5.) aktuell ziehe ich alles runter, was geht. Muß das ein bißchen
> Stückeln, weil ich keine 4TB (Datenmenge) am Stück irgendwo frei habe.
> Aber alles besser als nichts. Mal gespannt, ob noch Lesefehler kommen...

So, und in Zukunft packst Du gefälligst nicht alle Eier in einen Korb, 
wie die Briten sagen, sondern machst Backups.

fchk

[Harald K. (kirnbichler)]

Von K. schrieb:
> Muß das ein bißchen
> Stückeln, weil ich keine 4TB (Datenmenge) am Stück irgendwo frei habe.

Das ist eine der Naturkonstanten: Bei Datenrettungen hat man nie genug 
Platz.

[Von K. (klausewitz)]

Hi zusammen,
ein finales Update: Daten waren alle unbeschädigt verfügbar.

Das mit dem Übernehmen des modifizierten GPT von der anderen Platte hat 
so nicht ganz funktioniert. Irgendwas muß ich da übersehen haben. 
Jedenfalls hat er zwar eine GPT-Tabelle erkannt, aber trotzdem immer was 
erzählt, daß eine DOS-Partition nicht so groß sein könnte ...

In einem Anflug von Euphorie habe ich dann doch fdisk probiert (mit 
cfdisk kam ich so gar nicht zurecht). Neue GPT-Tabelle erstellt, neue 
primäre Partition mit entsprechend Anfang und Ende erzeugt - und siehe 
da: Rückfrage, ob er gefundene EXT4-Markierung löschen oder übernehmen 
soll. Natürlich übernehmen ;)

Speichern, Platte weg, Platte dran - geht :)

Danke an alle für die Hilfe, vor allem das blockdev.
Wären die Daten verloren gewesen, wäre auch kein Weltuntergang gewesen. 
Aber so habe ich noch sehr viel gelernt über Partitionen :)

VG Andreas

[.● Des|ntegrator ●. (Firma: FULL PALATINSK) (desinfector)]

Harald K. schrieb:
> Von K. schrieb:
>> Muß das ein bißchen
>> Stückeln, weil ich keine 4TB (Datenmenge) am Stück irgendwo frei habe.
>
> Das ist eine der Naturkonstanten: Bei Datenrettungen hat man nie genug
> Platz.

Beim Drama kauft man sich die.

Ich finde allerdings interessant,
wie oft, mitunter auch recht leichtfertig Leute Firmwareupdates machen,
BIOS neu flashen etc.

Das tat bei mir irgendwie noch nie wirklich not.
Ausser wenn Mudderns Sat-Receiver danach gelüstet
und so'n Ding sonst nichts mehr macht.

(Jungeeeh kannst Du da mal bitte gucken?)