Rpi-imager: Windows 10에서 작동하지 않는 고급 옵션

어떤 이미지를 쓰고 있었나요?

그리고 Pi sshd 프로세스가 실행되고 있지 않은지 실제로 확인하셨습니까?
(단, 연결할 수 없는 것에는 다른 이유가 있을 수 있습니다.)

Pi에 SD 카드를 넣는 대신 쓰기 직후에 컴퓨터에 다시 넣으면 FAT 파티션에 firstrun.sh라는 파일이 생성됩니까?

그리고 그렇지 않다면 "종료 시 미디어 꺼내기" 체크 여부에 따라 차이가 있나요?

응답해 주셔서 감사합니다!

이미지는 원본 Rasberry Pi OS(32-BIT) 출시일 2021-01-11입니다.
나는 ssh에 대해 Pi 자체를 확인했습니다. 그러나 작동하지 않는 것은 ssh 활성화 기능뿐만이 아닙니다. 옵션 메뉴에서 아무 것도 작동하지 않습니다. 다른 옵션도 시도했습니다. 확실하게 하기 위해 다른 SD 카드도 시도했습니다 ;)

방금 다른 sd 카드를 확인하고 사용했으며 이전과 똑같이 모든 작업을 수행했으며 firstrun.sh라는 파일을 만들지 않았습니다.
미디어 상자 꺼내기가 선택 취소되었습니다.

좋아요. 이 문제를 조금 더 살펴보니 이미저에 큰 SD 카드와 USB 드라이브에 문제가 있는 것 같습니다.

나는 16GB SD 카드를 시도했고 그 카드 이미저로 원하는 firstrun.sh 파일을 생성했습니다. 내가 사용한 첫 번째 SD 카드는 32GB와 128GB였습니다. 다음으로 외부 250Gb USB 드라이브를 시도했지만 성공하지 못했습니다. firstrun.sh 파일이 없습니다.
그래서 문제는 sd 카드의 크기입니까?

미디어 상자 꺼내기가 선택 취소되었습니다.

확인해보면 별 차이가 없겠죠?

드라이브가 이미징 전후에 동일한 드라이브 문자를 유지합니까?

미디어 꺼내기 상자를 선택하거나 선택을 취소해도 아무런 차이가 없습니다. 내 드라이브 문자는 그대로 유지됩니다.

지금은 매일 sd 카드에 OS를 쓰지 않기 때문에 큰 문제가 아닙니다. 하지만 이 옵션을 설정하면 기본적으로 ssh를 켜면 화면을 RPI에 연결할 필요 없이 OS를 설치할 수 있기 때문에 OS 설치 프로세스가 더 편리해집니다. ssh를 통한 원격 연결로 RPI를 완전히 설정할 수 있습니다.

내가 사용한 첫 번째 SD 카드는 32GB와 128GB였습니다. 다음으로 외부 250Gb USB 드라이브를 시도했지만 성공하지 못했습니다. firstrun.sh 파일이 없습니다.
그래서 문제는 sd 카드의 크기입니까?

64GB Samsung SD 카드와 32GB Toshiba에서 테스트되었으므로 크기 자체는 문제가 되지 않습니다.

최신 USB 드라이브는 표준 USB 대용량 저장 프로토콜 대신 UASP 프로토콜을 사용하는 경우 문제가 될 수 있습니다.
Windows가 이동식 저장소가 아니라 내부 드라이브로 취급하는 Samsung T7 SSD가 있습니다. 따라서 이미징 후 자동으로 드라이브 문자를 할당하지 않습니다. 대신 FAT 파티션에 있는 파일을 보려면 Windows 디스크 관리로 이동하여 드라이브 문자를 수동으로 할당해야 합니다.
해당 드라이브를 사용할 때 Imager는 분명히 파일을 자동으로 수정할 수 없지만 이 경우 명확한 오류 메시지를 표시합니다.

디스크에 쓰는 변경 사항이 손실되는 경우와 다릅니다.

비슷한 문제가 있습니다. "unable to write firstrun.sh" 오류가 발생합니다. 스크린샷을 포함하지만++X는 Snagit 2021과 충돌하므로 비활성화해야 했습니다. ;)

