Hallo
Ich bin grade etwas Ratlos zum 2.Mal verliere ich eine ganze Platte voll
Daten.
Ich habe 2 Server laufen beide recht neu aufgesetzt mit Ubuntu 20
Desktop. Ich habe einige Usb platten für Backups. Ich schlisse also
diese Festplatte an den Server erstelle mit Gparted eine ext4 Partition
und kopiere die Backup Daten drauf. Passt alles. Ich kann auf die Daten
zugreifen und ich denke alles ist toll. Dann hänge ich die Partition aus
stecke die Platte an ein Ubuntu 16 Rechner und sehe keine Partition.
Device Boot Start End Sectors Size Id Type
/dev/sde1 1 4294967295 4294967295 2T ee GPT
Partition 1 does not start on physical sector boundary.
Zurück am U20 Server bleibt die Platte genauso ohne Partition.
Beim ersten mal hatte ich eine Platte am Usb Nachdem ich dann nochmal
eine Partition erstellt hatte und alles neu kopiert hatte funktionierte
es. Beim 2. Mal das war eine andere neue Platte. Ich hatte diese aus dem
Usbgehäuse geholt und per sata Kopiert und jetzt wieder das gleiche
Problem.
Habt ihr das schon mal erlebt? wie könnte sich das erklären?
Bzw wo könnte der Fehler sein?
Ps Nein es gab keinen Datenverlust weil es sich nur um Backups handelt
und ich die öfter mache ;)
Von welchem Programm kommt die Ausgabe?
Was da angezeigt wird ist eine GPT Protektive Partition in einem
protektiven MBR.
Versuche mal, dir mit z.B. gdisk oder so die Partitionstabelle anzeigen
zu lassen. ("gdisk -l /dev/sde").
Schaue auch mal nach, was "ls -l /dev/sde*" liefert. Offset usw., die
der Kernel für diese effektiv ermittelt hat, kannst du so ermitteln:
https://unix.stackexchange.com/questions/335690/recovering-partitioning-information-from-block-devices#answer-335697
Das Problem ist, dass /dev/sde1 am Sektor 1 beginnt, da stimmt das
Alignment nicht. Evtl. hast Du die Platte mit einem alten Programm
partitioniert, mach das mal mit einem neuen Gparted. Vor dem 1.
benutzten Sektor sollten 2048 Sektoren frei sein!
Bei mir sieht das so aus:
1
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
2
/dev/sda1 * 2048 57738376 57736329 27,5G 83 Linux
3
/dev/sda3 57739264 1953327103 1895587840 903,9G 83 Linux
Was ich noch erlebt habe, sind unterschiedliche Blockgrößen, jenachdem
wie ich die Platte angeschlossen habe. Per USB-SATA-Adapter 4k-Blöcke,
direkt an SATA-Port des Motherboards 512-Byte-Blöcke. Da klappt dann
auch nichts.
Btw, wenn ich die Platte nur als eine große Partition brauche, spar ich
mir gerne die Partition-Table und benutze direkt /dev/sdX - kein
Gewurschtel mit GPT etc ...
Bei einer 2 TB-Platte wuerde ich nur einen MBR anlegen und gut ist.
Da braucht man das Gekasper mit GPT noch nicht.
Den MBR natuerlich ganz an den Anfang der Platte.
Erich schrieb:> Beim ersten mal hatte ich eine Platte am Usb Nachdem ich dann nochmal> eine Partition erstellt hatte und alles neu kopiert hatte funktionierte> es. Beim 2. Mal das war eine andere neue Platte. Ich hatte diese aus dem> Usbgehäuse geholt und per sata Kopiert und jetzt wieder das gleiche> Problem.
Lass mal den Teil mit USB komplett weg.
Die haben manchmal ihre eigenen Treiber für die Umsetzung von SATA auf
USB, manche (manche WD USB externe laufwerke) verstehen sogar
Dateisysteme, sind aber keine richtigen Festplatten mehr, nur noch
extern nutzbar.
D.h. wenn du deine SATA Platten per SATA Verbindung bespielst und danach
als SATA Platten nutzt, sind deine Chancen am grössten.
Erich schrieb:> Ich kann auf die Daten> zugreifen und ich denke alles ist toll. Dann hänge ich die Partition aus> stecke die Platte an ein Ubuntu 16 Rechner und sehe keine Partition.> Device Boot Start End Sectors Size Id Type> /dev/sde1 1 4294967295 4294967295 2T ee GPT>> Partition 1 does not start on physical sector boundary.> Zurück am U20 Server bleibt die Platte genauso ohne Partition.> Beim 2. Mal das war eine andere neue Platte. Ich hatte diese aus dem> Usbgehäuse geholt und per sata Kopiert und jetzt wieder das gleiche> Problem.>> Habt ihr das schon mal erlebt? wie könnte sich das erklären?> Bzw wo könnte der Fehler sein?
Ja, habe ich.
Und zwar über eSATA.
Ich hatte einmal, nach dem ich meine Rechner aufgerüstet habe vergessen
im BIOS für den für eSATA vorgesehen Port hot-plug auf enabled
einzuschalten.
Das führte dann beim Anschließen der Platte dazu, dass die Daten
scheinbar weg waren.
Außerdem meldete mir der Kernel noch Lesefehler.
Schau also mal ins BIOS/UEFI und sieh da nach, ob für den verwendeten
SATA Port hot-plug eingeschaltet ist.
Beachte dabei, dass leere Batterien zum Verlust der BIOS Einstellungen
führen und dann wieder BIOS Defaultwerte eingestellt werden. Wenn hier
der Default Wert der ist, dass die ganzen SATA ports bezüglich hot-plug
auf disabled stehen, dann musst du vor jeder Benutzung auch darauf
achten dass da keine Daten verloren gingen und die Batterie noch
ausreichend Energie hat.
Die Distri war damals auch Kubuntu 16.04 LTS, falls das wichtig ist.
Wegen GPT könnte es hilfreich sein die Distri upzudaten, so dass du von
etwaigen Korrekturen in den neuen Softwareversionen profitierst.
Mladen G. Aussage schließe ich mich an. Wenn du die Möglichkeit hast,
die Platte via (e)SATA an den PC anzuschließen, dann nutze diese
Möglichkeit. Achte aber wie oben angegeben auf die hot-plug Einstellung
im UEFI/BIOS.
Falls du die Platte vorher anschließt, bevor du den Rechner in Betrieb
nimmst und dann auch nicht vor dem Ausschalten des Rechners wieder
abstöpselst, ist das der Hot-Plug Einstellung natürlich egal.
Dennoch könnte es sein, dass man bei laufendem Rechner nicht darauf
achtet und dann braucht man diese. Also wenn du auf Nummer Sicher gehen
willst, dann aktiviere Hot-Plug.
bingo schrieb:> Das Problem ist, dass /dev/sde1 am Sektor 1 beginnt, da stimmt das> Alignment nicht. Evtl. hast Du die Platte mit einem alten Programm> partitioniert, mach das mal mit einem neuen Gparted. Vor dem 1.> benutzten Sektor sollten 2048 Sektoren frei sein!>
Wenn du Booten willst. Üblich, muss aber nicht so sein.
Einfach vielfache von 8 (4096/512) sollten es auch tun.
(g)parted kann man auch irgendeinen passenden Start geben,
z.B. verschieben auf Anfang 8Mb sollte so ein Prob. auch lösen.
Dann spielt auf die Sektorgröße auf anderem System keine Rolle.
Neu anlegen wird hier warscheinlich aber schneller gehen.
>>> schrieb:> bingo schrieb:>> Das Problem ist, dass /dev/sde1 am Sektor 1 beginnt, da stimmt das>> Alignment nicht. Evtl. hast Du die Platte mit einem alten Programm>> partitioniert, mach das mal mit einem neuen Gparted. Vor dem 1.>> benutzten Sektor sollten 2048 Sektoren frei sein!>>>> Wenn du Booten willst. Üblich, muss aber nicht so sein.> Einfach vielfache von 8 (4096/512) sollten es auch tun.> (g)parted kann man auch irgendeinen passenden Start geben,> z.B. verschieben auf Anfang 8Mb sollte so ein Prob. auch lösen.> Dann spielt auf die Sektorgröße auf anderem System keine Rolle.
Seine Partitionen fangen aber bei Sektor 1 an, das ist ganz schlimm, das
konvergiert weder mit 512- noch mit 4k-Sektoren, denn die Nummer des 1.
Sektors auf der Platte (HDD oder SSD) ist 0 !!!
Erich schrieb:> Device Boot Start End Sectors Size Id Type> /dev/sde1 1 4294967295 4294967295 2T ee GPT>> Partition 1 does not start on physical sector boundary.
Das erscheint mir eine Ausgabe von fdisk zu sein. Du kannst die Version
mit fdisk -l überprüfen, aber bei Xenial mit den letzten Updates sollte
das 2.27.1 sein. fdisk kann aber GPT erst seit 2.30.2, und auch das wohl
nicht vollständig.
Und auch der Rest des Systems könnte vielleicht nicht GPT-fähig sein,
also würde ich die Platte einfach mal probeweise mit MBR partitionieren.
bingo schrieb:> Seine Partitionen fangen aber bei Sektor 1 an, das ist ganz schlimm, das> konvergiert weder mit 512- noch mit 4k-Sektoren, denn die Nummer des 1.> Sektors auf der Platte (HDD oder SSD) ist 0 !!!
Eigentlich sollte das sowohl bei 512-Byte-Sektoren, als auch bei
4k-Sektoren egal sein. Ein Problem gibt es nur, wenn die Platte zwar
eigentlich 4k-Sektoren hat, aber nach außen hin so tut, als hätte sie
512-Byte-Sektoren.
Rolf M. schrieb:> bingo schrieb:>> Seine Partitionen fangen aber bei Sektor 1 an, das ist ganz schlimm, das>> konvergiert weder mit 512- noch mit 4k-Sektoren, denn die Nummer des 1.>> Sektors auf der Platte (HDD oder SSD) ist 0 !!!>> Eigentlich sollte das sowohl bei 512-Byte-Sektoren, als auch bei> 4k-Sektoren egal sein. Ein Problem gibt es nur, wenn die Platte zwar> eigentlich 4k-Sektoren hat, aber nach außen hin so tut, als hätte sie> 512-Byte-Sektoren.
Selbst dann sollte es funktionieren, allerdings mit einer üblen
»performance penalty«
Bedenklich finde ich das selbst heutzutage eine Samsung SSD 850 EVO
250GB das Folgende meldet:
1
# hdparm -I /dev/sda
2
ATA device, with non-removable media
3
Model Number: Samsung SSD 850 EVO 250GB
4
Serial Number: xxxxxxxxxxxxxxx
5
Firmware Revision: EMT02B6Q
6
Transport: SATA Rev 3.0
7
Configuration:
8
Logical max current
9
cylinders 16383 16383
10
heads 16 16
11
sectors/track 63 63
12
--
13
CHS current addressable sectors: 16514064
14
LBA user addressable sectors: 268435455
15
LBA48 user addressable sectors: 488397168
16
Logical Sector size: 512 bytes
17
Physical Sector size: 512 bytes
18
Logical Sector-0 offset: 0 bytes
19
device size with M = 1024*1024: 238475 MBytes
20
device size with M = 1000*1000: 250059 MBytes (250 GB)
Norbert schrieb:> Selbst dann sollte es funktionieren, allerdings mit einer üblen> »performance penalty«
Ja, richtig.
> Bedenklich finde ich das selbst heutzutage eine Samsung SSD 850 EVO> 250GB das Folgende meldet:
SSDs sind ja sowieso speziell, da sie in der Hinsicht komplett anders
arbeiten als Festplatten, aber nach außen hin das Verhalten einer
Festplatte emulieren. Ein Unterschied ist ja schon, dass SSDs intern
nicht nur die beiden Operationen "lesen" und "schreiben", sondern
zusätzlich noch eine dritte Operation "löschen" brauchen. Dazu kommt
noch, dass die Blockgröße, in der das stattfindet, für alle drei
Operationen unterschiedlich (und insbesondere für das Löschen auch sehr
viel größer als für die anderen) ist. Somit gibt es dort gar keine
klassische Sektorgröße. Es bleibt nur noch die quasi virtuelle
Sektorgröße der emulierten Festplatte übrig. Der SSD-Controller kümmert
sich dann darum, dass on-the-fly irgendwie passend auf den tatsächlichen
internen Aufbau zu übersetzen.
(prx) A. K. schrieb:> Norbert schrieb:>> Man beachte logical und physical sector size…>> Und was ist daran bedenklich?
Sie haben im Falle aller mir bekannten SSDs eine physikalische
›sector-size‹ von mindestens 4096B (4KiB) und eine (weniger wichtige)
›erase-block-size‹ von 2MiB.
Wenn sich das Betriebssystem nach den Angaben richten würde, so könnte
ein ›block-misalign‹ stattfinden (performance penalty, write
amplification)
Glücklicherweise schaut Linux (und soweit ich weiß mittlerweile auch
Win) nicht darauf und fängt bei den bereits zuvor mal erwähnten
2048*512B also 1MiB Grenzen an.
Norbert schrieb:> Sie haben im Falle aller mir bekannten SSDs eine physikalische> ›sector-size‹ von mindestens 4096B (4KiB) und eine (weniger wichtige)> ›erase-block-size‹ von 2MiB.
Seit Partitionierungstools kapiert haben, dass es eine saudumme Idee
war, eine Partition an Block #63 beginnen zu lassen (bis Win XP), ist
zumindest die 4K Thematik vom Tisch. Denn die üblichen Filesysteme wie
NTFS, ext4, xfs etc verwenden sowieso eine Blockgrösse von 4K.
Es ist wohl kein Problem, in hdparm 4K als physikalische Sektorgrösse
anzugeben, denn das machen diverse HDDs. Aber mehr als Schmuck fürs Auge
ist das nicht. Oder gibt es irgendeine Stelle in Betriebssystemen, die
sich für die Angabe der physikalischen Sektorgrösse interessiert, die
hdparm auswirft? Zumal der Mechanismus, den hdparm für
Informationsbeschaffung verwendet, bei meiner NVMe SSD nicht
funktioniert.
(prx) A. K. schrieb:> Seit Partitionierungstools kapiert haben, dass es eine saudumme Idee> war, eine Partition an Block #63 beginnen zu lassen …
Nun, ich kann mich noch gut an MFM und RLL Controller und die dazu
passenden Platten erinnert. Damals (letztes Jahrtausend) war es 'ne
clevere Idee die cylinder,head,sector Informationen zu nehmen. Dann kam
irgendwann der geschmeidige Übergang von CHS -> LBA. Der hätte einen
wirklich harten Schnitt gebraucht.
Verdammt, jetzt bin ich deprimiert. ;-)
Norbert schrieb:> Nun, ich kann mich noch gut an MFM und RLL Controller und die dazu> passenden Platten erinnert.
Wobei es allerdings auch Disks, die in ihrer Schnittstelle in CHS
adressiert wurden, ziemlich schnuppe war, wo eine Partition anfing. Das
hatte keine nennenswerten Folgen für die Performance. Partitionen an
Zylindern auszurichten war so gesehen nie wirklich nötig.
Obendrein wurde auf der CHS-Ebene bald gelogen, dass sich die Balken
biegen, sobald die Dinger gross genug waren um das Bitformat zu
sprengen. Da gab es dann eine echte phsikalische Struktur und eine
simulierte.
> irgendwann der geschmeidige Übergang von CHS -> LBA. Der hätte einen> wirklich harten Schnitt gebraucht.
Eigentlich nicht, denn bereits die Cluster-Nummerierung des FAT
Filesystems war von der CHS-Nummerierung losgelöst. Die Filesysteme
waren also von Anfang an unabhängig vom physikalischen Aufbau.
(prx) A. K. schrieb:> Eigentlich nicht, denn bereits die Cluster-Nummerierung des FAT> Filesystems war von der CHS-Nummerierung losgelöst. Die Filesysteme> waren also von Anfang an unabhängig vom physikalischen Aufbau.
Filesysteme ja, aber eine Etage tiefer?
Wenn ich mir den Krampf im MBR vorstelle, da haben wir selbst im 21.
Jahrhundert noch CHS Einträge. Kein Bezug zur Realität mehr, da steht
heute drin »Bitte weitergehen, hier gibt's nichts zu sehen«
Norbert schrieb:> Filesysteme ja, aber eine Etage tiefer?
Welche API-Ebene wäre das? Der Disk-Interrupt adressierte CHS, die
Filesysteme lineare Cluster. Was liegt dazwischen, das eine an Zylindern
orientierte Partitionierung sinnvoll machte? Also ausser geistiger
Trägheit oder mangelndem Abstraktionsvermögen.
Bei IBMs Mainframes rechnete man noch ewig in Zylindern. Ein User bekam
in den frühen Systemen einen Platz von soundsoviel Zylindern zugewiesen.
Das hielt sich auch noch, als das längst keine echten Zylinder mehr
waren, sondern bloss eine obskure Messeinheit für Plattenplatz.
(prx) A. K. schrieb:> Seit Partitionierungstools kapiert haben, dass es eine saudumme Idee> war, eine Partition an Block #63 beginnen zu lassen (bis Win XP), ist> zumindest die 4K Thematik vom Tisch. Denn die üblichen Filesysteme wie> NTFS, ext4, xfs etc verwenden sowieso eine Blockgrösse von 4K.
Ja, umso unsinniger ist es ja, wenn zwischen den logischen 4k-Blöcken
des Dateisystems und den internen 4k-Blöcken der Platte ein Layer liegt,
das das in imitierte 512-Byte-Sektoren um- und wieder zurückwandelt.
Es gibt ja durchaus Festplatten, die 4k-Sektoren haben und die auch nach
außen als solche durchreichen. Aber das scheint außer Mode gekommen zu
sein. Probleme mit Alignment der Sektoren kommen wie gesagt auch nur
dadurch. Warum man allerdings ausgerechnet Sektor 63 als Start gewählt
hat, hab ich auch nie verstanden.
> Es ist wohl kein Problem, in hdparm 4K als physikalische Sektorgrösse> anzugeben, denn das machen diverse HDDs. Aber mehr als Schmuck fürs Auge> ist das nicht. Oder gibt es irgendeine Stelle in Betriebssystemen, die> sich für die Angabe der physikalischen Sektorgrösse interessiert, die> hdparm auswirft? Zumal der Mechanismus, den hdparm für> Informationsbeschaffung verwendet, bei meiner NVMe SSD nicht> funktioniert.
Funktioniert er wirklich nicht, oder gibt die SSD einfach nur
Phantasiewerte an?
Rolf M. schrieb:> Funktioniert er wirklich nicht, oder gibt die SSD einfach nur> Phantasiewerte an?
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
> stecke die Platte an ein Ubuntu 16 Rechner und sehe keine Partition.> Device Boot Start End Sectors Size Id Type> /dev/sde1 1 4294967295 4294967295 2T ee GPT> Partition 1 does not start on physical sector boundary.> Zurück am U20 Server bleibt die Platte genauso ohne Partition.
sde1 ist doch die Partion, GPT ist der Typ.
Soll er sdpasseshalber den nächsten Superblock nehmen,
der jenseits der gpt liegt. mount auf den Weg geben.
dumpe2fs /dev/sde1 |grep -i superblock
mount ... sb=xy ...
---
Ich habe ab und zu auch das Problem wie der TO. Es kam hier zwei mal vor
bis jetzt. Linux Ext FS kopiert zuerst den Inhalt in Blöcken, und
schreibt erst danach die 'sichtbaren Dateien' (zugewiesen zu den
Blöcken) in das Dateisystem Journal - Mehr oder weniger.
Es schreibt aber leider den neuen Datei Index nicht immer in sein
Journal. Und aktualisiert das Dateisystem nicht. Der Inhalt der Datei
ist aber (irgendwo in den Blöcken) vollständig vorhanden.
Am problematischsten ist es, wenn man einen Ordner mit vielen Dateien
darin kopiert: Es sind ggf alle Dateien vorhanden, aber der eigentliche
Ordner ist nirgendwo zu sehen. Und somit hat man keinen Zugriff.
Man soll ja das Kommando 'synch' absetzen, um den Festplattencache
fertig rein zu schreiben bzw zu leeren. Um ggf noch offene schreibende
'Filehandles' zu schließen. Vor allem bei USB und Hotplug Geschichten.
Aber trotz sauberen 'unmount' und sogar 'synch' danach, gibt es
irgendwie "Verluste".
Habe mir daher angewöhnt, den Rechner komplett herunter zu fahren. Da
klappt es bislang immer. Aber bei Servern ist das natürlich
ausgeschlossen.
Man kann es anscheinend umstellen, dass Linux zuerst das Journal noch
vor den Blöcken schreibt. (Wie bei Windows) Der Nachteil ist aber, falls
das Kopieren abbricht (Stromausfall usw) dass dann Schrott im Filesystem
steht und Speicher irgendwie reserviert ist, zudem es aber keinen
richtigen Bezug in den Blöcken gibt. (...weil es noch nicht kopiert
wurde, aber trotzdem als 'falsche' und 'fehlerhafte' Datei im System
auffindbar ist.)
Hat jemand eine Idee was man da noch machen oder optimieren kann?
Norbert schrieb:> Sie haben im Falle aller mir bekannten SSDs eine physikalische> ›sector-size‹ von mindestens 4096B (4KiB) und eine (weniger wichtige)> ›erase-block-size‹ von 2MiB.
Dann sind hier Dein 1. und 2. Fall (zugegeben schon etwas betagt):
bingo schrieb:>>>> schrieb:>> bingo schrieb:>>> Das Problem ist, dass /dev/sde1 am Sektor 1 beginnt, da stimmt das>>> Alignment nicht. Evtl. hast Du die Platte mit einem alten Programm>>> partitioniert, mach das mal mit einem neuen Gparted. Vor dem 1.>>> benutzten Sektor sollten 2048 Sektoren frei sein!>>>>>>> Wenn du Booten willst. Üblich, muss aber nicht so sein.>> Einfach vielfache von 8 (4096/512) sollten es auch tun.>> (g)parted kann man auch irgendeinen passenden Start geben,>> z.B. verschieben auf Anfang 8Mb sollte so ein Prob. auch lösen.>> Dann spielt auf die Sektorgröße auf anderem System keine Rolle.>>> Seine Partitionen fangen aber bei Sektor 1 an, das ist ganz schlimm, das> konvergiert weder mit 512- noch mit 4k-Sektoren, denn die Nummer des 1.> Sektors auf der Platte (HDD oder SSD) ist 0 !!!
Nö.
Sektorgröße logisch/physisch u. Wahl des Startsektor haben mit dem
Problem hier doch nichts zu tun. GPT das warum auch immer hier die
gesamte Platte einnimmt ist halt kein extFS, 83/LINUX
Falls da drin tatsächlich ein extFS drinstecken sollte wird z.B.
dumpe2fs die Signaturen schon finden, wenn nich gibts dort auch keine
Daten, wo immer sie dann auch gelandet sein mögen.
Dein Vorredner hatte das schon richtig erkannt:
>>> Was da angezeigt wird ist eine GPT Protektive Partition in einem
protektiven MBR.
----
>>>> Ich habe ab und zu auch das Problem wie der TO.
?
>>>> Es kam hier zwei mal vor
Darin erschöpft sich die Geminsamkeit ;)
bingo schrieb:> (prx) A. K. schrieb:>> Wobei ein umount den sync bereits enthält.>> Sollte theoretisch so sein, ich bin ich mir aber nicht sicher.
Iss so!
Aber der Hardware Buffer könnte (rein theoretisch) eventuell bei
externen USB-Drives noch Probleme machen. Habe ich aber noch nie
beobachten können.
hdparm -fF <device>
-f Sync and flush the buffer cache for the device on exit.
-F Flush the on-drive write cache buffer
>>> schrieb:>> stecke die Platte an ein Ubuntu 16 Rechner und sehe keine Partition.>> Device Boot Start End Sectors Size Id Type>> /dev/sde1 1 4294967295 4294967295 2T ee GPT>>> Partition 1 does not start on physical sector boundary.>> Zurück am U20 Server bleibt die Platte genauso ohne Partition.>> sde1 ist doch die Partion, GPT ist der Typ.
Ja, aber GPT ist der Typ der Partitionstabelle. Normalerweise müsste da
der Typ der Partition stehen.
Rolf M. schrieb:>> sde1 ist doch die Partion, GPT ist der Typ.>> Ja, aber GPT ist der Typ der Partitionstabelle. Normalerweise müsste da> der Typ der Partition stehen.
Nicht aber, beides heißt abgekürzt GPT. Als Partitionstyp (ID ee) ist
GPT die Abkürzung für "Dies ist eine Partition, in der man
GPT-Partitionen verstecken kann".
Alte Programme und Betriebssysteme, die keine GPT-Tabelle kennen, sehen
genau eine unbekannte Partition. Aktuelle Software ignoriert den alten
MBR und liest die GPT-Tabelle.
Edit:
https://en.wikipedia.org/wiki/GUID_Partition_Table#Protective_MBR_(LBA_0)
�� DPA �� schrieb:> z.B. gdisk>
hat eine interessante Option das Tool;
recovery and transformation
GPT to MBR (r,g,[w])
g
Convert GPT into MBR and exit.
This option converts as many partitions as possible into MBR form,
destroys the GPT data structures, saves the new MBR, and exits.
Use this option if you've tried GPT and find that MBR works better for
you....
----
Kommt halt drauf an was und wieviel tatsächlich drauf ist
und ob es ins alte Schema paßt.
thanks, bye.
>Device Boot Start End Sectors Size Id Type>/dev/sde1 1 4294967295 4294967295 2T ee GPT
Das ist die Information des MBR in Sektor 0.
Der macht eine Partition des Typs GPT (ID 0xEE) von Sektor eins bis zum
letzten Sektor. Dadurch ist die komplette Platte "voll"
Dein BS sollte also so clever sein,die GPT einzulesen, und diese
Informationen zu nutzen.
Idee: steht eventuell in deinem Sektor 0 am Ende (Adresse 510..511)
nicht 55 AA
Thread beobachten
Seitenaufteilung abschalten