레드필 부트로더 하드디스크 이식 기능 구현 중간상황.

9일전에 공유를 드렸던 내용인데요.

기존에 DSM 6.1 에서 처리 가능한 가이드 입니다. MS 윈도우를 통해야 하고 여러가지로 좀 번거러운 작업이긴 합니다.

처음엔 GRUB2 에 부트 파티션 변경방법에 대한 개념이 정립이 안되서 1주일 정도를 허비했습니다.

그 뒤에서 부터는 속도가 붙여서 잠도 줄여가며 열심히 스크립트를 만들어 봤습니다.

tcrp-mshell 이 rr 과 조금 다른 부분은

tcrp 는 이름 그대로 tinycore linux 를 사용하는 redpill 로더이기에 이 커널이 한가지 더 포함이 되어 있습니다.

rr 과 tcrp 가 사용하는 커널은  아래와 같습니다.

1. rr 커널 ( tcrp 는 friend 커널 )
2. dsm 커널 ( tcrp 도 동일 )
3. tc 커널 ( tcrp 전용 )

rr 은 rr 커널안에서 tc 커널과 friend 커널이 해야 하는 기능을 모두 포함하고 있습니다.

메뉴가 rr 커널 안에서 직접 ./menu.sh 로 시작하는것도 이런 이유 때문입니다.

이 커널들을 죽 설명드린 이유가 

결국은 이 커널파일 (커널당 2개) 을 하드에 이식을 해야 하는데요.

기존 DSM 6 Jun's 로더는 커널에 크기가 50M 에 불과 했기 때문에 맨 첫번째 하드의 맨 마지막에 남는 짜투리 공간 100M 로도 충분했습니다.

하지만, 레드필은 이렇게 여러가지 커널들을 탑재하고 있고 각 커널당 파일이 거의 100M 에 육박합니다.

1. tc 커널 ( 20M , mydata.tgz 백업 파일이 가변적 )
2. friend 커널 ( 61M 고정크기 )
3. dsm 커널 ( ds3622xs+ 7.2.1-69057 기준 82M initrd-dsm 이 가변적 [ 각 모델별 드라이버 모듈 및 addon 포함 ] )

원래 USB 스틱의 로더에는 큰 여유공간이 있는 3번째 파티션에 모두 존재하고 있습니다.

이 모든것을 하드 1개의 100M 담는것은 불가능하구요.

포기할것은 좀 덜어내고 2, 3 번만 취해서 2개의 하드를 사용합니다.

Basic 또는 JBOD 타입으로 생성된 하드 2개가 필요합니다.

스토리지풀이 생성된 각 하드의 구조는 위 2가지 타입으로 가정했을때,

시스템 파티션  8G + 2G 와 데이터 파티션 ( 나머지 전체 영역 ) 으로 구성됩니다.

여기서 짜투리 공간은 데이터 파티션 뒤쪽에 약 100M 공간만 있는줄 알았는데,

잘 보시면 시스템 파티션과 데이터 파티션 사이에 약 128M 의 여유 공간이 더 존재합니다.

Start / End 섹터가 연결되지 않고 비어 있는게 보이실겁니다.

그 사이에 확장 파티션인 sd#4 를 만들고 부트로더 파티션들이 존재해야 할 로지컬 파티션을 각각 더 생성합니다.

이 캡쳐가 부트로더 파티션 1,2,3을 쪼개서 2개의 하드에 나눈 모습입니다.

1번째 파티션에는 98M 공간을 잡아서 

위 2번의 friend 커널을 담았습니다. 

커널의 위치가 바뀌였기 때문에 별도의 grub.cfg 에 수정을 가했고,

기존의 부트로더는 (hd0,msdos1) 을 찾아서 grub이 부팅하도록 설정되어 있는 부분도

grub-install 을 이용해서 (hd0,msdos5) = /dev/sd#5 를 가리키도록 재조정합니다.

하드 스스로 grub 부팅이 가능하도록 부트로더 1번째 파티션에 해당하는 /dev/sd#5 네 Active 를 활성화 합니다.

2번째 파티션에는 큰 공간이 필요 없지만,

중요한 부분이 원본 dsm pat 파일로 부터 추출된 rd.gz 을 담고 있고 

SmallFixVersion 의 업데이트가 감지되면 Ramdisk 자동패치를 통해 자동으로 Update 처리를 돕도록 되어 있습니다.

현재는 DSM 7.2.1-69057 U0 가 U4 로 자동 업데이트가 되도록 해주는데 필요한 파일입니다.

3번째 파티션에는 

각 모델별 dsm 커널이 담기게 됩니다.

이 파일은 로더를 재빌드 할 때마다 계속 바뀌고 재생성되는 커널 파일입니다.

중간파일인 custom.gz 파일 ( rd.gz 과 드라이버를 담고 있음 ) 도 

사이즈가 만만치 않기 때문에 최종 결과물인 initrd-dsm 가 동일한 내용을 거의 유사하게 담고 있어서

배제 시킬수 있는 방법을 찾아서 최근에 friend 커널의 버전업에도 미리 반영을 시켜둔 상태입니다.

rr 의 경우는 custom.gz 과 initrd-dsm 의 사이즈가 tcrp 에 비해 너무 많은 모듈 (예로 wifi 모듈등) 을 

담고 있어서 이대로는 2장의 하드만으로도 부족상 상황입니다.