32GB SD 카드에서 오류가 발생했지만 16GB USB 스틱에서는 발생하지 않았습니다.

비슷한 문제가 있습니다. "unable to write firstrun.sh" 오류가 발생합니다.

이는 Windows에서 FAT 파티션에 드라이브 문자가 할당되었음을 나타내었지만(그렇지 않으면 "운영 체제에서 FAT32 파티션을 마운트하지 않았습니다"라는 메시지가 표시됨) 쓰기를 위해 파일을 여는 데 여전히 실패했습니다.
Windows에서 드라이브 문자를 할당하고 파일 시스템이 마운트를 완료하는 데 지연이 있을 수 있습니다.
이 경우 여러 번 재시도해야 할 수 있습니다.

오류를 수신한 후 카드를 다시 연결하거나 특별한 작업을 수행하지 않고도 탐색기에서 FAT 파티션의 파일을 볼 수 있습니까?

FAT32 파티션은 볼 수 있지만 물론 firstrun.sh 파일은 없습니다. 내 컴퓨터에서는 E: HDD에 2개의 파티션이 있으므로 묻지 마십시오. 그러나 USB 스틱의 경우 E:이기도 합니다.

FAT32 파티션은 볼 수 있지만 물론 firstrun.sh 파일은 없습니다.

확인.
이것이 더 잘 작동한다면 시도해 볼 수 있습니까?

이미저-1.7beta.zip

변경 사항 쓰기를 진행하기 전에 드라이브 문자에 config.txt가 있는지 확인하는 동안 최대 3초 동안 기다립니다.

예상대로 작동합니다. Pi 4에서 생성부터 부팅 주기까지 32GB SD 카드로 테스트했습니다.

감사 해요.

예상대로 작동합니다.

좋은 소식입니다.

@TeeSee64 베타도 해볼 수 있나요?
(당신이 다른 증상을 가지고 있기 때문에 그것이 당신의 문제에 대해 무엇이든 할 수 있는지 전혀 모릅니다).

@maxnet
네! 1.7베타 버전으로 문제가 해결된 것을 확인할 수 있습니다. 이제 firstrun.sh 파일을 작성하고 모든 옵션이 작동합니다. 128Gb SD 카드 및 250Gb USB 드라이브 모두에서 작동

고맙습니다 !!

안녕하세요 @maxnet , @CharlesGodwin과 같은 문제가 있었습니다. 또한 1.7베타를 시도했지만 불행히도 저에게는 작동하지 않습니다. 변경 사항으로 인해 오류 메시지만 변경되었습니다. 이제 "사용자 정의할 수 없습니다. 'I:\/config.txt' 파일이 존재하지 않습니다."가 표시됩니다.
문제는 FAT32 파티션이 "I:\" 대신 "J:\"에 마운트되어 있다는 것입니다.
죄송합니다. 현재 "J:\"에 마운트된 이유 또는 Imager가 "I:\"에 마운트되었다고 생각하는 이유에 대해 더 이상 분석할 수 없지만 최소한 이 정보를 공유하고 싶습니다. .

문제는 FAT32 파티션이 "I:\" 대신 "J:\"에 마운트되어 있다는 것입니다.

흠, 이전에 드라이브 문자가 릴리스되지 않고 새 드라이브 문자가 드라이브에 할당되었다는 보고가 있었던 것 같습니다.
좋아요: https://github.com/raspberrypi/rpi-imager/issues/31
그러나 그러한 문제를 재현하지 못했습니다. 그래서 원인이 무엇인지 모릅니다.
아마도 드라이브에 잠금 장치가 있는 것(일부 시스템 서비스 또는 바이러스 스캐너?)

아니면 I: 이전에 카드를 사용할 수 없었습니까?
Imager에서 드라이브를 선택할 때 어떤 드라이브 문자가 표시되었습니까?

Imager는 Windows에서 드라이브와 연결되어 있다고 알려주는 첫 번째 볼륨이 우리가 찾는 FAT 파티션이라고 가정합니다.
대신 config.txt에 대한 드라이브와 관련된 모든 볼륨을 검색하는 것과 같은 더 나은 메커니즘이 있는지 확실하지 않습니다.

