[10.10 Yosemite] [gelöst] Festplattendienstprogramm Fehlermeldung bei Partitionieren / Verschlüsseln

[ma:ro]

Hallo zusammen,

ich habe hier ein sehr obskures Problem mit dem Festplattendienstprogramm, vielleicht kennt es jemand und weiß Abhilfe (Suchergebnisse nach "MediaKit" ohne meine konkrete Fehlermeldung).

Auf einer USB 3.0 Festplatte mit 5 Partitionen (GUID-Schema, 4x NTFS, 1x HFS+) wollte ich ein TimeMachine-BackUp erstellen. Dieses funktioniert auch - allerdings nur unverschlüsselt.

TM selbst brach bei der Option mit folgender Fehlermeldung (siehe Anhang) ab.

"Die Verschlüsselung des Mediums ist fehlgeschlagen.
Beim Löschen des Medium ist folgender Fehler aufgetreten:
MediaKit meldet: Gerät hat für den gewünschten Vorgang nicht genügend Speicher."​

Nun gut, OS X von USB-Medium gestartet und nur das Festplattendienstprogramm aufgerufen.

Partition LÖSCHEN - funktioniert.
Partition ERSTELLEN - funktioniert (egal welche Größe und egal ob HFS+, FAT, exFAT)​

Nun allerdings das Problem:

Gehe ich im Festplattendienstprogramm auf "löschen" und neu formatieren mit "HFS+ verschlüsselt" kommt zwar meine Wunschpasswortabfrage, anschließend jedoch sofort o.g. Fehlermeldung.

Festplattenpartition ist 100 GB groß, ich habe dem freien Bereich bereits 10% zugeteilt - ohne Erfolg.
Unverschlüsselt alles kein Thema... nur das ist nicht Sinn und Zweck...​

Daher die Frage:

Kennt jemand dieses Problem und kann mir eine Lösung mitteilen?​

Besten Dank dafür

PS: Falls es etwas hilft in groben (gerundeten) Angaben lt. Festplattendienstprogramm:

USB-HDD: 2.000 GB

Partition I: 107 GB NTFS
Partition II: 107 GB HFS+ <-- hier soll das TM-BackUp drauf, lässt sich nur unverschlüsselt nutzen.
Partition III: 860 GB NTFS
Partition IV: 860 GB NTFS
Partition V: 66 GB NTFS​

 

[Scotch]

Kennt jemand dieses Problem und kann mir eine Lösung mitteilen?

Da ist mit 99%-iger Wahrscheinlichkeit die Partitionstabelle kaputt. Führe mal

diskutil list

im Terminal aus (und stell das Ergebnis hier innerhalb von CODE-Tags ein). Aus der Liste suchst du dir dann die Nummer der dich interessierenden Festplatte 'raus (z.B. /dev/disk3) und gibst dann

sudo fdisk -d /dev/disk<Nummer der Festplatte>

ein. Ergebnis wieder innerhalb von CODE-Tags hier posten. Auf die Passwortabfrage musst du mit dem Passwort des Benutzers, den du verwendest antworten. Danach wissen wir mehr. Keine Angst, die beiden Kommandos fragen nur Parameter ab, an deinen festplatten wird nichts geändert. Du solltest von weiteren Partitionierungs- und Löschexperimenten bis auf weiteres absehen und auch nicht auf die Platte schreiben, sondern stattdessen ein Backup aller Partitionen der betroffenen Festplatte machen. Wenn die Daten nicht so wichtig sind (oder du bereits ein Backup hast) kannst du die Platte ganz normal weiter benutzen - nur keine weitere Aktionen mit dem Festplattendienstprogramm!

Grundsätzlich: (TM-)Backups gehören auf einen dedizierten Datenträger und da gehört auch sonst nichts 'drauf!

 

[ma:ro]

Dankeschön für die Antwort, Scotch.

Komplette Übersicht von 2 internen und 1 externem Laufwerk:
Der relevante Teil ist in DISK3, Partition 2

Disk0 - System interne SSD
Disk1 - zweite interne HDD
Disk3 - externe USB 3 HDD

Disk2/5 kann ich nicht zuordnen.

/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *128.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage                         127.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:          Apple_CoreStorage                         499.8 GB   disk1s2
   3:                 Apple_Boot Boot OS X               134.2 MB   disk1s3
