☰

USB에서 SATA로 - 부팅 시 파티션 테이블을 읽을 수 없음

tag-icon • tag-icon linux boot usb
USB에서 SATA로 - 부팅 시 파티션 테이블을 읽을 수 없음

USB로 연결된 SATA 디스크가 연결된 상태에서 시스템이 부팅되면 Linux는 분명히 디스크의 파티션을 인식하지 못합니다. 이로 인해 파티션(및 파일 시스템)이 보이지 않게 되어 파티션을 다시 검색(partprobe, blockdev --rereadpt 등)하거나 UAS 모듈을 다시 로드하거나 드라이브를 분리했다가 다시 삽입해야 합니다. 문제의 디스크가 ESP 및 루트 파일 시스템을 포함하는 부팅 장치로 사용하려는 경우에는 실현 가능하지 않습니다.

몇 가지 실험을 했습니다. 결과:

  1. 호스트가 온라인이고 UAS 모듈이 로드된 디스크를 삽입합니다. ->일하다
  2. 호스트가 온라인이고 UAS 및 usb_storage 모듈이 로드되지 않은 상태에서 디스크를 삽입하세요. ->일하다
  3. 디스크를 삽입한 후 다른 드라이브에서 시스템을 부팅합니다 ->실패하다 파티션이 감지되지 않았습니다. 안정화할 충분한 시간을 준 후 다음 사항이 관찰되었습니다. 흥미롭게도 UAS 및 usb_storage 모듈이 로드되었으며 /sys/class/block/sda가 존재했습니다.아니요그것을 나열하면 /proc/partitions도 그렇지 않습니다.
    1. 이 상태에서 UAS 모듈을 언로드했다가 다시 로드합니다 ->일하다(lsblk에 나열되고, /dev/sda{1,2}가 생성되고 모든 것이 "정상"입니다.)
    2. 또한 이 상태에서 시작하여 blockdev --rereadpt ->를 통해 파티션을 다시 검색합니다.일하다
    3. 커널 명령줄을 통해 UAS 모듈을 사전 로드하거나 사전 로드하지 않고 테스트를 반복하면 동일한 결과가 나타납니다.
  4. 디스크를 삽입한 후 동일한 디스크에서 시스템 부팅을 시도합니다 ->실패하다(시스템을 부팅할 수 없습니다. 복구 셸에 삭제되었습니다.)
    1. 셸에 넣은 후 시도해 보세요 blockdev --rereadpt->일하다
    2. 커널 명령줄을 통해 UAS 모듈을 사전 로드하거나 사전 로드하지 않고 테스트를 반복하면 동일한 결과가 나타납니다.

dmesg | grep sd테스트 사례 #3 실행의 출력(blockdev --rereadpt가 42초에 실행됨) 사례 #4의 출력은 동일합니다.

[   13.831953] sd 6:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   13.831955] sd 6:0:0:0: [sda] Sense Key : Not Ready [current] 
[   13.831956] sd 6:0:0:0: [sda] Add. Sense: Logical unit is in process of becoming ready
[   13.832435] sd 6:0:0:0: [sda] Test WP failed, assume Write Enabled
[   13.832850] sd 6:0:0:0: [sda] Asking for cache data failed
[   13.832853] sd 6:0:0:0: [sda] Assuming drive cache: write through
[   15.038494] sd 6:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   15.038497] sd 6:0:0:0: [sda] Sense Key : Not Ready [current] 
[   15.038498] sd 6:0:0:0: [sda] Add. Sense: Logical unit is in process of becoming ready
[   15.039379] sd 6:0:0:0: [sda] Attached SCSI disk
[   42.833001] sd 6:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[   42.834148] sda: detected capacity change from 0 to 1000204886016
[   42.956764]  sda: sda1 sda2

어떤 팁이 있나요? 장치가 부팅되고 준비되는 데 시간이 좀 걸리고(메시지에서 Logical unit is in process of becoming ready) 장치가 준비되지 않았거나 오류가 발생하거나 잘못된 데이터를 가져오는 경우 파티션 검색이 발생할 수 있다고 가정합니다 . 이 스캔이 언제 발생했는지, 어떤 하위 시스템으로 인해 스캔이 발생했는지는 알 수 없습니다. udev와 관련이 있나요? 다른 가능한 범인이 있습니까? 처음에는 주문형 모듈 로딩으로 인해 필요할 때 사용할 수 없게 될 수도 있다고 생각했습니다. 그래서 강제로 로드하려고 했습니다. 분명히 이것은 커널 명령줄에 모듈 이름을 나열하여 수행할 수 있었지만 아무 소용이 없었습니다.

rootwait테스트를 거쳤 rootdelay습니다. 둘 다 문제를 해결하지 못했습니다.

제가 흥미롭게 생각하는 점은 일반 USB 스틱이일하다의도한 실행 목적(ESP 및 루트 파일 시스템)을 제공합니다. 또한 BIOS는 USB로 연결된 SATA 디스크를 감지하고 UEFI 실행 파일(GRUB)을 찾아 시작하며 GRUB는 여기에서 커널을 읽고 부팅합니다.

--

문제 배경:

2.5인치 HDD를 컴퓨터에 연결하는 데 사용하는 USB-SATA 케이블이 있습니다. 이 시스템은 4개의 내부 SATA 포트가 있는 소형 홈 서버이며 모두 RAIDZ 구성원 디스크용입니다. 외부 드라이브를 부팅하고 여기에 루트 파일 시스템을 마운트할 계획입니다. 지금까지 저는 8GB USB 스틱에 ESP와 루트 파일 시스템을 설치했는데 훌륭하게 작동했습니다. USB 스틱이 가능하다는 것을 알았습니다.매우일반적인 루트 파일 시스템이 받는 작업 부하를 받는 경우 로그가 RAM으로 리디렉션되고 기본 프로세스를 제외한 모든 것이 루트 파일 시스템이 ZFS 풀에 있는 LXC 컨테이너에서 실행되고 있는 경우에도 마찬가지입니다. 곧 똥을 싸기 쉽습니다.

답변1

좀 더 조사한 끝에 이 문제에 대한 해키적인 해결책을 찾았습니다. 완벽과는 거리가 멀고 근본 원인을 해결하지는 못하지만 최소한 시스템을 부팅 가능하게 만듭니다.

해커는 스크립트를 가지고 있습니다파일 시스템 초기화sleep루트 마운트를 시도하기 전, 장치 초기화 후, 실행 전 어느 시점 에 실행됩니다 blockdev --rereadpt.

데비안 기반 시스템에서는 다음 파일을 넣으십시오 /etc/initramfs-tools/scripts/local-top/rereadpt.

#!/bin/sh
PREREQ=""

prereqs()
{
    echo "$PREREQ"
}

case $1 in
# get pre-requisites
prereqs)
    prereqs 
    exit 0
    ;;
esac

sleep 5
blockdev --rereadpt /dev/<yourdisknode>

/dev/sda사이트 환경에 단일 SCSI 디스크 또는 기타 논리가 있는 경우 유사한 이름을 사용하여 /dev/disk/by-id/...올바른 드라이브에서 재검색을 트리거할 수 있습니다.

업데이트: 이미지를 다시 빌드할 때마다 위 스크립트를 실행하고 싶지 않다면 update-initramfs(그렇지 않아야 하는데도??)생략할 수 없다시작 prereqs과 단편case

관련 정보