성공축하드립니다.

저장소도 캡쳐올려주시면 좋겠습니다. 하드를 어떻게 잡았는지 궁금합니다.
" UEFI 부분 추가" 이부분은 원래 grub.cfg에 적혀 있지않은가요? 저의 경우 원래 적혀있던데...다른것인가요?

입반 버전에서 적용이 참조 입니다

중요한것을 안물어보았군요.
sata 인식을 위한  DiskIdxMap=0004 SataPortMap=3320 SasIdxMap=0
부분을 설명해주세요. 어떻게 해서 저런 값을 적용했는지  궁금합니다.

저도 배우고 있는중 자료  찾아보고 누군가 젹용한  값입니다
1차 성공 하여 ...지금까지 문제없음
아래 댓글 링크도 확인 바랍니다

오늘 정보 찾아 정리가 된는지 확인 부탁 드립니다
https://11q.kr/www/bbs/board.php?bo_table=s11&wr_id=11217

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
-------------------------------

좋은 자료 감사드립니다.

좋은 정보 잘 배워갑니다.

감사합니다

좋은 자료 감사합니다.

감사합니다

rtl8105e랜카드 인식 되는지 확인해볼게요.

감사합니다

감사합니다.

도전 해 보겠습니다~

감사합니다!! 도전 해 보겠습니다^^

해놀로지 초보이지만 한번 도전해보겠습니다. 자료를 공유해주셔서 감사합니다.

해놀로지 초보이지만 한번 도전해보겠습니다. 자료를 공유해주셔서 감사합니다.

초보이지만 도전해보려구요. 자료에 감사 드립니다.

감사합니다. 정보 잘 활용하겠습니다.

감사합니다~ 도전해보겠습니다.

도전해 보겠습니다^^ 감사합니다

감사합니다!! 도전 해 보겠습니다^^

감사합니다!! 도전 해 보겠습니다^^

성공 축하드리고 잘 참고해서 저도 시도 해보겠습니다!

한번 테스트해보겠습니다. 감사합니다

감사합니다!! 도전

감사합니다. 저도 도전해보겠습니다.

가입인사합니다. 나스 7 설치 정보 보고 왔어요

I'm from México, thanks, testing ...

감사합나다.

감사 해요. 이것을 시도 할 것입니다

Just upgraded; first in VMWare workstation 16.2 test (DSM 7.0.1 42214) worked great; then the real VM with 8 physical disks (also VMware workstation 16.2 DSM7.0.1 42214). Works fine; thank you!

저는 중국산 헤놀로지 타오바오로 셋팅 진행했습니다.
기존에 6.2.3 버전 리셋하고  도전했는데 1차는 실패 했습니다. 오늘 내일 해서 2차로 한번 더 해야겠네요

도움 많이 되었습니다.

일단 저도 시도 해보게씃ㅂ니다.

좋은 정보 잘 배워갑니다.

좋은 정보 감사합니다~^^

도전!

감사합니다.!!

감사합니다!

감사합니다

감사합니다.

fwrerrwr

와.. 성공하셧군요.. 저도 이번 주말에 도전해봐야겠네요.. ^^

수고하셨습니다.

설치가 될까요?

설치해 보고 글 남기겠습니다.

grub 에서 막혔는데 성공을 기원해주세요!

정상적으로 컴파일 됩니다....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]

감사합니다

감사합니다~

감사합니다.

다운받아 테스트 해 보겠습니다 감사합니다.

TS140 에서 테스트 해보겠습니다. 감사합니다.

테스트 해보겠습니다. 감사합니다

좋은 자료 감사합니다.^^

좋은정보 공유 감사드립니다!!

감사합니다!!

감사합니다~~~

감사합니다!~!~

감사합니다 우선 내장 랜카드로 해보고 안되면 랜카드를 구매해야겠네요

좋은 자료 감사합니다.

THX

감사합니다~~~

좋은 자료 감사합니다.

감사합니다

Nice to see it work on v7

nice to see it work

nice to see it work

감사합니다.

오~ 좋은 자료가 많네요. 감사합니다.

감사합니다!

감사합니다

감사합니다

감사합니다

감사합니다!

감사합니다!

잘 받아가겠습니다

감사합니다. 다음버전도 부탁드립니다.

항상 좋은 정보 감사합니다~

굿굿

감사합니다~

감사합니다

gracias

gracias

감사합니다.

감사합니다.

감사합니다. 여기저기 헤매다 왔네요 ㅎㅎ

좋은 정보 잘 배워갑니다.

감사합니다~~~ ^^

감사합니ㅏㄷ!

도전정신

감사 합니다.

감사합니다.

감사합니다

3617 자료가 없나요?

감사합니다. 도전해봐야겠어요

감사합니다

굿 좋네요

hello

감사합니다.

감사합니다

감사합니다.

감사합니다.

좋네요

감사합니다

잘 사용하고 좋은글 많이 올리겠습니다

감사합니다

감사합니다~~^^

감사합니다...^^^;

감사합니다.

감사합니다

감사합니다