Vorsicht beim Anschluss von USB-Festplatten an unbeaufsichtigte Server

Ich kann aus eigener Erfahrung nur davor warnen, USB-Geräte (v.a. USB-Festplatten) an unbeaufsichtigte Server anzuschließen, ohne vorher mehrfach über die potentiellen Folgen nachgedacht zu haben.

In meinem Fall habe ich – für interne VM-Backups – zwei USB-Festplatten an meinen Fujitsu-Server mit PROXMOX angeschlossen. So weit, so problemlos.

Nun habe ich jedoch in der GUI von PROXMOX einen kleinen Fehler gemacht und die gemountete Festplatte mit 8TB versehentlich für eine VM freigegeben. Daraufhin war die Platte nicht mehr ansprechbar und dmesg warf ganz unterschiedliche Fehler. Vielleicht ist die Platte auch "plötzlich" defekt – die Fehlermeldungen sind da nicht ganz eindeutig. Tut am Ende aber auch nichts zur Sache, denn die Platte ist aktuell nicht mehr nutzbar.

Als erste Maßnahme habe ich daher mittels usbreset das Gerät zurückgesetzt. Leider hat das nicht wirklich geholfen, denn auch nach dem Reset bleiben die Fehler weiterhin erhalten.

Hier der Auszug aus dmesg:

kernel: EXT4-fs (sde1): error count since last fsck: 5
kernel: EXT4-fs (sde1): initial error at time 1671131374: ext4_get_inode_loc:4426: inode 170393601: block 1363148832
kernel: EXT4-fs (sde1): last error at time 1671228222: ext4_journal_check_start:83
kernel: sd 9:0:0:0: [sde] tag#13 timing out command, waited 180s
kernel: sd 9:0:0:0: [sde] tag#13 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=180s
kernel: sd 9:0:0:0: [sde] tag#13 Sense Key : Not Ready [current]
kernel: sd 9:0:0:0: [sde] tag#13 Add. Sense: Logical unit is in process of becoming ready
kernel: sd 9:0:0:0: [sde] tag#13 CDB: Read(16) 88 00 00 00 00 03 a3 81 27 80 00 00 00 08 00 00
kernel: blk_update_request: I/O error, dev sde, sector 15628052352 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
kernel: sd 9:0:0:0: [sde] tag#4 timing out command, waited 180s
kernel: sd 9:0:0:0: [sde] tag#4 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=180s
kernel: sd 9:0:0:0: [sde] tag#4 Sense Key : Not Ready [current]
kernel: sd 9:0:0:0: [sde] tag#4 Add. Sense: Logical unit is in process of becoming ready
kernel: sd 9:0:0:0: [sde] tag#4 CDB: Read(16) 88 00 00 00 00 03 a3 81 27 80 00 00 00 08 00 00
kernel: blk_update_request: I/O error, dev sde, sector 15628052352 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
kernel: Buffer I/O error on dev sde1, logical block 1953506288, async page read
kernel: usb 2-5.1: USB disconnect, device number 4
kernel: sd 9:0:0:0: [sde] Synchronizing SCSI cache
kernel: sd 9:0:0:0: [sde] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
kernel: usb 2-5: reset SuperSpeed USB device number 3 using xhci_hcd
kernel: usb 2-5.1: new SuperSpeed USB device number 5 using xhci_hcd
kernel: usb 2-5.1: New USB device found, idVendor=0bc2, idProduct=ab38, bcdDevice= 1.00
kernel: usb 2-5.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
kernel: usb 2-5.1: Product: Backup+ Hub BK
kernel: usb 2-5.1: Manufacturer: Seagate
kernel: usb 2-5.1: SerialNumber: XXX
kernel: scsi host9: uas
kernel: scsi 9:0:0:0: Direct-Access
kernel: sd 9:0:0:0: Attached scsi generic sg4 type 0
kernel: sd 9:0:0:0: [sde] Spinning up disk...
kernel: ..................................................................................................not responding...
kernel: sd 9:0:0:0: [sde] 15628053167 512-byte logical blocks: (8.00 TB/7.28 TiB)
kernel: sd 9:0:0:0: [sde] 4096-byte physical blocks
kernel: sd 9:0:0:0: [sde] Test WP failed, assume Write Enabled
kernel: sd 9:0:0:0: [sde] Asking for cache data failed
kernel: sd 9:0:0:0: [sde] Assuming drive cache: write through
kernel: sd 9:0:0:0: [sde] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
kernel: sd 9:0:0:0: [sde] Spinning up disk...
kernel: ..................................................................................................not responding...
kernel: sd 9:0:0:0: [sde] tag#16 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD IN
kernel: sd 9:0:0:0: [sde] tag#16 CDB: Read(16) 88 00 00 00 00 00 00 00 00 07 00 00 00 01 00 00
kernel: sd 9:0:0:0: [sde] tag#15 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD IN
kernel: sd 9:0:0:0: [sde] tag#15 CDB: Read(16) 88 00 00 00 00 00 00 00 00 06 00 00 00 01 00 00
kernel: sd 9:0:0:0: [sde] tag#14 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD IN
kernel: sd 9:0:0:0: [sde] tag#14 CDB: Read(16) 88 00 00 00 00 00 00 00 00 05 00 00 00 01 00 00
kernel: sd 9:0:0:0: [sde] tag#13 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN
kernel: sd 9:0:0:0: [sde] tag#13 CDB: Read(16) 88 00 00 00 00 00 00 00 00 04 00 00 00 01 00 00
kernel: scsi host9: uas_eh_device_reset_handler start
kernel: usb 2-5.1: reset SuperSpeed USB device number 5 using xhci_hcd
kernel: scsi host9: uas_eh_device_reset_handler success
kernel: scsi host9: uas_eh_device_reset_handler start
kernel: sd 9:0:0:0: [sde] tag#4 uas_zap_pending 0 uas-tag 5 inflight: CMD
kernel: sd 9:0:0:0: [sde] tag#4 CDB: Read(16) 88 00 00 00 00 00 00 00 00 04 00 00 00 01 00 00
kernel: sd 9:0:0:0: [sde] tag#5 uas_zap_pending 0 uas-tag 6 inflight: CMD
kernel: sd 9:0:0:0: [sde] tag#5 CDB: Read(16) 88 00 00 00 00 00 00 00 00 05 00 00 00 01 00 00
kernel: sd 9:0:0:0: [sde] tag#6 uas_zap_pending 0 uas-tag 7 inflight: CMD
kernel: sd 9:0:0:0: [sde] tag#6 CDB: Read(16) 88 00 00 00 00 00 00 00 00 06 00 00 00 01 00 00
kernel: sd 9:0:0:0: [sde] tag#7 uas_zap_pending 0 uas-tag 8 inflight: CMD
kernel: sd 9:0:0:0: [sde] tag#7 CDB: Read(16) 88 00 00 00 00 00 00 00 00 07 00 00 00 01 00 00
kernel: usb 2-5.1: reset SuperSpeed USB device number 5 using xhci_hcd