/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS System X9              *126.8 GB   disk2
                                 Logical Volume on disk0s2
                                 EEBCC67A-616E-47DA-845E-9DC07F148684
                                 Unlocked Encrypted
/dev/disk3
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *2.0 TB     disk3
   1:       Microsoft Basic Data Win 10 Systemabbild     107.4 GB   disk3s1
   2:                  Apple_HFS Apple                   97.4 GB    disk3s2
   3:       Microsoft Basic Data Sicherung               859.0 GB   disk3s3
   4:       Microsoft Basic Data Storejet                859.0 GB   disk3s4
   5:       Microsoft Basic Data Software                67.7 GB    disk3s5
/dev/disk5
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS WD-Blue                *499.4 GB   disk5
                                 Logical Volume on disk1s2
                                 764911D3-10EB-4F9B-8BEF-ADDEC2EE7EF6
                                 Unlocked Encrypted

Der Befehl "sudo fdisk -d /dev/disk3" bringt folgendes für die entsprechende USB HDD, und sieht optisch - bis der Eintrag vor "0xEE" - gleich aus, wie die interne System-SSD.

1,-387938129,0xEE,-,1023,254,63,1023,254,63
0,0,0x00,-,0,0,0,0,0,0
0,0,0x00,-,0,0,0,0,0,0
0,0,0x00,-,0,0,0,0,0,0

Danke für weitere Hinweise.

PS: Das Medium wurde gestern erst komplett gesichert - alles sauber und für Experimente zugelassen.
Ich kann die HFS+ Partition auch löschen und mit einer NTFS-Partition zusammenführen, da das Original-BackUp von TM eigentlich auf einem Netzlaufwerk (und redundant) gesichert wird. Ich wollte nur ein BackUp Medium für "alle" Geräte haben, das sind nunmal 3x Windows und 1x OS X (die letzte Partition ist mit Programmen zur Wiederherstellung etc.)

 

[Rastafari]

Abgesehen davon, dass "Backups" auf einer partitionierten HD, noch dazu eine die unter Windows genutzt werden soll, keinerlei "Backup" mehr sind - sondern nur noch ein weiteres Volume mehr, das selbst eines Backups bedürfte...

Also wie schon gesagt, abgesehen davon dass solche Vorhaben kompletter *Schwachfug* sind (den du zu gg. Zeit bereuen wirst)...

...wenn du unter den ersten 3 Partitionen einer HD mindestens eine in einem Format anlegst, das von Windows lesbar ist (MSDOS, NTFS oder exFAT), dann wird automatisch versucht eine sog. "hybride" Partitionierung zu erstellen die sicher von *jeder* Windows-Version benutzt werden kann (nicht erst seit Vista/SP1, wie das bei reiner GUID-Partitionierung der Fall ist).
"Hybride" Partitionierung" bedeutet das parallele Weiterführen einer MBR-Tabelle, diese wiederum lässt keine verschlüsselten Mac-Volumes zu.
Du könntest versuchen, erst mal alle Partitionen in HFS+ zu erstellen, dann zu verschlüsseln und erst danach einzelne Pt'n in NTFS zu konvertieren. Oder die Partitionierung komplett "in Handarbeit" im Terminal erstellen.
Oder ... wie gesagt ... solchen fehlerschwangeren Unfug bleiben lassen.

 

[ma:ro]

Danke für die Antwort, Rastafari.

Die Festplatte ist rein als GPT in Betrieb, so steht es auch in einer kommerziellen Anwendung. Da alles < NT 6.3 ohne Bedeutung ist, wird auf MBR verzichtet.

Auf einem alten externen Medium (250 GB HDD / 130 GB HFS+ verschl. / 120 GB exFAT) war das absolut kein Problem - es lässt sich sogar booten und arbeiten.
Die HDD war aber auch nur 1/8 so groß wie die aktuelle und besaß weniger Partitionen. Daher leuchtet mir die Erklärung nicht ein.

Wieso das "Schwachfug" ist, verstehe ich nicht. Seit 20 Jahren arbeite ich bei Datenträgern mit Partitionen und bislang ist mir noch keine Partitionstabelle "abgeraucht" oder Dateien beschädigt worden. Lediglich habe ich einmal eine Verschlüsselung unfreiwillig durch Stromausfall unterbrochen, sodass alle Daten kaputt waren (BackUp aber natürlich vorhanden) und bei einer uralten 120 GB 3,5 P-ATA Platte ist mir der Controller flöten gegangen.

