dohun0310
-
Posts
4 -
Joined
-
Last visited
Posts posted by dohun0310
-
-
2 minutes ago, ThorGroup said:
좋은 새 소식과 나쁜 소식 - 하지만 업데이트가 준비되었습니다!
SATA 부팅은 여기
최근에는 USB를 사용할 수 없는 사용자(예: ESXi 사용자)를 위해 SATA 부팅 지원을 제공하기 위해 열심히 노력했습니다. Jun의 로더가 완전히 다른 방법(v7에서는 가능하지 않음)을 사용했기 때문에 우리는 여기에서 미지의 영역에 들어섰습니다.
그 뒤에 숨겨진 아이디어는 간단합니다. 간단히 말해서 우리는 새 디스크에 대한 커널 프로브 이벤트를 가로채서 공급업체 이름과 모델 이름을 즉석에서 변경해야 했습니다. 그러나 다음과 같은 세 가지 핵심 장애물을 고려해야 하기 때문에 말처럼 쉽지 않습니다.
- SCSI 드라이버에는 연결할 후크가 없습니다.
- 변경해야 할 드라이브를 구별하는 방법은 무엇입니까?
- 모듈이 로드되기 전에 드라이브가 처리되면 어떻게 됩니까?
훅킹 불가
우리는 시간이 지남에 따라 안정적인지 확인하기 위해 해킹이 아닌 방식으로 접근하기로 결정했습니다. 우리는 Linux 드라이버 하위 시스템에 직접 연결하고 SCSI 장치 프로빙을 위한 자체 방법을 지정했습니다. 이 방법을 사용하면 USB와 같은 경쟁 조건 영역에 들어가지 않고 들어오는 드라이브를 필터링할 수 있습니다.
어떤 드라이브를 변경할 것인가?
USB 드라이브와 달리 SATA는 vid/pid 또는 이와 유사한 것을 사용하지 않습니다. 순수한 SCSI 세계(SATA는 SCSI를 기본 프로토콜로 사용)에서 장치는 유형이 있고 추가 드라이버 없이 명령에 간단히 응답할 것으로 예상됩니다(vid/pid를 쓸모 없게 만듭니다). 장치를 일치시키는 세 가지 방법이 있습니다.
- 공급업체/모델 이름 : syno가 사용하지만 고유하지 않습니다(사실 하이퍼바이저는 모든 드라이브에 대해 하드코딩된 쌍을 사용합니다(전달, 가상, USB 등)).
- 일련 번호: 위와 같이 고유하지 않습니다.
- 호스트/포트 위치: 가상화된 환경에서 부팅할 때마다 변경할 수 있지만 커널 간에 동일하다는 보장은 없습니다(즉, 우분투를 부팅하여 확인하고 DSM이 동일한 것으로 가정할 수 없음). 또한 일반적으로 아무도 드라이브가 연결된 가상 포트에 신경 쓰지 않기 때문에 사용자가 쉽게 제어할 수 없습니다.
안정적이고 사용자가 제어할 수 있는 유일한 요소는 용량입니다. SCSI 메타데이터에 포함되어 있지 않기 때문에 이를 기준으로 필터링하는 것은 간단하지 않습니다. 드라이브에 대한 명령을 실행하여 쿼리해야 합니다. 그러나 그것은 가장 안정적이고 강력한 접근 방식이며 우리는 그것을 사용했습니다. 기본적으로 1GiB보다 작거나 같은 첫 번째 드라이브를 synoboot 드라이브로 간주합니다. redpill-load에 의해 생성된 기본 이미지는 ~300MiB이므로 그 이하입니다. 이 값은 변경할 수 있습니다(아래 참조).
SCSI가 RedPill보다 빨랐다면?
우리는 벽에 부딪힐 때까지 SATA 지원을 훨씬 더 일찍 출시하게 되어 기뻤습니다. 일반적으로 테스트하는 동안 모듈이 이미 로드되고 모든 코드를 디버그한 후 드라이브를 "플러그"했습니다. 그러나 전체 부팅 프로세스는 훨씬 더 동적입니다. 우리가 수행한 시도의 약 절반에서 RedPill LKM이 로드될 수 있기 전에 SATA 드라이브가 처리되었습니다. 잘, *******.
syno가 synoboot를 할당하는 방식으로 인해 완료 후 지정을 변경하는 것은 거의 불가능합니다. 이 때문에 모듈이 용량 기준과 일치하는 경우 모든 기존 드라이브를 확인하는 시스템을 추가했습니다. 그들 중 하나라도 일치하면 연결이 끊어지고 컨트롤러의 강제 재검색이 트리거됩니다. 이것은 드라이브가 장착되지 않는 한 완벽하게 안전합니다. 이것이 이미 shimmable로 확인된 터치 디스크에만 주의를 기울이는 이유입니다. 또한 이 기능은 SCSI 드라이버에서 제공하는 공식 SCSI API를 사용하고 있으므로 앞으로 중단되지 않아야 합니다.
USB 및/또는 SATA shimming 작동 방식에 대한 기술적인 세부 사항에 대해 자세히 알아보려면 다음을 참조하십시오.
- https://github.com/RedPill-TTG/dsm-research/blob/master/quirks/synoboot.md (상위 수준 개요)
- https://github.com/RedPill-TTG/redpill-lkm/blob/master/shim/boot_dev/usb_boot_shim.c (파일 주석에는 USB 시밍에 대한 모든 세부 정보가 포함됨)
- https://github.com/RedPill-TTG/redpill-lkm/blob/master/shim/boot_dev/sata_boot_shim.c (파일 주석에는 SATA 시밍에 대한 모든 세부 정보가 포함되어 있음)
SATA 부팅에는 제한이 있습니다.
그리고 여기에 나쁜 소식이 있습니다. USB 부팅은 보편적이지만 SATA는 그렇지 않습니다. Syno 커널에는 세 가지에 대한 하드코딩된 검사가 포함되어 있습니다.
- SATA DoM 지원(컴파일 매개변수)
- SATA DoM 활성화(부팅 매개변수)
- SATA DoM 공급업체/모델 기준(컴파일 매개변수)
활성화된 매개변수를 분명히 제어할 수 있고 필요한 경우 컴파일 중에 커널에 하드코딩된 공급업체/모델을 변경할 수 있습니다(그러나 우리는 그렇지 않습니다). 그러나 SATA DoM 지원 플래그(CONFIG_SYNO_BOOT_SATA_DOM)에 대해 현실적으로 할 수 있는 일은 없습니다. 커널을 컴파일하는 동안 해당 옵션이 설정되지 않으면 SATA DoM을 지원하는 코드가 최종 커널에도 없으므로 공급업체/모델 이름을 변경해도 드라이브가 synoboot로 표시되지 않습니다. 위에서 논의한 요인으로 인해 사후에 간단히 변경할 수 없습니다.
즉, 현재 SATA DoM 지원 없이 apollolake 가 컴파일 되므로 SATA 부팅은 918+ 에서 지원되지 않습니다 .
Jun의 로더가 userland의 /dev/ 노드를 변경하는 데 사용하는 해킹 해결 방법이 있었습니다. 그러나 이 접근 방식에는 많은 문제가 있습니다(synoboot 문서에 설명됨). 더 이상 사용할 수 없습니다. 우리는 커널을 속이는 다른 방법을 모색하려고 노력할 것입니다. SATA DoM은 실제로 SATA 운명이 아니지만 아마도 다른 것일 수 있지만 불행히도 거기에는 확실한 약속이 없습니다. 여기서 가장 큰 어려움은 SCSI 드라이버에 "MY_ABC_HERE"가 흩어져 있다는 것입니다. 이것은 (특히 거기에) 실제 커널에서 실제로 컴파일된 부분을 실험하지 않고는 코드를 읽고 이해할 수 없도록 만드는 여러 다른 상수를 대체하는 데 사용되었습니다.
언급할 가치가 있는 것은 SATA DoM에는 USB처럼 "강제 재설치"를 트리거하는 방법이 없다는 것입니다. 이것은 보통 사람이 당신에 대해 걱정할 일이 아닙니다. SATA DoM 커널 매개변수(아래 참조)로 여기에 그대로 두기만 하면 "mfg"와 함께 사용할 수 없습니다. 기술적으로 부팅할 수는 있지만 syno 코드가 이러한 시나리오를 지원하지 않기 때문에 그러한 상태는 무의미합니다(그래서 우리는 syno 코드처럼 자동으로 실패하는 대신 이를 확인하고 오류를 제거하도록 추가했습니다).
SATA 부팅을 사용할 때 vid/pid가 전혀 필요하지 않으며 완전히 무시됩니다.
SATA 부팅 사용법은 간단하지만 신중하게 마이그레이션
SATA 부팅을 사용하는 것은 커널이 아닌 사람들에게 거의 투명합니다. SATA DoM 지원을 활성화하기 위한 기본 syno 옵션인 "synoboot_satadom=1" 부팅 옵션을 확인합니다. 해당 옵션이 설정되면 시밍을 USB(기본값)에서 SATA로 전환하고 전체 로직을 실행합니다.
또한 드라이브가 synoboot인지 여부를 알려주는 1GiB 기준은 사용자 지정 "dom_szmax=" 옵션을 사용하여 구성할 수 있습니다. 0부터 모든 값을 허용합니다. MiB로 지정해야 합니다(예: 기본값은 dom_szmax=1024). 이것은 <1GiB.....인 SATA 드라이브가 두 개 이상인 경우에만 필요합니다. 예, 가능성은 거의 없습니다.
이전에 Jun의 로더를 사용하고 UI에서 부팅 드라이브를 숨기기 위해 internalportcfg=/esataportcfg=/usbportcfg=/DiskIdxMap을 지정한 경우(특히 ESXi를 사용하는 동안) 이러한 옵션을 다시 평가해야 합니다 . 공식 SATA DoM을 사용하므로 디스크 숨김이 더 이상 필요하지 않으므로 DSM이 DiskIdxMap 이동을 수행하는 동안 해당 디스크를 계산하지 않기 때문입니다. 그대로 두면 첫 번째 데이터 디스크가 표시되지 않습니다.
포럼에는 이러한 가치가 무엇을 의미하고 어떻게 함께 작동하는지에 대한 훌륭한 게시물이 있습니다.
-------------------------------------------------- -------------------------------------------------- ----------------------------------------
GRUB는 부팅 옵션을 저장합니다.
이와 함께 여러 부팅 옵션을 지원하고 실제로 마지막으로 부팅된 옵션을 저장하도록 RedPill Load를 업데이트했습니다. 따라서 새 이미지를 처음 실행할 때 SATA 부팅 옵션을 선택해야 합니다. 재부팅할 때마다 GRUB은 사용자의 선택을 기억합니다. 이제 SATA DoM을 지원하는 모든 이미지에는 기본적으로 USB 또는 SATA의 두 가지 부팅 옵션이 포함됩니다. 이 단계에서 우리는 둘 다 허용하는 플랫폼(예: Proxmox)을 사용하는 경우 사용해야 하는 기본 설정이 없으며 둘 다 똑같이 안정적이어야 한다고 말할 수 있습니다.
기본적으로 충돌
RP LKM의 기본 빌드에서 "bug-on-load-error" 옵션을 활성화하기로 결정했습니다. 이는 모듈이 시스템 부팅을 허용하지 않고(및 잠재적으로 오류 13을 표시함) 수행할 수 없는 작업을 감지한 경우 즉시 커널 패닉이 발생함을 의미합니다. 이렇게 하면 모든 사람이 버그 보고 및 디버깅을 훨씬 쉽게 수행할 수 있습니다.
문서 업데이트
다음 사항에 대한 문서를 추가했습니다.
- 오류 13 (스텁, 본질적으로 이 질문이 항상 여기에 표시될 때 볼 수 있는 빠른 참조)
- syno 커널의 포트 및 디스크 (표준 SCSI 하위 시스템에 추가된 것으로 알려짐 )
- synoboot에 대한 자세한 내용
자동 커널 패치
...일부는 어디로 가는지
알 수 있습니다. 이전 업데이트에서 언급하는 것을 잊었지만 ramdisk 검사 뿐만 아니라 boot_params 신뢰 플래그 체인 도 자동으로 패치하는 방법을 찾을 수 있었습니다 . 이는 커널이 그렇게 많이 변경되지 않는 한 새 버전에 대한 반응이 상당히 빨라야 함을 의미합니다.
-------------------------------------------------- -------------------------------------------------- ----------------------------------------
이제 전통을 이어가는 모든 뛰어난 댓글에 답장을 보내드리겠습니다.
위에서 언급한 오류 13 문서를 참조하십시오. 재설치 옵션은 도움이 되지 않습니다. Jun의 로더(및 RedPill에서도)에서 "재설치" / "mfg" 옵션이 수행하는 유일한 작업은 USB를 DSM에 "이봐, 기존 OS를 무시하고 설치 프로그램으로 부팅" 신호를 보내는 다른 vid/pid 값으로 shim하는 것입니다. 뭐라고 요".
우리는 VirtIO 드라이버를 모든 곳에 로드하는 것에 대해 확신을 갖고 있지 않으며, 이를 진정으로 사용할 수 있는 시스템을 대상으로 하려고 합니다.
우리가 뭔가를 놓쳤나요? 모든 플랫폼에 VirtIO를 맹목적으로 로드하려는 이유가 있습니까?
이제 새로 구워진 SATA 부팅을 사용하여 그렇게 할 수 있습니다. 그러나 컴파일할 수 없다면 아직 로더를 사용하지 않는 것이 좋습니다. 베타 버전이 있으면 사용법이 훨씬 더 간단해질 것입니다. 지금은 자신이 하는 일을 알고 있는 개발자가 이 버전으로 게임을 할 수 있도록 하여 일반 취미 사용자가 데이터 손실을 방지할 수 있도록 하려고 합니다.
로더는 "멍청한 놈 친화적"이지는 않습니다 (그리고 그것은 가능한 데이터 손실로부터 당신을 구하기 위해 의도적으로 비슷합니다).
현재 통합 작업을 진행 중입니다. @haydibe의 도커를 RedPill 로드 리포지토리
에 삽입 SATA 부팅 기능에 대해 작업할 때 SATA 부팅이 세 리포지토리 모두에 걸쳐 변경 사항을 포함하므로 다른 복잡성 계층을 도입하고 싶지 않았습니다.
SATA 지원은 최신 릴리스에만 있습니다. 테스트하려면 새 버전을 가져오세요.
But it doesn't work on 918+, which means you can't use 7.0-41890?
-
31 minutes ago, Piteball said:
As has been noted many times over in the last posts, there's no SATA DOM support implemented yet, which means you can only boot using USB storage. It's also why you can't boot this loader on ESXi yet.
Ah, I see. Thank you.
-
Hello, I'm using xpenology, which is a 4G RAM for the Intel Celeron J1900. I'm looking at your incredible project and trying to apply it to this xpenology. But this xpenology has been installed on msata ssd with built-in dsm. At that time, both vid and pid were empty and used, but your project stopped at the grub because vid and pid were empty. Help me, please. (I've tried vid 0x46f4 and pid 0x0001, but it's the same)
-
1
-
RedPill - the new loader for 6.2.4 - Discussion
in Developer Discussion Room
Posted
I revised it like this. https://github.com/tossp/redpill-load/blob/42218-20211021/config/DS918%2B/7.0.1-42218/config.json But it fails to bring in the kernel and turns off.