[...]

Daraufhin habe ich den PROXMOX-Host neu gestartet, da ich mir davon einen umfänglicheren Reset der USB-Festplatte erhofft habe. Doch damit habe ich einen großen Fehler gemacht. Der Host fährt jetzt nämlich überhaupt nicht mehr hoch.

Schaue ich über die Funktion Console Redirection des iRMC von Fujitsu auf die Maschine, sehe ich, dass das BIOS bei Fehlercode B4 hängen bleibt (BIOS POST Watchdog-Aktion: Power Cycle (Post-Code: 0xB4)). Welch Überraschung – ein USB-Fehlercode.

Also dachte ich, ich deaktiviere einfach die USB-Ports im BIOS und versuche daraufhin den Server zu starten. Das hat auch geklappt, doch fährt der Host nach diesem Versuch dennoch nicht mehr hoch, da ich in der /etc/fstab vergessen hatte, den Parameter nobootwait für den Eintrag der USB-Festplatte zu setzen 🤦.
Damit lande ich (sehr warscheinlich) direkt in einer Rescue-Shell. Leider habe ich bislang die Console Redirection auf Kernel-Ebene nicht aktiviert, so dass ich das nicht verifizieren und in dieser auch nichts ausrichten kann.

Dieser Server wird also nicht mehr booten, bis jemand vor Ort den Stecker der USB-Platte zieht und diese damit zurücksetzt und/oder über direkten Zugriff auf den Server aus der Rescue Shell den Server startet.

Genau so sieht ein DEADLOCK aus 🙈

Was lerne ich daraus?

1. Keine USB-Geräte an einen unbeaufsichtigten Server anschließen, solange man diese nicht auch per Remote "stromlos" machen kann, z.B. mit einer per Tasmota fernsteuerbaren Steckdose. In meinem Fall wird es nun eine Nous A5T 3-fach WiFi Steckerleiste werden.
2. Kenne deine "Notfall-Werkzeuge" wie Console Redirection oder iRMC, damit du im Falle eines Falles handlungsfähig bleibst. Richte dir die Console Redirection auf Kernel-Ebene vorab ein, auch wenn du meinst, sie nie zu brauchen.
3. nobootwait ist dein Freund.
4. Die warscheinlich wichtigste Lernerfahrung: Akzeptiere, dass es in der IT immer mindestens EINEN Fall geben wird, den du vorab NICHT bedacht hast 😜