PS: Das aktuelle TM-BackUp liegt auf einem gespiegeltem NAS auf EXT4-Format in einem SparseImage. Verschlüsselt - läuft. Auch Wiederherstellen - kein Problem.

 

[Rastafari]

Wieso das "Schwachfug" ist, verstehe ich nicht.

Du musst nur verstehen was ein "Backup" ist - und was ein solches von einer simplen Kopie unterscheidet.
Dann hat sich jede weitere Idee in diese Richtung erledigt.

Ob eine hybride Tabelle im Einsatz ist oder nicht, zeigt dir übrignes nur ein 'fdisk'-Aufruf zuverlässig.
Gibt es ausser dem obligatorischen "EE" Eintrag noch weitere, dann ist das Hybrid, egal was andere Programme dazu meinen, bzw anzeigen.

 

[ma:ro]

In obigem fdisk Befehl steht doch nur der 0xEE und unterscheidet sich bis auf den ersten Eintrag in keinster Weise von den beiden anderen internen Laufwerken, die ausschließlich mit HFS+ verschl. laufen. Oder übersehe ich da etwas? Mit UNIX-Befehlen/Ansichten kenne ich mich leider überhaupt nicht aus - bin mit MS-DOS "aufgewachsen", bis Windows 98 kam, und da hat man es auch noch gebraucht...

Ein "echtes BackUp" ist ein Duplikat (auch 1:1-Kopie landläufig genannt) des betroffenen Datenträgers, georedundant aufbewahrt.
Eine "Kopie" ist eine Abschrift, die Fehler enthalten kann. Daher werden die Daten ja nicht manuell per CMD+C/V kopiert, bringt zur Wiederherstellung nichts. Ein TM-BackUp finde ich auch etwas fragil, daher liegt auf der ersten Partition der alten HDD eben ein Duplikat der SSD vor. - Und das läuft einwandfrei - auch extern.

PS: Das Problem hat auch nichts mit TM zu tun, denn auch im Festplattendienstprogramm, welches ohne OS X von DVD/USB gestartet werden kann, lässt sich die HFS+ formatierte Partition nicht auf HFS+ verschlüsselt setzen.

 

[Rastafari]

Wie schon gesagt: Richte die Platte ganz ohne Windows-Partitionen ein, nimm die Verschlüsselung vor und wandle erst danach in NTFS.

 

[ma:ro]

Danke, ich denke, da werde ich vom zeitlichen Aufwand eher die HFS+ Partition löschen, den Speicherplatz einer anderen Partition zuteilen und den TM-Container weiterhin im SparseImage verschlüsselt lassen, sowie ab und an ein Systemabbild auf dem "alten" externen Datenträger anfertigen.

Woran erkenne ich mit fdisk nun, ob es eine reine GPT ist?
Ich sehe ja nur den einen "0xEE" Eintrag. Wäre toll, wenn das noch beantwortet wird, um etwas gelernt zu haben.

 

[Rastafari]

den TM-Container weiterhin im SparseImage verschlüsselt lassen

? ? ?

Woran erkenne ich mit fdisk nun, ob es eine reine GPT ist?
... Wäre toll, wenn das noch beantwortet wird

Bereits geschehen, #6

 

[ma:ro]

? ? ?

Beitrag 5, Abschnitt 5, Satz 1 - verschlüsseltes TM-BackUp auf Netzlaufwerk in EXT4-Format.

Zu dem Hinweis in Beitrag 6, sollte eine reine GPT dann "so" aussehen:
???

-,0xEE,-,-,-,-,-,-
0,0,0x00,-,0,0,0,0,0,0
0,0,0x00,-,0,0,0,0,0,0
0,0,0x00,-,0,0,0,0,0,0

Weil wie erwähnt ist kein Unterschied (bis auf den ersten Eintrag) ggnb. den "reinrassigen" HFS+ mit GPT zu erkennen, wo noch nie etwas anderes als HFS+ verschl. lief.

Interne SSD:

1,250069679,0xEE,-,1023,254,63,1023,254,63
0,0,0x00,-,0,0,0,0,0,0
0,0,0x00,-,0,0,0,0,0,0
0,0,0x00,-,0,0,0,0,0,0

