Home / / Xpenology Redpill 로더 ESXi 관련 업데이트

Xpenology Redpill 로더 ESXi 관련 업데이트

2292 views 2 min , 40 sec read

반가운 소식이네요
918+ 도 SATA 방식이없어서 3615로 테스트했었고,, 그마저도 디스크 SMART에서 짤렸었는데 제대로 시도해볼만한거같습니다.
시간날 떄 도전해봐야겠네요.

새로운 릴리스 업데이트! 

이것은 현재까지 가장 큰 릴리스이며 ESXi 사용자는 특히 기뻐할 것입니다! ;)


918+(및 기타)에
대한 SATA 부팅 지원 커널이 해당 플랫폼에서 SATA DOM을 지원하는 코드가 물리적으로 부족하기 때문에 918+에 대한 SATA 부팅 지원을 추가하는 것이 거의 불가능하다고 말한 것을 기억하십니까? 글쎄, 우리는 아이디어가 있었지만 그것이 실패할 경우 누군가를 실망시키고 싶지 않았기 때문에 거의 불가능하다고 말했습니다. 그렇지 않았다.

이번 릴리스 에서는 기본적으로 지원이 부족한 플랫폼에 대한 SATA 부팅 지원을 도입합니다 . 이것은 주로 에뮬레이트된 USB 지원이 없는 하이퍼바이저를 대상으로 합니다( ESXi 참조 ). 작동 방식은 다소 미쳤습니다. SCSI 드라이버가 드라이브에 올바른 유형을 제공하도록 잠시 동안 SATA 드라이브를 USB 드라이브로 마스킹합니다(그러나 데이터 읽기에 문제를 일으킬 만큼 길지는 않음). ). 이것이 작동할 수 있는지 또는 얼마나 잘 작동하는지 확신할 수 없었습니다. 작동하는 것으로 나타났으며 안정적으로 보입니다.

그러나 이 코드의 특성으로 인해 (적어도 현재로서는) 부팅할 다른 방법이 없을 때만 사용하는 것이 좋습니다. VM으로 전달되는 물리적 USB 플래시 드라이브가 더 나은 선택이 될 것입니다. 이것은 기본 SATA DOM(예: 3615에서)에는 적용되지 않는다는 점을 명심하십시오. 이것은 USB만큼 안정적입니다. 부팅 매개변수 “synoboot_satadom”을 보면 어떤 모드가 사용되는지 쉽게 구별할 수 있습니다. 기본 DOM은 synoboot_satadom=1이고 이 에뮬레이트된 DOM은 “synoboot_satadom=2″로 활성화됩니다. 기술적으로 네이티브 SATA DOM을 지원하는 플랫폼에서 이 에뮬레이트 모드를 실제로 사용할 수 있습니다(이유가 있는 것은 아님).

자세한 내용은 다음 커밋을 참조하세요.

디스크 SMART 에뮬레이터
보고된 가장 큰 문제 중 하나는ESXi(또는 VMWare 제품)에서 풀을 생성할 수 없다는 것이었습니다. 이 버그는 GH에서도 추적되었습니다:https://github.com/RedPill-TTG/redpill-lkm/issues/14. 여러 이론이 있었고 커뮤니티가 나서서 해결 방법을 찾았습니다. 그러나 이 상태가 오랫동안 지속되지 않았기 때문에 파기 시작했습니다.

오 소년. v7에서는 디스크 처리 방식이 많이 변경되었습니다. 가장 큰 변경 사항 중 하나는 이제 풀의 시스템에서 사용하는 모든 드라이브가 SMART(및 실제로는 여러 부분)를 지원해야 한다는 것입니다. 풀을 만드는 데 해결 방법을 사용하더라도 그렇게 하지 않으면 끔찍하게 고장날 것입니다. QEmu가 모든 가상 드라이브에 대한 최소한의(그러나 기본 작동에는 충분) SMART 지원을 실제로 에뮬레이트하기 때문에 풀 생성은 Proxmox에서만 작동했습니다.

이번 릴리스 에서는 SMART를 지원하지 않는 모든 드라이브에서 SMART에 대한 완전한 에뮬레이트 지원을 구현 했습니다 . 이 모듈은 모든 것이 녹색으로 빛나고 문제가 없다고 보고합니다. 상태 탭과 자동 SMART 테스트도 문제를 일으키지 않으며 실제로 실행된 것처럼 나타납니다. 분명히 에뮬레이트된 SMART에는 진단 값이 없으며 드라이브를 외부에서 모니터링해야 합니다. SMART 에뮬레이션은 ESXi에서 유용하지 않습니다. SMART 데이터가 누락되거나 누락될 수 있는 세 가지 주요 시나리오를 식별했습니다.

  • ESXi에서 실행(SMART를 전혀 지원하지 않음)
  • SCSI 포트에 연결된 VirtIO 디스크 실행(아래 참조)
  • 실제 HBA 모드에서 작동하지 않는 RAID 카드 사용