명령 프롬프트에서 "diskpart"를 시작하고 "목록 볼륨"을 입력하면 I:와 J:가 모두 표시됩니까?
"select volume [볼륨 수]"로 선택하고 "detail volume"(및 "detail partition" "detail disk")이 비정상적인 것을 인쇄하는지 확인할 수도 있습니다.

아마도 드라이브에 잠금 장치가 있는 것(일부 시스템 서비스 또는 바이러스 스캐너?)

그렇게 생각하지 마세요.

Imager에서 드라이브를 선택할 때 어떤 드라이브 문자가 표시되었습니까?

이미 이미지 처리된 카드에는 "I:\,J:\로 장착됨"(번역, 독일어 버전 사용)이 표시됩니다.
또한 사용하지 않은 카드로 시도했습니다. "Mounted as J:\"가 표시됩니다(I:\는 탐색기에서도 완전하지 않습니다. 이유는 묻지 마세요...)

명령 프롬프트에서 "diskpart"를 시작하고 "목록 볼륨"을 입력하면 I:와 J:가 모두 표시됩니까?

아니요, J:\만 표시됩니다. 그러나 탐색기에서는 I:\와 J:\를 모두 표시합니다.

Imager는 Windows에서 드라이브와 연결되어 있다고 알려주는 첫 번째 볼륨이 우리가 찾는 FAT 파티션이라고 가정합니다.

그게 문제인 것 같습니다.

@maxnet 그냥 아이디어...
아마도 Windows 검색 인덱서? 가끔 내 컴퓨터에서 SD 카드를 안전하게 제거하려고 할 때 windwos 검색 인덱서가 해당 카드에서 사용 중이기 때문에 불가능합니다. 잠시 후 인덱서가 준비되고 안전한 제거가 가능합니다.

아마도 Windows 검색 인덱서?

모든 Microsoft 서비스가 드라이브 사용을 중지하고 모든 잠금/드라이브 문자를 적절하게 해제하는 방법을 알고 있기를 바라며 이미징 시작 시 파티션 테이블 지우기를 Microsoft의 diskpart 유틸리티에 아웃소싱합니다.
시스템 서비스 외에도 모든 드라이브의 "\System Volume Information"에 있는 파일을 요청하고 열어 두려는 타사 프로그램도 있습니다.
예를 들어 Symantec Endpoint Security는 이미 검사한 파일과 해당 파일의 서명에 대한 부기를 유지하는 것으로 알려져 있습니다.
그래서 제가 바이러스 스캐너를 언급한 것입니다.

@CRGer

이것이 더 잘 작동한다면 시도해 볼 수 있습니까?

이미저-20210322.zip

드라이브와 연결된 모든 마운트 포인트에서 첫 번째 마운트 포인트 대신 config.txt를 검색해야 합니다.

@maxnet 이미지 쓰기 전후에 자동 마운트된 드라이브 문자가 바뀌더라도 물리 디스크 번호는 바뀌지 않는다고 가정합니까? 이미지를 플래싱하기 전과 후에 WMI 항목을 사용하여 드라이브 문자를 연관시킬 수 있습니까? :shrug: 또는 원시 드라이브 크기를 사용할 수 있다고 생각합니다. 사용자가 동일한 원시 크기를 가진 두 개의 드라이브를 연결할 가능성이 거의 없기 때문입니다. (그리고 그것은 또한 깜박임 전후에 변경되지 않습니다)

@maxnet 이미지 쓰기 전후에 자동 마운트된 드라이브 문자가 바뀌어도 물리 디스크 번호로 가정
변하지 않을거야? 이미지를 플래싱하기 전과 후에 WMI 항목을 사용하여 드라이브 문자를 연관시킬 수 있습니까?

이미징 후 해당 물리적 ​​드라이브 번호에 속하는 볼륨 목록을 이미 가져옵니다.

그러나 CRger의 경우 두 개의 볼륨(I: 및 J:) 이 해당 물리적 ​​드라이브에 속하는 것으로 반환됩니다.
우리 코드는 이전에 첫 번째 파티션이 FAT 파티션이라고 가정했지만 그의 경우 두 번째 파티션이 유일하게 유효한 볼륨입니다.
새 코드는 config.txt에 대해 반환된 두 볼륨을 모두 스캔해야 합니다.