Interne HDD:

1,976773167,0xEE,-,1023,254,63,1023,254,63
0,0,0x00,-,0,0,0,0,0,0
0,0,0x00,-,0,0,0,0,0,0
0,0,0x00,-,0,0,0,0,0,0

Externe HDD:

1,-387938129,0xEE,-,1023,254,63,1023,254,63
0,0,0x00,-,0,0,0,0,0,0
0,0,0x00,-,0,0,0,0,0,0
0,0,0x00,-,0,0,0,0,0,0

 

[Scotch]

Wie erwartet ist deine Partitionstabelle im Eimer. Wenn ich mir die Volume-Daten anschaue liegt das vmtl. daran, dass die Platte teilweise unter Windows partitioniert wurde - das macht Windows (oder tools unter Windows) i.d.R. richtig, aber das Festplattendienstprogramm überschreibt dann gerne mal alles, was es nicht kennt mit Nullen - OS X tangiert das wenig, das kriegt alle seine Informationen aus dem EFI, aber wenn man dann doch mal 'dran muss - hier: Anlegen einer Verschlüsselung - dann steht bei bei negativen Sektorenangaben wie bei dir auch OS X auf dem Schlauch

Deine /dev/disk0 Tabelle dürfte ungefähr so aussehen (sudo -d /dev/disk0):

1,490234751,0xEE,-,1023,254,63,1023,254,63
0,0,0x00,-,0,0,0,0,0,0
0,0,0x00,-,0,0,0,0,0,0
0,0,0x00,-,0,0,0,0,0,0

Da gibt's einen fundamentalen Unterschiede zu deinem printout von deiner disk3: Keine negativen Zahlen Viel wichtiger ist aber, dass so eine Tabelle nur OK ist, wenn ausschliesslich HFS(+) Partitionen auf der Platte sind (der Vollstädnigkeit halber: Ich glaub' für ZFS ist das auch OK, hatte ich aber auf einem Mac noch nicht im Einsatz). Da werden alle Information aus dem EFI geholt. Auf deiner disk3 sind aber nicht nur HFS-Partitionen, d.h. die Tabelle sollte irgendwie so aussehen:

1: EE 1023 254 63 - 1023 254 63 [ 1 409639] <Unknown ID>
2: AF 1023 254 63 - 1023 254 63 [ 409640 125683888] HFS+
3: 83 1023 254 63 - 1023 254 63 [ 909627392 65048576] Linux files*
*4: 07 1023 254 63 - 1023 254 63 [ 127363072 782264320] HPFS/QNX/AUX

Das Format ist etwas anders, weil mit der '-e' Option plus print-Command erzeugt (das solltest du nicht nachvollziehen, wenn du nicht sehr genau weisst, was du tust!), da ich gerade keine Hybrid-Platte da habe um mit '-d' zu dumpen, aber der relevante Teil ist, dass in diesem Fall die einzelnen Partitionen eindeutig markiert sein müssen. Insbesondere dürfen die IDs nicht auf 0x0 stehen. Im oberen Beispiel kommt nach dem EFI (0xEE) eine HFS+ Partition (0xAF), dann eine Linux-Partition (0x83 - in diesem Fall ext4, könnte aber auch ext2, ext3, xia usw. sein) und dann kommt eine abgeschmierte Linux Swap-Partition, die auf Grund eines falschen Eintrags als IFS bzw. HPFS interpretiert ist (und auch noch als bootfähig markiert ist, was zwar mit HPFS, nicht aber mit Linux Swap funktioniert ). Der Rest sind die Geometriedaten und ganz wichtig: Die Startsektoren der Partitionen und deren Länge!

Auf deiner disk3 gibt's sechs Partionen (EFI mitgezählt), aber die Tabelle kennt nur vier und davon hat eine eine negative Größe und drei haben eine Größe von Null. Funktioniert überhaupt nur, weil OS X & Windows bei Zugriff die Partitionstabelle komplett ignoriert - bis du versuchst, was zu ändern. Mit Windows-Bordmitteln müsste das eigentlich auch schief gehen - wenn du ein Backup hast und Zeit zum Experimentieren, kannst du ja mal unter Windows versuchen, eine der Partitionen zu löschen oder in der Größe zu verändern. Müsste eigentlich auch schiefgehen - wäre mal interessant.