https://github.com/RedPill-TTG/redpill-lkm/commit/d032ac48c00f78b11516f2f2112970bc51bf68be 커밋 을 통해 ESXi에 대한 완전한 지원을 공식적으로 확인할 수 있습니다. 우리는 아직 피드백을 기다리는 GH에 대한 문제를 종료하지 않았습니다.


SCSI VirtIO
..에 대한 지원이 추가 되었으며 이 릴리스에는 더 많은 디스크 업데이트가 있습니다!

Proxmox(및 QEmu, libvirt[예: unRAID에서 사용] 또는 VirtualBox와 같은 다른 모든 VirtIO 지원 하이퍼바이저)를 사용하면 드라이브를 SATA 또는 SCSI로 전달할 수 있습니다. 그들 사이에는 기술적인 차이가 있습니다. 그러나 실제로 사용하는 동안 가장 중요한 것은 최대 6개의 SATA 장치(0-5)를 추가할 수 있는 반면 SCSI는 최대 31(0-30)을 허용한다는 것입니다.

이 릴리스에는 VirtIO SCSI 드라이브에 대한 지원이 추가되었습니다. 여기에는 위에서 설명한 SMART 에뮬레이션도 포함됩니다. QEmu는 비SATA 장치에 대해 SMART를 제공하지 않기 때문입니다. SATA 장치는 궁극적으로 SCSI 프로토콜을 사용하고 프로토콜의 대부분을 공유하므로 우리는 단순히 OS가 VirtIO SCSI 드라이브를 SATA처럼 취급 하도록 설득합니다 . 이것은 정말 해킹이 아닙니다. 공식 syno 커널은 “NEXTKVMX64” 플랫폼(VDSM?)에 대해서만 동일한 작업을 수행합니다. 우리는 단순히 모든 플랫폼에서 작동하도록 해당 기능을 개조했습니다. 또한 부팅을 위해 SCSI 드라이브를 사용하고 SATA 및 SCSI 디스크를 혼합할 수도 있습니다.

핵심 기능은 커밋에서 찾을 수 있습니다. https://github.com/RedPill-TTG/redpill-lkm/commit/2ce06db3ef69b6ea28c49754c101fd0832abec04


SCSI 드라이브 모니터링 하위 시스템
이것은 개발자 전용 기능에 가깝지만 위에서 설명한 모든 기능의 핵심에 있습니다. 간단히 말해서 Linux 커널에는 이벤트를 게시하고 구독하기 위한 메커니즘이 포함되어 있습니다. 불행히도 그것은 다소 새롭고 틈새 시스템입니다. Linux 커널의 가장 오래된 부분 중 하나인 SCSI 드라이버는 알림을 지원하지 않습니다. 시스템에 연결되는 새 드라이브에 대응하기 위해 해당 기능을 추가하는 SCSI 드라이버 확장을 개발했습니다. 우리는 아마도 이러한 변경 사항의 업스트림을 추구하여 언젠가 커널에 기본적으로 포함될 수 있을 것입니다.

자세한 내용은 다음 커밋을 참조하세요.


다중 빌드 모드 및 시스템에서 숨기기
이전 버전의 모듈은 항상 개발 모드에서 빌드되었습니다. 4MB라는 엄청난 용량 외에도 디버깅 정보가 포함되어 있기 때문에 광범위한 로깅과 여러 개의 내보낸 기호도 포함되어 있습니다. 이 릴리스로OS에서 모듈을 숨기는 데상당한 진전이 있었습니다.

이제 모듈을 세 가지 모드로 빌드할 수 있습니다.

  • dev : 모든 디버그 기호가 포함되고 표준 디버그 메시지가 인쇄됩니다. 이것은 본질적으로 현재의 모드입니다. 매개변수 없이 make를 실행할 때 여전히 기본값입니다.
  • test : 모듈이 디버그 기호에서 제거되고 경고, 오류, 중요 및 BUG 메시지만 표시합니다. 이는 발생하는 문제를 포착할 수 있는 동시에 출력이 크게 감소함을 의미합니다. 이것은 테스트 설치에서 실행하는 데 권장되는 모드입니다. 그러나 버그를 보고할 때 버그로 이어지는 훨씬 더 많은 정보가 포함된 개발 빌드에서 출력을 얻는 것을 선호합니다.
  • prod : 모듈이 디버그 기호에서 완전히 제거되고 로깅이 전혀 포함되지 않으며 또한 OS에서 자신을 숨기기 위해 노력합니다. lsmod에서 볼 수 없으며 /proc/kallsyms에 해당 기호를 게시하지 않으며 로드되면 언로드할 수 없습니다. 이 상태에서 충돌이 발생하면 스택 추적은 로드된 모듈이 아닌 익명 커널 주소를 가리킵니다.

자세한 내용은 다음 커밋을 참조하세요.


올바른 컴파일러가 중요한 이유는 무엇입니까?
우리는 다른 GCC 버전을 사용하고 다른 구성으로 플레이하는 것에 대해 얼마 전에 여기에서 토론했습니다. 우리는 이제 하루 종일 우리의 피를 끓게 만든 실질적인 예를 얻었습니다. 커널 고유의 코드가 GCC 자체에서 버그를 유발했습니다. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63567