두더지 잡기 게임으로 끝날 수 있습니다. 다른 모든 것이 실패할 때 "어떤 드라이브입니까?" 대화 상자의 코드일 수 있습니다.

아, 제가 잘못 이해했습니다. 소음에 대해 사과드립니다! :눈짓:

이것이 더 잘 작동한다면 시도해 볼 수 있습니까?

그것을 시도하고 예상대로 작동합니다. "firstrun.sh"는 선택된 모든 구성으로 내 FAT 파티션을 생성했습니다. 수고 하셨습니다 @maxnet , 감사합니다!

Raspberry PI OS Lite를 작성하려고 하는 우분투에서 이 문제를 보고 있습니다. 파티션에 firstrun.sh를 쓰려고 시도하기 전에 부팅 파티션이 마운트될 때까지 충분히 오래 기다리지 않는 것처럼 보입니다. 우분투의 지연 시간이 더 긴 빌드가 있습니까?

또한 임의의 3초 대기 대신 오류가 발생하기 전에 60초 동안 루프의 파티션에 액세스할 수 있는지 테스트하는 것은 어떻습니까?

Raspberry PI OS Lite를 작성하려고 하는 우분투에서 이 문제를 보고 있습니다. 부팅할 때까지 충분히 오래 기다리지 않는 것처럼 보입니다.
파티션에 firstrun.sh 쓰기를 시도하기 전에 마운트할 파티션. 우분투의 지연 시간이 더 긴 빌드가 있습니까?

이것이 더 잘 작동합니까?

rpi-imager-ubuntu-20210324.zip

또한 임의의 3초 대기 대신 루프에서 파티션에 액세스할 수 있는지 테스트하는 것은 어떻습니까? 예를 들어 60
오류가 발생하기 몇 초 전에?

참고로 FAT 파티션이 Ubuntu 컴퓨터에 마운트되기까지 0.008초가 걸립니다.

Raspberry PI OS Lite를 작성하려고 하는 우분투에서 이 문제를 보고 있습니다. 부팅할 때까지 충분히 오래 기다리지 않는 것처럼 보입니다.
파티션에 firstrun.sh 쓰기를 시도하기 전에 마운트할 파티션. 우분투의 지연 시간이 더 긴 빌드가 있습니까?

BTW 이전에 Raspberry Pi 웹 사이트에서 .deb를 사용했습니까? 아니면 canonical에서 제공한 스냅을 사용했습니까?

다른 사람이 언급했듯이 문제는 스냅에서만 발생합니다. https://www.raspberrypi.org/forums/viewtopic.php?f=63&p=1842486

Windows 10에서 작동하지 않는 고급 옵션 이라는 제목의 문제에서 Ubuntu rpi-imager가 논의되는 이유는 무엇입니까?

아무도 그것을 찾을 수 없습니다

Windows 10에서 작동하지 않는 고급 옵션이라는 제목의 문제에서 Ubuntu rpi-imager가 논의되는 이유는 무엇입니까?

그것은 다른 문제보다 제목의 문제입니다.

두 경우의 문제는 동일합니다.
운영 체제는 마운트가 실제로 아직 준비되지 않았을 때 마운트가 완료되었다고 보고합니다.

이것은 일반 Linux 시스템에서 발생하지 않아야 합니다.
그러나 우리가 생성하지 않은 타사 스냅 패키지에서 발생할 수 있습니다.
음, Windows에서 이 문제를 해결하는 부작용으로 스냅 문제도 해결할 수 있습니다...

문제의 이름이 "SD 카드에 설정을 쓰지 않는 고급 옵션"으로 _가능_할 수 있다고 생각하지만 @maxnet 에 이미 잠재적인 수정 사항이 있다면 가치가 없는 것 같습니까? :약간_웃는_얼굴:

문제 이름을 "SD 카드에 설정을 쓰지 않는 고급 옵션"으로 바꿀 수 있다고 생각하지만 @maxnet
이미 잠재적인 수정 사항이 있습니까?

문제가 이미 해결된 것 같습니다.
그러나 1.6(git latest 대신)을 사용하는 다른 사람들이 새 문제를 여는 것을 방지하기 위해 지금은 이것을 열어 둡니다.

1.6.1에서 수정됨