Lange Rede, kurzer Sinn: Das kann man reparieren, ist aber sehr aufwändig, kompliziert und fehlerträchtig. Wenn du die Daten aller Partitionen gesichert hast, würde ich empfehlen, die Platte komplett zu löschen und neu zu partionieren. Vorher vielleicht mal über @Rastafari und meinen Einwand bzgl. Backups auf so einer Platte ablegen nachdenken. Wenn du Glück hast klappt das, indem du den Mac in den Recovery-Modus bootest und dann mit dem Festplatten-Dienstprogramm erst die Festplatte löschst (die Festplatte! Nicht die Partitionen (die werden natürlich automatisch mitgelöscht) - die Operationen sind unter der Haube nicht die gleichen!). Danach gewünschte Anzahl & Typ mit dem Festplattendienstprogramm anlegen (müsste klappen, wenn das Löschen klappt) und wenn du unbelehrbar da deine TM-Partition 'drauf haben willst: Erst verschlüsseln, bevor du irgendein anderes OS auf die anderen Partitionen los lässt.

Wenn das nicht klappt geht's nut zur Fuss auf der Kommandozeile weiter.

HTH & Viel Erfolg.

 

[Scotch]

Woran erkenne ich mit fdisk nun, ob es eine reine GPT ist?

Hat mein Roman hoffentlich erläutert Du erkennst das in deinem Fall mit fdisk gar nicht, aber aus der Kombination von fdisk und diskutil erkennst du, dass deine Partitionstablle hin ist. Die Fehlermeldung kommt aus dem Versuch des Festplattendienstprogrammes, auf eine negative Sektorenadresse zuzugreifen.

 

[ma:ro]

Hallo Scotch,

besten Dank für die ausführliche Antwort.

Ich nehme aus der interessanten Diskussion mit:
Mit irgendetwas habe ich mir selbst die GPT beschädigt, da eines der Partitionen eine negative Größe hat, die nicht möglich sein kann.
Heißt im Umkehrschluss, ich lösche die komplette Festplatte, spiele übergreifende Daten auf, lagere etwas anderes aus und lasse weiterhin auf dem Netzlaufwerk die TM-Sicherungen und besorge mir jeweils ein weiteres Medium für die anderen Kisten

Dass die anderen mit 0 ausgewiesen werden, hängt vielleicht mit BitLocker zusammen, dass sie nicht gelesen werden können?

Wie dem auch sei,
vielen Dank.

Beide haben mir geholfen und ich habe nun mit "fdisk" und dem negativen Wert etwas aus der UNIX-Welt dazu gelernt.

 

[Rastafari]

bei bei negativen Sektorenangaben wie bei dir

Irrelevant, das ist nur ein Darstellungsfehler des "übergründlich standardkonform" erstellten fdisk - das arbeitet mit "signed int" statt mit "unsigned" - und kommt daher nicht mit Platten >= 1 TB klar (in Worten: *EIN* TB, nicht zwei).
--> An der Tabelle fehlt (anscheinend) gar nichts.

Zur Klarstellung noch:
Es ist nicht allein entscheidend, ob die HD bereits Hybrid partitioniert ist oder nicht - wichtig ist, welches Layout dem Framework während des Änderungsprozesses als genehm und richtig erscheint.
Und da gilt wieder die schon erwähnte Regel: Findet sich eine Windows-lesbare Partition, wird Hybrid zumindest versucht - ohne wenn und aber. Nicht nur bei der Neuerstellung, sondern auch bei jeglicher Modifikation.
(Und verschlüsselte Partitionen *benötigen* eine solche Modifikation: Hinzufügen einer Boot/Recovery-Partition und abändern des HFS-Partitionstyps auf "CoreStorage")

Eine alternative Möglichkeit gäbe es noch - aber diese Info läuft unter "ohne Gewähr", weil ungetestet.
Du könntest dir zB 'gpt-fdisk' laden und installieren. (Gibts für alle relevanten OS für lau)
Damit entfernst du die HFS-Partition, und erstellst an deren Stelle eine vom typ "Apple CoreStorage", sowie eine weitere, unmittelbar darauf folgende vom Typ "Apple/Darwin Boot" mit genau 128 MiB (== 262144 sect).
(Diese Bootpartition muss sowohl von der physischen Position her, als auch von ihrer logischen Indexposition in der Tabelle unmittelbar auf die CS folgen!)
Dann sollte beim Löschen des Volumes als "verschlüsselt" keine Veränderung an der Partitionstabelle mehr nötig sein, damit dürfte das formatieren und verschlüsseln ohne Fehler gelingen.

 

