Mein alter Laptop ist gestern Morgen kaputtgegangen, aber die Festplatte funktioniert noch.
Als mein Bruder Ubuntu installierte, entschied er sich, den homeOrdner zu verschlüsseln. Wenn ich also versuche, die Festplatte auf einem anderen Computer zu verwenden, werde ich nach der Passphrase der Festplatte gefragt. Ich habe meinen Bruder bereits danach gefragt, und er hat keine Ahnung, wo die alte Passphrase ist (es ist 3 Jahre her).
Meine Fragen:
Gibt es eine Möglichkeit, die Festplatte vollständig zu löschen oder so zu formatieren, dass sie für eine andere Installation verwendet werden kann?
Falls dies nicht möglich ist, gibt es einen Hardware- oder BIOS-Trick, mit dem ich das Laufwerk entsperren kann?
Einige nützliche Informationen:
Wenn ich den Befehl versuche, sudo mount /dev/sdb /mnt/hd2erhalte ich den folgenden Fehler:
mount: /dev/sdb: can't read superblock
Wenn ich versuche, die Partitionstabelle anzuzeigen, sudo fdisk -l /dev/sdberhalte ich Folgendes:
fdisk: cannot open /dev/sdb: Input/output error
Ich kann nicht mit Sicherheit sagen, ob es ein Passwort auf BIOS-Ebene gab.
Und der sudo fsck /dev/sdbBefehl gibt die folgende Ausgabe aus:
fsck from util-linux 2.28.1
e2fsck 1.43.1 (08-Jun-2016)
fsck.ext2: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdb
Could this be a zero-length partition?
Was das physische Problem angeht, wenn ich die Festplatte anschließe, wird kein Problem angezeigt /dev, es gibt keine Klickgeräusche und die dmesg | tailAusgaben sind wie folgt:
[11267.246656] sd 51:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 00 00 02 00 00 02 00
[11267.246659] blk_update_request: critical medium error, dev sdb, sector 2
[11267.246665] Buffer I/O error on dev sdb, logical block 1, async page read
[11267.265418] sd 51:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[11267.265426] sd 51:0:0:0: [sdb] tag#0 Sense Key : Medium Error [current]
[11267.265431] sd 51:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read error
[11267.265436] sd 51:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 00 00 04 00 00 04 00
[11267.265440] blk_update_request: critical medium error, dev sdb, sector 4
[11267.265445] Buffer I/O error on dev sdb, logical block 2, async page read
[11267.265449] Buffer I/O error on dev sdb, logical block 3, async page read
Ich denke, dass die meisten dieser Fehler darauf zurückzuführen sind, dass das System die Partitionstabelle des Geräts nicht lesen kann, da diese verschlüsselt ist.
Schließlich befindet sich auf diesem Laufwerk auch eine Windows-Partition, falls das einen Unterschied macht.
Wenn Sie weitere Informationen benötigen, gebe ich diese gerne weiter. Ich kann auch sagen, dass die Wiederherstellung persönlicher Daten in diesem Fall nicht meine Priorität ist, sondern eher die Möglichkeit, das Laufwerk wieder verwenden zu können. Außerdem entschuldige ich mich für meine Englischfehler oder die falsche Formatierung.
AKTUALISIERUNG 1
Nachdem ddich fertig bin, stehe ich vor einem seltsamen Problem. Die Festplatte, die 500 GB groß ist, wird als 2 GB angezeigt, selbst nachdem ich sie mit formatiert habe gparted. Und selbst nach der Formatierung wird sie, wenn ich sie in der GUI anzeige gparted, wie folgt angezeigt:
AKTUALISIERUNG 2
ddberichtete, dass 2 GB geschrieben wurden, was vermutlich der Bootsektor oder etwas Ähnliches war.
sudo fdisk -l /dev/sdbAusgabe:
Disk /dev/sdb: 1,9 GiB, 1994428416 bytes, 3895368 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
lsblk /dev/sdbAusgabe:
lsblk: /dev/sdb: not a block device
sudo parted /dev/sdb printAusgabe:
Error: /dev/sdb: unrecognised disk label
Model: (file)
Disk /dev/sdb: 1994MB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
sudo hdparm -I /dev/sdbAusgabe:
/dev/sdb:
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
Ich kann nur vermuten, dass das Laufwerk währenddessen ausgehängt ddund sehr schnell wieder eingehängt wurde, was etwas durcheinander gebracht hat. Trotzdem weiß ich nicht genau, was los ist. Soll ich ddes noch einmal versuchen?
AKTUALISIERUNG 3
Wie gewünscht file /dev/sdberhalte ich folgende Ausgabe:
/dev/sdb: data
AKTUALISIERUNG 4
Ich glaube, ich habe etwas gefunden, das hilfreich sein kann, um zu verstehen, was passiert. Hier ist ein Screenshot ddmit angeschlossenem Laufwerk:
Und hier, nachdem das Laufwerk physisch getrennt wurde:
Wie Sie sehen, liegt kein Fehler wegen /dev/sdbNichtvorhandenseins mehr vor und es wird immer noch in ls aufgeführt, wie Sie im folgenden Screenshot sehen können:
Mir ist auch die andere sdbangezeigte Farbe aufgefallen; sie ist auch bei angeschlossenem Laufwerk die gleiche.
So wie ich es verstehe, ist dieses „Geistergerät“ für das ddProblem verantwortlich. Gibt es eine Möglichkeit, es loszuwerden?
AKTUALISIERUNG 5
Ich habe rmdie „Geisterdatei“ immer gelöscht, aber ich habe immer noch keine Ahnung, wie sie dort gelandet ist. Wenn ich jetzt ausführe dd, wird mir nicht angezeigt, dass 2 GB geschrieben wurden, und wie Sie sehen können, wird die Festplatte nach einem kurzen Durchlauf und einer Unterbrechung „korrekt“ in angezeigt gparted:
Trotzdem gpartederhalte ich beim Öffnen zahlreiche Fehlerfenster wie dieses:
Ähnliche Fenster werden angezeigt, wenn ich versuche, eine neue Partitionstabelle zu erstellen oder eine neue Partition auf dem Laufwerk zu erstellen. Bedeutet das, dass ich dddas gesamte Gerät ausführen muss oder dass das Laufwerk physisch beschädigt ist? Eine Sache, die Sie beachten sollten, ist, dass ich die Option status=progresszum ddBefehl hinzugefügt habe und nach einiger Ausführungszeit (nicht immer in derselben Größe) keine Fortschrittsaktualisierungen mehr angezeigt werden und ich nicht sicher bin, ob ddes in einem fehlerhaften Sektor oder so etwas feststeckt. Der Befehl, den ich jetzt verwende, ist sudo dd if=/dev/zero of=/dev/sdb bs=4M status=progress.
AKTUALISIERUNG 6
Ich habe also gnome-disksnicht die Möglichkeit (zumindest wird sie nicht aktiviert), einen Selbsttest des Laufwerks durchzuführen. Trotzdem habe ich versucht, es zu verwenden gsmartcontrol, und das hier ist das Ergebnis:
Und wenn ich versuche, mit diesem Tool einen Selbsttest durchzuführen, erhalte ich diesen Fehler.
Wenn ich die Befehlszeilenversion verwende, sudo smartctl /dev/sdb -asollte mir das Ausführen die SMART-Informationen liefern. Da die Ausgabe ziemlich lang war, habe ich sie in Pastebin eingefügt, weil ich nicht sicher war, ob dieser Beitrag zu lang wurde.
Der Ausgabe zufolge gibt es viele Fehler, aber ich bin nicht sicher, ob diese wegen des Problems mit dem verschlüsselten Laufwerk auftreten.
LETZTES UPDATE
Da auf dem Laufwerk ein BIOS-Passwort aktiv ist und der alte Computer kaputt ist, bleibt nichts weiter zu tun, als ein neues Laufwerk zu kaufen. Ich markiere diesen Beitrag als erledigt. Vielen Dank an alle, die mitgemacht und Gedanken dazu geäußert haben.
Antwort1
Wenn ich also versuche, die Festplatte auf einem anderen Computer zu verwenden, werde ich nach der Passphrase der Festplatte gefragt.
Lesen Sie sorgfältig. Ihre Festplatte ist verschlüsselt. Vielleicht ist es auch Ihr Ubuntu-Home-Ordner, aber die Festplatte selbst ist ebenfalls verschlüsselt. Normalerweise kann die Verschlüsselung im BIOS aktiviert und deaktiviert werden, wenn Sie das Kennwort haben. Wenn Sie großes Pech haben, wurde das Laufwerk über TPM-Chips auf dem alten Computer verschlüsselt, wo Sie das Kennwort sowieso nicht wiederherstellen können. Lesen Sie die Dokumentation des Systems, in dem sich die Festplatte befand.
Deshalb meldet Smart so viele Fehler. Jeder SATA-Befehl wird ignoriert, weil das Laufwerk zuerst eine Autorisierung verlangt.