간단히 말해서 이 문제는 이전 버전의 GCC에는 없었지만 GCC >4 및 <5에 영향을 줍니다. 이는 모듈이 C99를 염두에 두고 작성되었기 때문에 심각한 문제이며 C89 이외의 모드에서 코드를 컴파일할 때 버그가 발생합니다. 글쎄, 일반적으로 GCC를 업그레이드합니다. 그러나 Linux <3.18은 GCC 5.0에서도 컴파일되지 않습니다 . 가장 최신 버전은 4.9.x 입니다.
우리가 사용한 해결 방법은 나머지 코드가 여전히 [정상] C99 모드에서 컴파일되는 C89 모드에서 컴파일된 별도의 컴파일 단위로 문제가 되는 코드 조각을 추출하는 것이었습니다.

컴파일러 버전이 깨끗한 방식으로 작성된 코드에도 큰 영향을 미칠 수 있다는 경고로 이 이야기를 남겨둡니다 . C세계에서는 그렇게 오랜 세월이 흘렀음에도 불구하고 아직도 그런 괴물들이 옷장에 있다.;)

————————————————– ————————————————– —-

다양한 소규모 변경 및 수정 사항:

RTC 스케줄링 충돌
수정 기본 RTC 지원이 없는 플랫폼(예: 918+)에서 트리거된 작업으로 인해 자동 전원 켜기 스케줄링이 수정되었을 때 RTC 프록시에서 소프트 충돌이 발생했습니다. 그것은보고되었다 https://github.com/RedPill-TTG/redpill-lkm/issues/17 및 고정 https://github.com/RedPill-TTG/redpill-lkm/commit/29637db757d8ad0240e161136db814d5bfd31c33

구형 HDD의 SATA DOM shimming 수정
일부 구형 HDD(및 일부 실제 SATA DOM)는 용량을 쿼리하는 데 사용되는 소위 CAP16 명령을 구현하지 않습니다. 용량 추정 코드의 버그로 인해 CAP16 지원이 없는 디스크에 대해 CAP10 대체가 트리거되지 않았습니다. 이제 이것은 수정되었으며 모든 드라이브의 용량이 올바르게 감지되어야 합니다.
관련 커밋: https://github.com/RedPill-TTG/redpill-lkm/commit/524690549cb7cad96de50cc350a9e13f520f53fa

execve() 디버깅 충돌 수정
Linux가 부팅할 때마다 수천 개의 바이너리를 실행한다는 사실을 알고 계셨습니까? 우리도하지 않았다. (매우 시끄럽지만 유용한) execve() 디버그 모드를 활성화하면 일부 충돌이 발생했습니다. 그것은 인수 파싱의 극단적인 경우에 관한 것이었습니다. 1992년의 Linux 코드를 기억하는 코드로 작업할 때 몇 가지 문제가 발생합니다. https://github.com/RedPill-TTG/redpill-lkm/commit/1a6665bc71f7a73b02a3c150aad746d359caf9a4 커밋을 사용하면디버거가 충돌을 일으키지 않아야 합니다. 문제가 발생하면 문제를 통해 알려주십시오.

GCC 경고가 사라졌습니다.
자백을 피하기 위해(여기와 GH에서 보고됨) 코드를 전반적으로 개선하면서 모든 GCC 경고를 수정했습니다. 주요 기능 중 하나는 모든 플랫폼에서 발생하는 validate_nets입니다. https://github.com/RedPill-TTG/redpill-lkm/commit/0a91024b5ed4e51382015d098f0c4ed04417700f

새로운 오버라이드 기호로의 전환이 완료
되었습니다. 이전 게시물에서 언급했듯이 보다 안정적이고 빠른 새 오버라이드 기호 로직이 구현되었습니다. 이제 전면적으로 사용됩니다. 기존 방식이 완전히 제거되었습니다. 이 과정에서 재정의가 완전히 실패하고 커널이 충돌할 수 있는 드문 상황도 발견했습니다. 이것도 수정되었습니다.

자세한 내용은 다음 커밋을 참조하세요.

보다 일관된 로깅
사용자의 디버깅 및 보고를 더 쉽게 하기 위해 각 shim/하위 모듈이 상태를 보고하는 방법을 통합했습니다. 이는 이러한 로그의 일반적인 정리 역할도 합니다.

자세한 내용은 다음 커밋을 참조하세요.

빌드 환경 개량

 

————————————————–

사이트 리뉴얼중입니다~

서버(Linux, ESXi), NAS(헤놀로지, ESXi 및 IT관련 정보, 기타 등등을 공유하는 커뮤니티 SVRFORUM을 새로 만들었습니다.
많은 가입(?) 부탁드립니다~
https://svrforum.com

이전글들은 모두 상단 메뉴의 Blog 글 모음에있습니다!

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

홈서버 IT 커뮤니티 SVRFORUM
Link