Partitionstabellen aller Art zuverlässig löschen - wie?

[meti]

Ich hantiere desöfteren mit verschiedenen Festplatten rum. Daher auch mit verschiedenen Typen von Partitionstabellen. Alles kein Problem, aber das sichere und vollständige Löschen einer Partitionstabelle ist mir bisher nicht immer gelungen.

Bei den meisten Partitionstabellen mache ich das mit

Code: Alles auswählen

dd if=/dev/urandom of=/dev/sdx bs=1K count=1024

Damit ist fast immer alles gelöscht da das erste MB komplett überschrieben wird.

Wenn ich aber eine GPT Tabelle löschen will, dann krieg ich das eigentlich nie zuverlässig hin. Warum auch immer.
Die Partitionstabelle ist bei GPT ja am Anfang der Platte gespeichert und eine Kopie ist am Ende der Platte gespeicherrt. Wie krieg ich das zuverlässig gelöscht ohne die komplette Platte überschreiben zu müssen? Also im Idealfall nur exakt die Sektoren zu überschreiben die mit GPT belegt sind. Ideen dazu? Gibts vielleicht ne fertige Lösung? Die Lösung muss/sollte bei Debian in main zu finden sein. Mindestanforderung allerdings das es bei allen wichtigen Ports (i386, amd64, powerpc, sparc, kfreebsd-64) bei Debian Stable/testing im Repository per apt zu finden ist.

Noch ne Frage: wie kann ich dem Linux-Kernel bzw. auch dem BSD Kernel bei kFreeBSD klarmachen das eine Platte keine Partitionstabelle mehr hat, also das System nicht mit irgendwelchen Cache-Daten arbeitet? Kann da einer helfen?

[shakky4711]

Hallo,

im FreeNAS Forum hatte mal jemand dieses Script veröffentlicht

Code: Alles auswählen

#!/bin/sh
echo "What disk do you want"
echo "to wipe? For example - da1 :"
read disk
echo "OK, in 10 seconds I will destroy all data on $disk!"
echo "Press CTRL+C to abort!"
sleep 10
diskinfo ${disk} | while read disk sectorsize size sectors other
do
        # Delete MBR and partition table.
        /bin/dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
        # Delete GEOM metadata.
        /bin/dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors - 2` count=2
done

Gruß
Shakky

[Cae]

Nur schade, dass es ein Programm diskinfo nicht in den Repositorys gibt. Man findet [1], das scheint Pascal mit cmd-Skripten zu sein, unter bin/release liegt eine Win32-exe (wtf?). Vielleicht magst du einen Link dazuposten, damit man den Kontext versteht. Ah, gefunden, das scheint aus dem Wiki [2] dort zu sein. Allerdings ohne weitere Erwähnung, was dieses diskinfo sein soll. Übrigens auch im Kontext "ZFS sperrt da was", also nicht zwangsläufig auf Partitionierungsebene.

Gruß Cae

[1] https://github.com/Xail/disk-info
[2] http://wiki.freenas.org/faq:0129

[rendegast]

Als Ersatz für 'diskinfo' für die Plattengröße gibt es

Code: Alles auswählen

# cat /sys/block/sda/size 
156368016

für die Anzahl der 512b-Blöcke.

[shakky4711]

Hallo,

tut mir Leid dass ich das nicht geschrieben habe, habe hier auch FreeBSD Maschinen laufen und der Begriff GPT legt in mir immer einen Richtungspfeil zu FreeBSD, dort ist "diskinfo" im Basissystem enthalten. Es geht auch eine NAS4Free Live CD http://www.nas4free.org

Gruß
Shakky

[cirrussc]

Noch ne Frage: wie kann ich dem Linux-Kernel bzw. auch dem BSD Kernel bei kFreeBSD klarmachen das eine Platte keine Partitionstabelle mehr hat, also das System nicht mit irgendwelchen Cache-Daten arbeitet? Kann da einer helfen?

Code: Alles auswählen

hdparm -z /dev/sda
blockdev --rereadpt

usw.
http://wiki.debianforum.de/Hdparm#Tipps ... Funktionen

ps: Warum /dev/random? Ein MBR ist mit Nullen ebenso gelöscht. Außerdem gibt es Software, die sich an keine Platten traut, die irgendwelchen Inhalt (alles außer Nullen) beinhalten.

[meti]

So langsam wird das richtig interressant. Wäre vielleicht nen Wiki Artikel wert ...


@cirrussc
Warum /dev/urandom anstatt /dev/null? Keine Ahnung ... ich habs einfach als Platzhalter hingeschrieben weil ich davon ausgegangen bin das lauter Nullen ebenso zuverlässig eine Partitionstabelle killen können wie zufälliger Datenmüll.

Aber wenn das einen realen Grund hat /dev/urandom nicht zu verwenden dann hab ich was dazugelernt.

[cirrussc]

Aber wenn das einen realen Grund hat /dev/urandom nicht zu verwenden dann hab ich was dazugelernt.

Macht sich zwar bei den paar Byte nicht bemerktbar, aber /dev/random ist zusätzlich langsam und belastet die CPU. Anders gesagt gibt es keinen Grund, dieses statt /dev/zero zu verwenden.