[ma:ro]

Und da gilt wieder die schon erwähnte Regel: Findet sich eine Windows-lesbare Partition, wird Hybrid zumindest versucht - ohne wenn und aber.

Danke, ist dennoch seltsam, dass es mit der anderen externen trotz "Windows-Partition" funktioniert.
Dennoch, irgendwas gefällt dem OS X damit nicht, sei es die Größe, die Anzahl der Partitionen, einer unlesbaren BitLocker-Partition oder sonstiges...
Deswegen ist mein Vorhaben diese eine HFS+ Partition - unabhängig vom Inhalt- zu verschlüsseln obsolet, und das ist ja das, was ich wissen wollte, ob es eine "Lösung" gibt. Die Vorschläge wurden genannt und ich habe mich entschieden, das nicht weiter zu verfolgen sondern die HFS+ Partition zu entfernen.

PS: Ist das dann nicht eigentlich ein IT-seitiger Fauxpas?
Maximale Kompatibilität zu "Fremdsystemen" schafft Inkompatibilität zu "Eigensystem"...

 

[Scotch]

Dass die anderen mit 0 ausgewiesen werden, hängt vielleicht mit BitLocker zusammen, dass sie nicht gelesen werden können?

Nein, der verändert nichts an der Partitionstabelle, sondern nur die tatsächlichen Daten auf der Platte. Dein Problem liegt einen Level unter dem Dateisystem.

An der Tabelle fehlt (anscheinend) gar nichts.

Es fehlen Einträge für mindestens eine Partition, sämtliche Sektorengrenzen, sowie alle FS-IDs. Das wird spätestens bei Operationen, die Zugriff auf die Tabelle erfordern zum Problem. Was der TE unfreiwillig verifiziert hat und daher gibt es diesen thread.

 

[Rastafari]

Maximale Kompatibilität zu "Fremdsystemen" schafft Inkompatibilität zu "Eigensystem"...

Tja, rate mal wem die Schuld am nicht-funktionieren gegeben würde, wäre man nicht so kompatibilitäts-besessen.
Versuch du mal einem typischen Windows-User zu erklären, dass seine Maschine die zu dämliche ist, und dass Windows eben nicht der Nabel der Welt und gültiger Massstab aller Dinge ist. Viel Glück dabei.

Und ich sags gerne nochmal: An der Tabelle scheint NICHTS zu fehlen.
Das sind rein kosmetische DARSTELLUNGSprobleme ohne jede Relevanz.

 

[Scotch]

Du, ich sag's gerne auch nochmal: Das ist Unsinn. Warum ich mir sicher bin? Weil ich letzte Woche mehrere Tage damit verbracht habe, Partitionstabellen wegen genau dieser Probleme zu reparieren. Damit kriegt man nämlich auch "verschwundene" Partitionen zurück.

Und weisst du was? Wenn die Tabelle sinnvolle Angaben enthält, dann klappt's auf einmal auch wieder mit dem Festplattendienstprogramm und insb. der MediaKit-Fehler ist weg.

Für mich ist hier EOD.

@ma:ro: Wenn's mit dem Löschen nicht klappt, schick' mir 'ne PN und ich erklär' dir, wie das zu Fuss geht. Ich habe kein Interesse, das Thema hier im Forum weiter zu verfolgen.

 

[Rastafari]

Du, ich sag's gerne auch nochmal: Das ist Unsinn. ...

Du hast nur leider hier den Punkt und den Doppelpunkt vertauscht. Dumm gelaufen.


(Was sich auch ganz leicht verifizieren lässt:
Einfach den überflüssigen Switch '-d' in 'fdisk' weglassen, um die ganz gewöhnliche, vollständige Listenanzeige statt eines verkürzten (Repipe-) Dumps zu bekommen - und schwupps, hex-hex, wie durch Zauberei ist plötzlich alles wunderbar und prima.
Booooahhh, ey.... )