Mein Multiboot-USB-Laufwerk (das auch als normales USB-Laufwerk verwendet wird) funktioniert nicht richtig. Damit meine ich, dass ich einen Computer nicht dazu bringen kann, zu erkennen, dass es sich um ein USB-Flash-Laufwerk handelt. Am nächsten komme ich dem unter Ubuntu Live OS. Ich kann im Dashboard nach „Laufwerk“ suchen und die Liste der Laufwerkgeräte oder wie auch immer der genaue Wortlaut lautet, aufrufen. Es erkennt allesanderswie es sollte, alle meine Partitionen usw., und dann erkennt es meinen USB. Es gibt keine Option, irgendetwas Nützliches zu tun, da in Rot „kein Medium“ steht, anstatt eine Option zum Mounten zu geben. Es ist hier als „XXXXXXXX U168CONTROLLER“ aufgeführt, falls das hilft.
Fdisk findet es nicht. lsblk findet mein Gerät nicht. lsusb gibt zurück
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 002 Device 002: ID 8087:8000 Intel Corp.
Bus 003 Device 002: ID 046d:c32b Logitech, Inc.
Bus 003 Device 003: ID 046d:c24c Logitech, Inc.
Bus 003 Device 006: ID 041e:323c Creative Technology, Ltd
Bus 003 Device 005: ID 1b1c:1a95 Corsair
Bus 003 Device 007: ID 048d:1168 Integrated Technology Express, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Aber machen Sie sich keine falschen Hoffnungen, denn obwohl ein Corsair-Gerät angezeigt wird, handelt es sich um einen zweiten USB-Stick, den ich verwende, um das Live-Betriebssystem auszuführen. Es ist ein 32-GiB-Laufwerk, und das Laufwerk mit dem besagten Problem ist 64 GiB groß. Das ist also mein Problem.
Nun zu der Frage, was die Ursache gewesen sein könnte …
Theorie eins:Ich war gerade dabei, Arch erneut auf meinem Desktop zu installieren, diesmal mit UEFI und GPT statt BIOS und MBR. Ich habe Partitionen mit parted eingerichtet und ich glaube, das war die Ursache für mein Problem, aber ich bin mir dessen NICHT sicher und es ergibt für mich auch keinen Sinn. Ich glaube, der Grund dafür ist folgender: Ich arbeite daran, meine Festplatte zu formatieren, um Home-, Boot- und Swap-Werte einzurichten. Home und Swap sind bereits vorhanden, also habe ich daran gearbeitet, die Boot-Partition hinzuzufügen. Ich habe die Home-Partition verkleinert und die Boot-Partition hinzugefügt. Es ist möglich, dass dies nicht die Festplatte war, sondern mein Multiboot-USB-Stick, obwohl ich an /dev/sda gearbeitet habe, das meine Winderp$-Partition sowie die Arch-Partition enthält. USB hätte zu diesem Zeitpunkt /dev/sdc sein sollen, wobei /dev/sdb meine SSD war.
Gleich nachdem ich meinen Live-USB-Stick heruntergefahren hatte, reagierte das Laufwerk auf nichts mehr. Habe es auf 4 verschiedenen Computern und 6 verschiedenen Betriebssystemen mit 4 BIOS und einem UEFI versucht. Außer einem Ubuntu-Live-Betriebssystem wurde es beim Auflisten der Laufwerke/Geräte mit dem oben genannten Programm nicht erkannt. Das lässt mich glauben, dass ich beim Formatieren einen Fehler gemacht habe.
Theorie zwei:Ich bin gezwungen, E2B zu verwenden, um meine Multiboot-Anforderungen zu erfüllen, was einige spezielle Dinge erfordert, um im UEFI-Modus zwischen Payloads zu wechseln. Dazu gehört das Booten über das BIOS, das Zurücksetzen des USB-Sticks in den BIOS-Modus, die Auswahl der neuen Payload und das Zurückkonvertieren des Laufwerks in den UEFI-Modus. Ich kann dies mit einem QEMU-Emulator tun, sodass ich der Portabilität halber eine einfache .exe habe, die ich verwende, um Dinge schnell umzuschalten.
Kurz bevor ich mit der Installation von Arch begann, habe ich das Laufwerk in den Arch UEFI-Modus versetzt. Nachdem dies abgeschlossen war, klickte ich auf „Laufwerk sicher entfernen“ und entfernte es, sobald das Popup angezeigt wurde. Anscheinend war es noch in Gebrauch (blödes Winderp$), aber ich hatte das Laufwerk bereits entfernt, bevor mir klar wurde, was ich falsch gemacht hatte. Ich glaube nicht wirklich, dass dies das Problem verursacht, insbesondere wenn man bedenkt, dass es direkt danach gebootet hat, aber je mehr Informationen, desto besser.
Ich kann es also in Gparted nicht als Laufwerk anzeigen, fdisk, lsblk usw. können es nicht finden, und /dev/sdd (der nächste Buchstabe in der Reihenfolge, also der, der es wäre) existiert nicht. lsusb sieht es wahrscheinlich als „Linux Foundation 2.0 Root Hub“, aber ich weiß nicht, wie ich feststellen kann, ob das stimmt oder nicht. Programme wie TestDisk, PhotoRec, Clonezilla oder ähnliches sehen das Gerät nicht, also kann ich es nicht einfach neu formatieren und hinter mich bringen.
Ich kann alle Befehle ausführen, die Sie von mir verlangen, aber da ich derzeit keine funktionierende Linux-Partition habe, wird sie, sofern nicht anders erforderlich, von einem aktiven USB-Stick ausgeführt. Ich kann immer eine schnelle Ubuntu-Installation zusammenstellen, wenn es wirklich nötig ist.
Ich hoffe, dass ich meine Daten nicht verliere und zumindest die meisten davon wiederherstellen kann, aber das ist nicht notwendig. Wenn ich es formatieren MUSS, um meinen USB-Stick wieder in ein funktionierendes Format zu bringen, ist mir das egal. Ich würde lieber alle unsere Ressourcen darauf verwenden, meine Daten zu retten, bevor wir neu formatieren müssen. Ich habe hier einige Dinge, die ich nirgendwo anders habe (dumm, ich weiß. Ich erstelle regelmäßig Backups meiner Standarddaten, habe das nie in Betracht gezogen).
Ich verwende Winderp$ erneut und warte auf Hilfe, da mir die Optionen ausgehen, bis ich Vorschläge bekomme. Mir ist aufgefallen, dass die Systemzeit falsch ist, aber ich kann nicht mit Sicherheit sagen, ob das relevant ist oder nicht. Keine meiner beiden Theorien scheint plausibel, da man beim Eintippen von parted /dev/sda/... nur schwer einen Fehler machen kann. Während ich in dieser parted-Sitzung bin, bin ich mir ziemlich sicher, dass ich nicht einmal auf /sdc/ zugreifen kann, also kann ich nicht erkennen, wie es ein Benutzerfehler sein könnte, obwohl es immer einer ist.
Antwort1
Erstens würde ich nicht viel darauf vertrauen, dass sich die Daten von diesem Laufwerk wiederherstellen lassen.
Zweitens: Führen Sie dmesg | tail -n 20vor und nach dem Anschließen Ihres USB-Laufwerks aus. Wenn keine Kernel-Meldung angezeigt wird, ist Ihr Laufwerk höchstwahrscheinlich komplett tot. Wenn Ihr Kernel das USB-Laufwerk erkennt, /dev/sdXihm aber kein Blockgerät () zuweisen kann, handelt es sich um ein Firmware-Problem (Sie können versuchen, es mit URescue wiederherzustellen). In beiden Fällen können Sie es zur RMA an Corsair senden.
So dmesgmeldet sich ein eingestecktes USB-Gerät:
[433011.248119] usb 2-1.2: new high-speed USB device number 10 using ehci-pci
[433011.334351] usb 2-1.2: New USB device found, idVendor=0781, idProduct=5583
[433011.334359] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[433011.334363] usb 2-1.2: Product: Ultra Fit
[433011.334367] usb 2-1.2: Manufacturer: SanDisk
[433011.334370] usb 2-1.2: SerialNumber: 4C5350122032812026
[433011.337486] usb-storage 2-1.2:1.0: USB Mass Storage device detected
[433011.338327] scsi host18: usb-storage 2-1.2:1.0
[433012.341971] scsi 18:0:0:0: Direct-Access SanDisk Ultra Fit 1.00 PQ: 0 ANSI: 6
[433012.343395] sd 18:0:0:0: [sdc] 60751872 512-byte logical blocks: (31.1 GB/28.9 GiB)
[433012.344718] sd 18:0:0:0: [sdc] Write Protect is off
[433012.344724] sd 18:0:0:0: [sdc] Mode Sense: 43 00 00 00
[433012.344990] sd 18:0:0:0: Attached scsi generic sg1 type 0
[433012.346597] sd 18:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[433012.377606] sdc: sdc1 sdc2 sdc3
[433012.381726] sd 18:0:0:0: [sdc] Attached SCSI removable disk