☰

fdisk -l이 연결된 모든 드라이브를 표시하지 않는 이유는 무엇입니까?

tag-icon • tag-icon ubuntu fdisk sata
fdisk -l이 연결된 모든 드라이브를 표시하지 않는 이유는 무엇입니까?

다른 사람들이 시작한 수많은 스레드가 잘못된 SATA 구성을 사용했기 때문에 장치에서 시작하지 못한 것을 발견했습니다. 이것이 내 문제가 아니라는 것을 확신시켜 드리겠습니다.

저는 회사의 IT 부서에 근무하고 있는데 SSD를 지워야 합니다. 나는 dcfldd및 hdparm(HDD를 물리적으로 손상시켰음에도 불구하고)을 사용하여 나만의 Ubuntu 머신을 만들었습니다 . 내 컴퓨터에는 여러 개의 USB-SATA 카드 리더가 연결되어 있으며 삭제를 위해 연결된 드라이브를 쉽게 교체할 수 있습니다.

우리가 삭제한 모든 SSD는 처음에 SATA AHCI 구성으로 이미지화되었습니다. 터미널에서 실행하면 fdisk -l가끔 목록에 없는 SSD가 나타납니다.

드라이브 연결을 끊고 다른 SATA 카드 리더에서 시도해 보았지만 결과는 동일했습니다. SSD의 SATA 핀이 손상되거나 구부러지지 않았습니다. hdparm -I /dev/(drive)드라이브 정보를 확인하기 위해 명령을 사용하여 드라이브가 잠겨 있는지/정지되었는지/등을 확인하려고 시도했지만 명령이 실패했습니다.

인터넷 검색에서는 내가 겪고 있는 문제를 해결/수정하는 방법이나 시스템에서 인식하지 못하더라도 연결된 드라이브를 강제로 지우는 방법에 대한 결과를 얻지 못했습니다.

이 질문을 우연히 발견할 수 있는 데이터 전문가에게 다음 두 가지 요청을 하고 싶습니다.

  1. 나는 정말로 배우고 싶다왜일부 드라이브가 인식되지 않아 액세스할 수 없습니다. 드라이브 고장으로 인해 이것이 발생할 수 있는 경우 이를 확인하기 위해 취할 수 있는 조치가 있습니까?
  2. 인식할 수 없는 드라이브를 지우는 것에 대한 대안은 무엇입니까? 회사 데이터를 안전하게 삭제해야 합니다. 데이터가 손상되지 않았는지 확인할 수 있다는 것이 장점입니다.

편집하다: 누구도 혼동하지 않았으면 좋겠습니다. 나는 미국 정부 프로토콜을 따르고 다음 명령을 사용합니다.

for n in 'seq 7'; do dcfldd if=/dev/urandom of=/dev/destination bs=8b conv=notrunc; done

드라이브의 데이터를 복구할 수 없도록 만듭니다. 다시 말하지만 문제는 /dev/sdaUbuntu이고 드라이브는 /dev/sdb - /dev/sdf내가 지우고 싶은 SSD입니다. 때로는 이러한 드라이브가 나열되지 않아 해당 드라이브를 지우는 데 사용하는 명령이 해당 드라이브에 영향을 미치지 않는 경우도 있습니다. 이러한 성격의 명령을 사용하는 것은 현재 드라이브를 지우는 데 사용하는 방법을 대체하지 않습니다.

또한 이러한 드라이브를 마더보드의 SATA 케이블에 직접 연결해도 라이브 부팅 USB에서 인식되지 않습니다.

답변1

fdisk는 사용자 공간 도구이며 fdisk커널이 장치를 인식하지 못하면 아무 것도 할 수 없습니다. 디스크가 연결되면 dmesg또는 를 확인하면 journalctl다음과 유사한 내용이 표시됩니다.

kernel: scsi 3:0:0:0: Direct-Access     ATA      Samsung SSD 860  2B6Q PQ: 0 ANSI: 5
kernel: sd 3:0:0:0: Attached scsi generic sg0 type 0
kernel: ata4.00: Enabling discard_zeroes_data
kernel: sd 3:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
kernel: sd 3:0:0:0: [sda] Write Protect is off
kernel: sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00
kernel: sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
kernel:  sda: sda1
kernel: sd 3:0:0:0: [sda] Attached SCSI disk

/dev/sdXnode 및 sysfs 디렉토리 도 생성되어야 합니다 . /sys/block/sdX이 시점에서 UDev와 이를 사용하는 도구는 lsblk이를 디스크로 인식할 수 있어야 하며노력하다그것을 사용하십시오(파티션/파일 시스템 등을 확인하십시오).

다음과 같은 것을 본다면

kernel: print_req_error: I/O error, dev sda, sector 0
kernel: Buffer I/O error on dev sda, logical block 0, async page read

이는 일반적으로 디스크에 문제가 있음을 나타내는 좋은 표시입니다. 이것이 반드시 완전히 파손되었다는 의미는 아니며, 여전히 컨트롤러나 케이블에 문제가 있을 수 있으며, 그 안의 데이터를 복구할 수 없다는 의미는 아닙니다. 따라서 장치 노드( )가 없고 /dev/sdX해당 노드에서 데이터가 "삭제"되었는지 확인해야 하는 경우 100% 확실하게 하려면 디스크를 물리적으로 파괴해야 할 것입니다(그러나 잘 모르겠습니다). 올바른 정부 프로세스는 무엇입니까).

@schrodigerscatcuriosity가 제안한 대로 언제든지 디스크를 다른 시스템에 연결하거나 USB 인클로저를 사용해 볼 수 있습니다. 이렇게 하면 최소한 일부 케이블이나 마더보드 SATA 컨트롤러 문제가 해결됩니다.

관련 정보