이건 wjz304 님도 잘 알고 계셔서 이와 관련된 커널 사이즈 조정을 하고 계신건지는 잘 모르겠습니다.

이렇게 만 준비해둔 상태에서 2개의 BASIC 타입 하드만으로 부트로더가 이식된 상태로 부팅이 가능합니다.

이를위해 오리지널 부트로더인 USB나 SATA DOM 부트로더는 제거해 둡니다.

그런데, Redpill 개발 그룹인 TTG 에서 새로 시도한 방법이 USB 부터로더가 아닌

Sata DOM 부트로더의 사용이 가능하도록 개발한 부분 때문에 발목이잡히게 되었습니다.

Sata 디스크들중 맨 앞에 존재하는 디스크는 무조건 부트로더로 인식하도록 되어 있습니다.

그래서, 이 부트로더를 이식한 BASIC 타입 디스크도 부트로더인 Synoboot 파티션화 시키는 부분 때문에

맨 앞의 디스크가 사라져 버리는 현상이 있습니다. (데이터가 손상된 것은 아닙니다.)

이건 lkm 쪽에 구현되어 있는 사항인데, 일종의 Fake 기술이라고 보시면 됩니다.

그래서, 더미로 맨앞에 SATA 디스크를 하나 빼서 존재시키는게 가능하다면 이렇게 해보려고 노력중입니다.

어제 lkm 을 다시 컴파일해서 개선해 볼 생각으로 소스를 좀 들여다 보았는데,

TTG 그룹에서도 이 Sata DOM Fake 기능을 처음 구현할 때 미친짓이라고 생각하며 시작한 모양입니다.

하지만, 지금은 많이 안정화 되서 쓸만해 졌다고 마지막에 평을 넣어준것 같네요.

https://github.com/PeterSuh-Q3/redpill-lkm/blob/master/shim/boot_dev/fake_sata_boot_shim.c

SATA DOM을 지원하지 않는 시스템에서 SATA 디스크를 적절한 부팅 장치로 사용하려는 미친 시도
 
   [배경]
   syno 수정된 SCSI 드라이버(sd.c)에는 소위 부팅 디스크에 대한 지원이 포함되어 있습니다. 드라이브에 대한 논리적 지정입니다.
   일반 데이터 디스크와 분리됩니다. 일반적으로 해당 지정은 드라이브 공급업체 및 모델을 기반으로 합니다. 기본 SATA
   boot shim은 해당 사실을 사용하여 해당 공급업체 모델과 일치하고 부팅 가능한 것으로 간주되도록 사용자 제공 드라이브를 수정합니다.
   마찬가지로 USB 부팅 미디어에도 유사한 메커니즘이 존재합니다. 둘 다 완전히 분리되어 있으며 완전히 다르게 작동합니다.
   USB 저장소와 SATA는 모두 SCSI 기반 시스템이지만 장치를 식별하는 방식과 모양이 다릅니다.
   프로토콜을 제외한 거의 모든 것에서 그렇습니다.
 
 
   [어떻게 작동하나요?]
   이 심은 SATA 디스크(기본 SATA 부팅 심과 유사)를 잡고 수정하는 거의 수술적인 작업을 수행합니다.
   설명자는 잠시 동안 USB 드라이브처럼 보입니다. 설명자는 다음과 같은 상태로 둘 수 없습니다.
   "sd.c" 드라이버가 디스크 유형을 결정하는 즉시 되돌려야 합니다. 그 이유는 다른
   프로세스는 실제로 드라이브를 SATA 드라이브로 읽고 조사해야 합니다(예: SATA 장치와 통신할 수 없으므로).
   USB 스틱을 사용하면 됩니다).
   조감도에서 설명자는 sd_probe()가 호출되기 직전에 수정되고 ida_pre_get()이 호출될 때 제거됩니다.
   sd_probe()에 의해 호출됩니다. ida_pre_get()은 [sd.c 코드가 변경되더라도] 호출되는 것이 거의 보장됩니다.
   내부에서 생성된 구조를 사용하려면 다른 항목에 대해 ID 할당을 수행해야 하므로 프로세스 초기에 수행됩니다.
 
 
   [여기에 용이 있어라]
   이 코드는 매우 실험적이므로 언제든지 폭발할 수 있습니다. 이전에는 우리가 아무것도 할 수 없다고 생각했습니다.
   커널 지원 부족으로 인한 SATA 부팅(현재 사용자 영역 방법이 중단됨) 이 말도 안되는 아이디어는 실제로
   작동했고 여러 플랫폼에서 많은 테스트를 거친 후에 안정적인 것 같습니다. 그러나 USB인 경우에는 사용하지 않는 것이 좋습니다.
   옵션입니다. 여기에 있는 코드에는 많은 안전 확인 및 보호 장치가 있지만 우리는 이를 방탄이라고 생각하지 않습니다.
 
 
   참고자료:
    - https://www.kernel.org/doc/html/latest/core-api/idr.html (커널에서 ID 할당)
    - syno 커널 GPL 소스의 drivers/scsi/sd.c(sd_probe() 및 syno_disk_type_get() 참조)

아직도 넘어야할 산이 많네요.

rr 의 wjz304님 제안으로 시작했지만, 지금은 정말 이 기능이 꼭 필요한가 싶은 회의도 좀 듭니다. ㅎㅎ