● 성공) 헤놀로지 부트로더 dsm7.0 redpill boot loader [GIGABYTE] B560M AORUS PRO + PCI Express 기가비트 랜카드 인텔 WGI210AT 칩셋 추가로성공
링크
첨부
등록일
2021.10.07 17:10
등록일
2021.10.07 17:10
등록일
2021.10.07 17:10
등록일
2021.10.07 17:30
등록일
2021.10.07 17:30
등록일
2021.10.07 19:19
등록일
2021.12.07 16:21
컨텐츠 정보
- 147,756 조회
- 115 댓글
- 1 추천
- 목록
본문
● 헤놀로지 부트로더 dsm7.0 redpill boot loader [GIGABYTE] B560M AORUS PRO + PCI Express 기가비트 랜카드 인텔 WGI210AT 칩셋 추가로성공
으로 관련 파일및 유틸을 저장 소장 합니다.
제가 사용중인 2021년12월7일 16시 컴파일 저장 합니다
\\RaiDrive-shimss\SFTP (1)\home\shimss\redpill\redpill\images\redpill-DS3615xs_7.0.1-42218_b1638860448.img
주) >>> ESxi 서버로 전환 성공 했습니다>> 게시판 글 참조 바랍니다.
설치 redpill bootloader : redpill-DS918+_7.0.1-42218_211003.img
기본 설정 부트 로더 기본 수정
- 메인 cmos 설정 > usb 레거시,sata 기본 으로(변경시 인식불가),cd-rom 제거 설치
- grub.cfg 주요 수정 정보 : 아래 내용중에 UEFI 부분 추가, vid pid mac1 sn 수정
(최종사용) sata 인식을 위한 DiskIdxMap=0 SataPortMap=66 SasIdxMap=0
추가 sata 정보로 설정 필요
> grub.cfg 주요 수정 정보
# UEFI
insmod efi_gop
insmod efi_uga
insmod font
if loadfont ${prefix}/unicode.pf2
then
insmod gfxterm
set gfxmode=auto
set gfxpayload=keep
terminal_output gfxterm
fi
menuentry 'RedPill DS918+ v7.0.1-42218 (USB, Verbose)' {
savedefault
set root=(hd0,msdos1)
echo Loading Linux...
linux /zImage HddHotplug=0 withefi console=ttyS0,115200n8 netif_num=2 mac1=18C04DDD1188 mac2=1CFD08731199 syno_hdd_detect=0 syno_port_thaw=1 vender_format_version=2 earlyprintksyno_hdd_powerup_seq=1 pid=0x0226 log_buf_len=32M syno_hw_version=DS918+ vid=0x1908 earlycon=uart8250,io,0x3f8,115200n8 sn=1850PDN409244 elevator=elevator root=/dev/md0 loglevel=15 DiskIdxMap=0 SataPortMap=66 SasIdxMap=0
echo Loading initramfs...
initrd /rd.gz
echo Starting kernel with USB boot..(0) setting
}=======
최종사용 ( 자신의 시스템에 맞게 변경하세요)
linux /zImage HddHotplug=0 withefi console=ttyS0,115200n8 netif_num=1 mac1=XXYYXXYYXXYY syno_hdd_detect=0 syno_port_thaw=1 vender_format_version=2 earlyprintksyno_hdd_powerup_seq=1 pid=0x0226 log_buf_len=32M syno_hw_version=DS918+ vid=0x1908 earlycon=uart8250,io,0x3f8,115200n8 sn=1850PDN409244 elevator=elevator root=/dev/md0 loglevel=15 DiskIdxMap=0 SataPortMap=66 SasIdxMap=0
-------------------------
▶ 접속 랜카드 정보
기본 기가바이트 메인보드 B560M 기가 2.5 랜으로 접속 지원이 되지 않습니다
추가 랜카드 구입 연결 정보 입니다
- PCI Express 기가비트 랜카드 인텔 WGI210AT 칩셋
자료 접속한 저의 redpill boot loader 저장 합니다
부트로더 수정 방법
1) 최신 OSFMount 구글링 다운 설치
변경전 파일 : redpill-DS918+_7.0.1-42218_211003.img
변경후 파일 :redpill-DS918+_7.0.1-42218_211003_cfg.img
저의 ran 및 vid pid sn의 정보를 상이하게 설정 기본 설치 가능하게 수정 저장 합니다
저의 ran 및 vid pid sn의 정보를 상이하게 설정 기본 설치 가능하게 수정 저장 합니다
수정부분은 첫번째 파티션 입니다
수정 저장 합니다
usb 만들기 는 USB_IMGE_TOOL.zip 또는 Rufus-3.15p.exe 로 작업 하세요
또는 Rufus 이용
작업후 usb 상태로 적용내용 확인 및 grub.cfg 간단 수정 하기
diskgenius_DGEng5421239_x64 (2).zip
usb 부팅 하고
다른 pc에서 어시스턴트 설치후 서버이름을 클릭 dsm 설치 합니다
시놀로지 어시스턴스 다운설치 (첨부)
dsm 다운받고
https://archive.synology.com/download/Os/DSM/7.0.1-42218
다른 pc에서 dsm 설치 합니다
dsm 7.0 적용 화면
패키지 소스 추가 경로가 자동으로 내오네요
문제) ipkgui 설치가 않되네요
-nano 에티터 mc 등설치를 위한 ipkg install
저장소 입니다
주의) 패키지 업데이트 중에 파일스테이션 다운해서 수동설치 필히 하세요
-기존것 구동안됩니다
https://archive.synology.com/download/Package/FileStation/1.3.1-1382
--- 잠시 사용 테스트 하고 구형pc와 교체 예 정입니다.(완료)
-- 제일 중요한 정보는 랜카드 지원여부 와 sata 구성 설정 입니다
● 컴퓨터 부품 구입 새로운 [GIGABYTE] B560M AORUS PRO 시스템 구성 과 CPU 선정/메뉴얼 참조 하세요
https://11q.kr/www/bbs/board.php?bo_table=s21&wr_id=4855
☞ https://11q.kr 에 등록된 자료 입니다. ♠ 정보찾아 공유 드리며 출처는 링크 참조 바랍니다♠
관련자료
-
링크
-
첨부등록일 2021.10.07 17:10등록일 2021.10.07 17:10등록일 2021.10.07 17:10등록일 2021.10.07 17:30등록일 2021.10.07 17:30등록일 2021.10.07 19:19등록일 2021.12.07 16:21
댓글 115
11qkr님의 댓글
https://xpenology.com/forum/topic/44285-proxmox-hba-passthrough-second-virtual-controller-not-detected/
여기서는 synoinfo.conf 수정이 필요하지 않습니다 . 이 작업을 수행하려면 다음을 포함하도록 부팅 구성을 설정해야 했습니다.
DiskIdxMap=0C0005 SataPortMap=157
하지만 이 값을 어떻게 얻었습니까?
내가 이해하지 못한 것은 "maxdisks"(synoinfo.conf에서 Jun의 로더에 의해 12로 패치됨), "SataPortMap" 및 "DiskIdxMap"이 함께 재생되는 방식이었습니다. 종종 게시물은 설명 없이 이러한 값을 올바른 값으로 나열합니다. kconfig는 종종 설명으로 표시됩니다( https://github.com/cake654326/xpenology/blob/master/synoconfigs/Kconfig.devices ). 설명은 하지만 DiskIdxMap에 심각한 오타가 있고 Xpenology synoboot 해킹을 고려하지 않습니다. 그러나 실제로는 매우 간단합니다.
maxdisks 는 UI가 스토리지 관리자에 열거되고 표시되어야 하는 디스크 수를 DSM에 알려줍니다. OS에 의한 디스크 감지와는 아무 관련이 없는 것 같습니다. 그렇기 때문에 실제 슬롯 수보다 이 숫자가 더 높으면 문제가 발생하지 않으므로 대부분의 구성은 기본적으로 12로 설정됩니다.
SataPortMap 은 초기화할 컨트롤러당 포트 수 (최대 9개, 내 예에서는 첫 번째 컨트롤러에서 1개, 두 번째에서 5개, 세 번째에서 7 개)를 DSM에 알리기 위해 읽는 숫자 목록 (문자 1개 = 항목 1개)입니다 . )
DiskIdxMap 은 컨트롤러에서 sda-sdz 개발자로 번호가 매겨진 포트를 매핑하는 방법을 DSM에 지시하는 16진수 쌍 (2개 문자 = 1개 항목) 목록입니다 . 여기서 값의 순서는 SataPortMap에서와 동일합니다. 위의 내 예에서는 다음과 같이 매핑됩니다.
0C (dec: 12)
첫 번째 컨트롤러는 13번째 위치에서 매핑을 시작합니다.
첫 번째 컨트롤러에는 SataPortMap에 1개의 포트가 있습니다.
결과: [sdm]
00 (dec: 0)
두 번째 컨트롤러는 첫 번째 위치에서 매핑을 시작합니다.
두 번째 컨트롤러에는 SataPortMap에 5개의 포트가 있습니다.
결과 : [sda] [sdb] [sdc] [sdd] [sde]
05 (dec: 5)
세 번째 컨트롤러는 여섯 번째 위치에서 매핑을 시작합니다.
세 번째 컨트롤러에는 SataPortMap에 7개의 포트가 있습니다.
결과: [sdf] [sdg] [sdh] [sdi] [sdj] [sdk] [sdl]
위와 같은 구성으로(그리고 스크린샷에서) 시스템은 베이(비어 있더라도)와 sdX 간의 직접적인 매핑을 봅니다.
# fdisk -l /dev/sd? | grep '디스크 /'
디스크 /dev/sdb: 1.8TiB, 2000398934016바이트, 3907029168 섹터
디스크 /dev/sdc: 5.5TiB, 6001175126016바이트, 11721045168 섹터
디스크 /dev/sdd: 1.8TiB, 2000398934016바이트, 3907029168 섹터
디스크 /dev/sdf: 111.8GiB, 120034123776바이트, 234441648 섹터
(sda 및 sde는 PCI 컨트롤러의 포트 1과 5가 연결되지 않아 누락되었습니다. sdf는 QEMU 컨트롤러의 첫 번째 포트입니다)
sdm이 synoboot로 "이름이 변경"되어 목록에서 누락되었습니다.
# fdisk -l /dev/synoboot | grep '디스크 /'
디스크 /dev/synoboot: 50MiB, 52428800바이트, 102400섹터
그러나 나는 두 개의 컨트롤러가 있다고 말했습니다 ... 아니면 내가 있습니까?
어디에서나 완전히 설명되지 않은 중요한 누락된 부분은 첫 번째 컨트롤러가 (항상?) DSM이 부팅되는 컨트롤러라는 것입니다. USB 장치도 SCSI 기반이기 때문에(예: SATA):
[ 5.500034] sd 13:0:0:0: [synoboot] 연결된 SCSI 이동식 디스크
이것은 그들이 sdX로도 나타날 것임을 의미합니다. 이는 이유를 정확하게 DiskIdxMap가 왜 첫 번째 컨트롤러는 13에서 시작하는 매핑 SataPortMap가 첫 번째 컨트롤러에서 단일 포트를 나열해야합니다. 이러한 구성에서 커널은 항상 12개의 최대 디스크 외부에 부팅 장치(첫 번째 컨트롤러에 있음)를 배치 하여 UI에서 보이지 않게 합니다. 그런 다음 두 번째 컨트롤러(내 경우에는 PCI 컨트롤러)가 sda에서 정상적으로 시작하여 UI 번호 지정을 정상으로 만듭니다("디스크 1"에서 시작).
image.thumb.png.a185a7e690d8279985df0f9c8e7f9644.png
이것은 SataPortMap 을 057 로 설정하여 쉽게 확인할 수 있습니다. 그러면 즉시 멋진 KP가 생성됩니다. :NS
image.thumb.png.d8c2e1a62020cadf9fc8b40b5f07a15a.png
-------------------
No synoinfo.conf modification is needed here. For this to work I had to set the boot config to include:
DiskIdxMap=0C0005 SataPortMap=157
But HOW did I get these values
What didn't make sense to me was how "maxdisks" (in synoinfo.conf, patched to 12 by Jun's loader), "SataPortMap", and "DiskIdxMap" play together. Often times posts just list these values as correct ones without explanation. The kconfig is often shown as an explanation (https://github.com/cake654326/xpenology/blob/master/synoconfigs/Kconfig.devices). While it does explain things it has a significant typo in DiskIdxMap and doesn't take Xpenology synoboot hacking into consideration. However it is actually pretty simple:
maxdisks tells DSM how many disks the UI should enumerate and show in Storage Manager, it seems to have nothing to do with disk detection by the OS. That's why most configs just default to 12 as having this number higher than the actual number of slots will not cause problems.
SataPortMap is a list of digits (one character = one entry) which are read in order to tell DSM how many ports per controller to initialize (max 9; in my example 1 port at 1st controller, 5 ports at 2nd, and 7 at 3rd)
DiskIdxMap is a list of hex pairs (two characters = one entry) which instructs DSM how to map numbered ports from controllers to sda-sdz devs. The order of values here is the same as in SataPortMap. In my example above it maps like so:
0C (dec: 12)
1st controller starts mapping from 13th position
1st controller had 1 port in SataPortMap
Result: [sdm]
00 (dec: 0)
2nd controller starts mapping from 1st position
2nd controller had 5 ports in SataPortMap
Result: [sda] [sdb] [sdc] [sdd] [sde]
05 (dec: 5)
3rd controller starts mapping from 6th position
3rd controller had 7 ports in SataPortMap
Result: [sdf] [sdg] [sdh] [sdi] [sdj] [sdk] [sdl]
With such configuration as above (and on the screenshot) the system sees a direct mapping between bays (even if empty) and sdX:
# fdisk -l /dev/sd? | grep 'Disk /'
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk /dev/sdc: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk /dev/sdd: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk /dev/sdf: 111.8 GiB, 120034123776 bytes, 234441648 sectors
(sda and sde are missing as the ports 1 and 5 of the PCI controller aren't connected; sdf is the 1st port of the QEMU controller)
sdm is missing from the list as it is "renamed" to synoboot:
# fdisk -l /dev/synoboot | grep 'Disk /'
Disk /dev/synoboot: 50 MiB, 52428800 bytes, 102400 sectors
But I said I have two controllers... or do I?
An important missing bit which doesn't seem to be explained fully anywhere is that the first controller is (always?) the one where DSM boots from. Since USB devices are also SCSI-based (like SATA):
[ 5.500034] sd 13:0:0:0: [synoboot] Attached SCSI removable disk
This means they will appear as sdX too. This is exactly why DiskIdxMap maps the first controller to start from 13th and why SataPortMap should list a single port in the first controller. In such configuration kernel will always put the boot device (residing on the 1st controller) outside of the 12 maxdisks making it invisible in the UI. Then the 2nd controller (which in my case is the PCI controller) starts normally from sda, making the UI numbering sane (starting from "Disk 1"):
image.thumb.png.a185a7e690d8279985df0f9c8e7f9644.png
This can be easily confirmed by setting SataPortMap to 057 - it will instantly cause a nice KP :D
image.thumb.png.d8c2e1a62020cadf9fc8b40b5f07a15a.png
What about eSATA & synoinfo.conf?
On top of these above "internalportcfg" / "esataportcfg" / "usbportcfg" masks are used to decide which of the sda-sdz devices are treated as internal / eSATA / USB. When something is connected to the DSM. With settings above the defaults for DS3615xs make perfect sense:
internalportcfg=0xfff -> first 12 devices (sda-sdl) should be treated as internal
esataportcfg=0xff000 -> devices 13-20 (sdm-sdt) should be treated as eSATA
usbportcfg=0x300000 -> devices 21-22 (sdu-sdv) should be treated as USB
The DS3615xs according to the data sheet has 12 bays and 2 USB ports.
Any unmapped devices or controllers will be attached with letters after the mapped boundary. So connecting a USB stick in my configuration results in sdu:
# fdisk -l /dev/sd? | grep 'Disk /'
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk /dev/sdc: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk /dev/sdd: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk /dev/sdf: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Disk /dev/sdu: 14.6 GiB, 15682240512 bytes, 30629376 sectors
...and a correctly mapped entry in the UI:
image.thumb.png.d02242e4c90f376a937036bc810c5fda.png
-------------------------------
여기서는 synoinfo.conf 수정이 필요하지 않습니다 . 이 작업을 수행하려면 다음을 포함하도록 부팅 구성을 설정해야 했습니다.
DiskIdxMap=0C0005 SataPortMap=157
하지만 이 값을 어떻게 얻었습니까?
내가 이해하지 못한 것은 "maxdisks"(synoinfo.conf에서 Jun의 로더에 의해 12로 패치됨), "SataPortMap" 및 "DiskIdxMap"이 함께 재생되는 방식이었습니다. 종종 게시물은 설명 없이 이러한 값을 올바른 값으로 나열합니다. kconfig는 종종 설명으로 표시됩니다( https://github.com/cake654326/xpenology/blob/master/synoconfigs/Kconfig.devices ). 설명은 하지만 DiskIdxMap에 심각한 오타가 있고 Xpenology synoboot 해킹을 고려하지 않습니다. 그러나 실제로는 매우 간단합니다.
maxdisks 는 UI가 스토리지 관리자에 열거되고 표시되어야 하는 디스크 수를 DSM에 알려줍니다. OS에 의한 디스크 감지와는 아무 관련이 없는 것 같습니다. 그렇기 때문에 실제 슬롯 수보다 이 숫자가 더 높으면 문제가 발생하지 않으므로 대부분의 구성은 기본적으로 12로 설정됩니다.
SataPortMap 은 초기화할 컨트롤러당 포트 수 (최대 9개, 내 예에서는 첫 번째 컨트롤러에서 1개, 두 번째에서 5개, 세 번째에서 7 개)를 DSM에 알리기 위해 읽는 숫자 목록 (문자 1개 = 항목 1개)입니다 . )
DiskIdxMap 은 컨트롤러에서 sda-sdz 개발자로 번호가 매겨진 포트를 매핑하는 방법을 DSM에 지시하는 16진수 쌍 (2개 문자 = 1개 항목) 목록입니다 . 여기서 값의 순서는 SataPortMap에서와 동일합니다. 위의 내 예에서는 다음과 같이 매핑됩니다.
0C (dec: 12)
첫 번째 컨트롤러는 13번째 위치에서 매핑을 시작합니다.
첫 번째 컨트롤러에는 SataPortMap에 1개의 포트가 있습니다.
결과: [sdm]
00 (dec: 0)
두 번째 컨트롤러는 첫 번째 위치에서 매핑을 시작합니다.
두 번째 컨트롤러에는 SataPortMap에 5개의 포트가 있습니다.
결과 : [sda] [sdb] [sdc] [sdd] [sde]
05 (dec: 5)
세 번째 컨트롤러는 여섯 번째 위치에서 매핑을 시작합니다.
세 번째 컨트롤러에는 SataPortMap에 7개의 포트가 있습니다.
결과: [sdf] [sdg] [sdh] [sdi] [sdj] [sdk] [sdl]
위와 같은 구성으로(그리고 스크린샷에서) 시스템은 베이(비어 있더라도)와 sdX 간의 직접적인 매핑을 봅니다.
# fdisk -l /dev/sd? | grep '디스크 /'
디스크 /dev/sdb: 1.8TiB, 2000398934016바이트, 3907029168 섹터
디스크 /dev/sdc: 5.5TiB, 6001175126016바이트, 11721045168 섹터
디스크 /dev/sdd: 1.8TiB, 2000398934016바이트, 3907029168 섹터
디스크 /dev/sdf: 111.8GiB, 120034123776바이트, 234441648 섹터
(sda 및 sde는 PCI 컨트롤러의 포트 1과 5가 연결되지 않아 누락되었습니다. sdf는 QEMU 컨트롤러의 첫 번째 포트입니다)
sdm이 synoboot로 "이름이 변경"되어 목록에서 누락되었습니다.
# fdisk -l /dev/synoboot | grep '디스크 /'
디스크 /dev/synoboot: 50MiB, 52428800바이트, 102400섹터
그러나 나는 두 개의 컨트롤러가 있다고 말했습니다 ... 아니면 내가 있습니까?
어디에서나 완전히 설명되지 않은 중요한 누락된 부분은 첫 번째 컨트롤러가 (항상?) DSM이 부팅되는 컨트롤러라는 것입니다. USB 장치도 SCSI 기반이기 때문에(예: SATA):
[ 5.500034] sd 13:0:0:0: [synoboot] 연결된 SCSI 이동식 디스크
이것은 그들이 sdX로도 나타날 것임을 의미합니다. 이는 이유를 정확하게 DiskIdxMap가 왜 첫 번째 컨트롤러는 13에서 시작하는 매핑 SataPortMap가 첫 번째 컨트롤러에서 단일 포트를 나열해야합니다. 이러한 구성에서 커널은 항상 12개의 최대 디스크 외부에 부팅 장치(첫 번째 컨트롤러에 있음)를 배치 하여 UI에서 보이지 않게 합니다. 그런 다음 두 번째 컨트롤러(내 경우에는 PCI 컨트롤러)가 sda에서 정상적으로 시작하여 UI 번호 지정을 정상으로 만듭니다("디스크 1"에서 시작).
image.thumb.png.a185a7e690d8279985df0f9c8e7f9644.png
이것은 SataPortMap 을 057 로 설정하여 쉽게 확인할 수 있습니다. 그러면 즉시 멋진 KP가 생성됩니다. :NS
image.thumb.png.d8c2e1a62020cadf9fc8b40b5f07a15a.png
-------------------
No synoinfo.conf modification is needed here. For this to work I had to set the boot config to include:
DiskIdxMap=0C0005 SataPortMap=157
But HOW did I get these values
What didn't make sense to me was how "maxdisks" (in synoinfo.conf, patched to 12 by Jun's loader), "SataPortMap", and "DiskIdxMap" play together. Often times posts just list these values as correct ones without explanation. The kconfig is often shown as an explanation (https://github.com/cake654326/xpenology/blob/master/synoconfigs/Kconfig.devices). While it does explain things it has a significant typo in DiskIdxMap and doesn't take Xpenology synoboot hacking into consideration. However it is actually pretty simple:
maxdisks tells DSM how many disks the UI should enumerate and show in Storage Manager, it seems to have nothing to do with disk detection by the OS. That's why most configs just default to 12 as having this number higher than the actual number of slots will not cause problems.
SataPortMap is a list of digits (one character = one entry) which are read in order to tell DSM how many ports per controller to initialize (max 9; in my example 1 port at 1st controller, 5 ports at 2nd, and 7 at 3rd)
DiskIdxMap is a list of hex pairs (two characters = one entry) which instructs DSM how to map numbered ports from controllers to sda-sdz devs. The order of values here is the same as in SataPortMap. In my example above it maps like so:
0C (dec: 12)
1st controller starts mapping from 13th position
1st controller had 1 port in SataPortMap
Result: [sdm]
00 (dec: 0)
2nd controller starts mapping from 1st position
2nd controller had 5 ports in SataPortMap
Result: [sda] [sdb] [sdc] [sdd] [sde]
05 (dec: 5)
3rd controller starts mapping from 6th position
3rd controller had 7 ports in SataPortMap
Result: [sdf] [sdg] [sdh] [sdi] [sdj] [sdk] [sdl]
With such configuration as above (and on the screenshot) the system sees a direct mapping between bays (even if empty) and sdX:
# fdisk -l /dev/sd? | grep 'Disk /'
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk /dev/sdc: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk /dev/sdd: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk /dev/sdf: 111.8 GiB, 120034123776 bytes, 234441648 sectors
(sda and sde are missing as the ports 1 and 5 of the PCI controller aren't connected; sdf is the 1st port of the QEMU controller)
sdm is missing from the list as it is "renamed" to synoboot:
# fdisk -l /dev/synoboot | grep 'Disk /'
Disk /dev/synoboot: 50 MiB, 52428800 bytes, 102400 sectors
But I said I have two controllers... or do I?
An important missing bit which doesn't seem to be explained fully anywhere is that the first controller is (always?) the one where DSM boots from. Since USB devices are also SCSI-based (like SATA):
[ 5.500034] sd 13:0:0:0: [synoboot] Attached SCSI removable disk
This means they will appear as sdX too. This is exactly why DiskIdxMap maps the first controller to start from 13th and why SataPortMap should list a single port in the first controller. In such configuration kernel will always put the boot device (residing on the 1st controller) outside of the 12 maxdisks making it invisible in the UI. Then the 2nd controller (which in my case is the PCI controller) starts normally from sda, making the UI numbering sane (starting from "Disk 1"):
image.thumb.png.a185a7e690d8279985df0f9c8e7f9644.png
This can be easily confirmed by setting SataPortMap to 057 - it will instantly cause a nice KP :D
image.thumb.png.d8c2e1a62020cadf9fc8b40b5f07a15a.png
What about eSATA & synoinfo.conf?
On top of these above "internalportcfg" / "esataportcfg" / "usbportcfg" masks are used to decide which of the sda-sdz devices are treated as internal / eSATA / USB. When something is connected to the DSM. With settings above the defaults for DS3615xs make perfect sense:
internalportcfg=0xfff -> first 12 devices (sda-sdl) should be treated as internal
esataportcfg=0xff000 -> devices 13-20 (sdm-sdt) should be treated as eSATA
usbportcfg=0x300000 -> devices 21-22 (sdu-sdv) should be treated as USB
The DS3615xs according to the data sheet has 12 bays and 2 USB ports.
Any unmapped devices or controllers will be attached with letters after the mapped boundary. So connecting a USB stick in my configuration results in sdu:
# fdisk -l /dev/sd? | grep 'Disk /'
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk /dev/sdc: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk /dev/sdd: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk /dev/sdf: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Disk /dev/sdu: 14.6 GiB, 15682240512 bytes, 30629376 sectors
...and a correctly mapped entry in the UI:
image.thumb.png.d02242e4c90f376a937036bc810c5fda.png
-------------------------------
11qkr님의 댓글의 댓글
정상적으로 컴파일 됩니다....20211207 16시 화요일 확인
######################################################################## 100.0%
[#] Extension pocopico.vmxnet3 for ds3615xs_42218 platform is already up to date
[#] Downloading remote file https://raw.githubusercontent.com/RedPill-TTG/redpill-boot-wait/master/recipes/universal.json to /opt/redpill-load/custom/extensions/_ext_new_rcp.tmp_json
######################################################################## 100.0%
[#] Extension thethorgroup.boot-wait for ds3615xs_42218 platform is already up to date
[#] Updating ds3615xs_42218 platforms extensions... [OK]
[#] Updating extensions... [OK]
[#] Verifying /opt/redpill-load/cache/ds3615xs_42218.pat file... [OK]
[#] Unpacking /opt/redpill-load/cache/ds3615xs_42218.pat file to /opt/redpill-load/build/1638860448/pat-ds3615xs_42218-unpacked... [OK]
[#] Verifying /opt/redpill-load/build/1638860448/pat-ds3615xs_42218-unpacked/zImage file... [OK]
[#] Patching /opt/redpill-load/build/1638860448/pat-ds3615xs_42218-unpacked/zImage to /opt/redpill-load/build/1638860448/zImage-patched... [OK]
[#] Verifying /opt/redpill-load/build/1638860448/pat-ds3615xs_42218-unpacked/rd.gz file... [OK]
[#] Unpacking /opt/redpill-load/build/1638860448/pat-ds3615xs_42218-unpacked/rd.gz file to /opt/redpill-load/build/1638860448/rd-ds3615xs_42218-unpacked... [OK]
[#] Apply patches to /opt/redpill-load/build/1638860448/rd-ds3615xs_42218-unpacked... [OK]
[#] Patching config files in ramdisk... [OK]
[#] Adding OS config patching... [OK]
[#] Repacking ramdisk to /opt/redpill-load/build/1638860448/rd-patched-ds3615xs_42218.gz... [OK]
[#] Bundling extensions... [#] Checking runtime for required tools... [OK]
[#] Dumping ds3615xs_42218 platform extensions to /opt/redpill-load/build/1638860448/custom-initrd/exts... [OK]
[#] Packing custom ramdisk layer to /opt/redpill-load/build/1638860448/custom.gz... [OK]
[#] Generating GRUB config... [OK]
[#] Creating loader image at /opt/redpill-load/images/redpill-DS3615xs_7.0.1-42218_b1638860448.img... [OK]
[#] Cleaning up... [OK]
######################################################################## 100.0%
[#] Extension pocopico.vmxnet3 for ds3615xs_42218 platform is already up to date
[#] Downloading remote file https://raw.githubusercontent.com/RedPill-TTG/redpill-boot-wait/master/recipes/universal.json to /opt/redpill-load/custom/extensions/_ext_new_rcp.tmp_json
######################################################################## 100.0%
[#] Extension thethorgroup.boot-wait for ds3615xs_42218 platform is already up to date
[#] Updating ds3615xs_42218 platforms extensions... [OK]
[#] Updating extensions... [OK]
[#] Verifying /opt/redpill-load/cache/ds3615xs_42218.pat file... [OK]
[#] Unpacking /opt/redpill-load/cache/ds3615xs_42218.pat file to /opt/redpill-load/build/1638860448/pat-ds3615xs_42218-unpacked... [OK]
[#] Verifying /opt/redpill-load/build/1638860448/pat-ds3615xs_42218-unpacked/zImage file... [OK]
[#] Patching /opt/redpill-load/build/1638860448/pat-ds3615xs_42218-unpacked/zImage to /opt/redpill-load/build/1638860448/zImage-patched... [OK]
[#] Verifying /opt/redpill-load/build/1638860448/pat-ds3615xs_42218-unpacked/rd.gz file... [OK]
[#] Unpacking /opt/redpill-load/build/1638860448/pat-ds3615xs_42218-unpacked/rd.gz file to /opt/redpill-load/build/1638860448/rd-ds3615xs_42218-unpacked... [OK]
[#] Apply patches to /opt/redpill-load/build/1638860448/rd-ds3615xs_42218-unpacked... [OK]
[#] Patching config files in ramdisk... [OK]
[#] Adding OS config patching... [OK]
[#] Repacking ramdisk to /opt/redpill-load/build/1638860448/rd-patched-ds3615xs_42218.gz... [OK]
[#] Bundling extensions... [#] Checking runtime for required tools... [OK]
[#] Dumping ds3615xs_42218 platform extensions to /opt/redpill-load/build/1638860448/custom-initrd/exts... [OK]
[#] Packing custom ramdisk layer to /opt/redpill-load/build/1638860448/custom.gz... [OK]
[#] Generating GRUB config... [OK]
[#] Creating loader image at /opt/redpill-load/images/redpill-DS3615xs_7.0.1-42218_b1638860448.img... [OK]
[#] Cleaning up... [OK]