Search the Community

Hi. I'm having a similar issue. I've used these commands to build but when i try to upload the .pat it fails at 47% every time. I've tried various sataportmap settings and enabled hotswap without success. ./rploader.sh update now ./rploader.sh fullupgrade now ./rploader.sh serialgen DS3622xs+ ./rploader.sh identifyusb now ./rploader.sh satamap now ./rploader.sh ext broadwellnk-7.1.0-42661 add https://github.com/pocopico/redpill-load/raw/develop/redpill-virtio/rpext-index.json ./rploader.sh ext broadwellnk-7.1.0-42661 add https://github.com/pocopico/redpill-load/raw/develop/redpill-acpid/rpext-index.json ./rploader.sh build broadwellnk-7.1.0-42661

eigentlich ist das in hex https://xpenology.com/forum/topic/32867-sata-and-sas-config-commands-in-grubcfg-and-what-they-do/ config SYNO_DISK_INDEX_MAP bool "Modify Disk Name Sequence" depends on SYNO_FIXED_DISK_NAME default y help <DSM> #19604 Add boot argument DiskIdxMap to modify disk name sequence. Each two characters define the start disk index of the sata host. This argument is a hex string and is related with SataPortMap. es müsste also eigentlich so aussehen 00, 01, 02, 03, 04 -> 5 ports 05, 06, 07, 08, 09, 0A -> 6 ports 0B, 0C -> 2 ports "DiskIdxMap": "05000B" falls das noch probleme macht wäre das log vom kernel besser um zu sehen was passiert, da sieht man neben dem controller auch wieviele ports gefunden werden evtl. zählst du bei den controllern schon falsch ein B450 hat eigentlich max 6 ports und das ist die summe aus chipset unf den port die die cpu mitbringt (4 + 2) chipset: 0000:05:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset SATA Controller [1022:43c8] (rev 01) pcie karte: 0000:08:00.0 SATA controller [0106]: JMicron Technology Corp. JMB58x AHCI SATA controller [197b:0585] von CPU (ASMxxxx, gehen vermutlich verloren wenn man nvme benutzt) 0000:0a:00.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] [1022:7901] (rev 81) 0000:0a:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] [1022:7901] (rev 81) wäre dann eher 4 + 5 + 2 (wenn es nach der reihenfolge geht wie sie gefunden werden) also: "SataPortMap": "452" "DiskIdxMap": "050009"

It does - I had no unusual issues installing with ESXi. Console does cut off as you state. If you are using KVM/q35 and a single virtual disk, configure the virtual disk to SATA, and try SataPortMap=11 and DiskIdxMap=1000. Also, the disk needs to be AT LEAST 21GB for the post-installation to complete and still create a shared folder.

das kurze aus/an wird das laden des treibers sein und wenn das nicht beim v1000 build passiert dann könnte der treiber fehlen beim 3622 ist der intel treiber evtl. beim dsm default mit dabei und es geht auch ohne treiber einbinden in loader, die builds von syno haben unterschiedliche treiber mit dabei und evtl. fehlt der treiber den dein intel nic braucht, du müsstest dann den treiber als erweiterung hinzufügen, beim tc geht das recht leicht durch erkennen von hardware grundsätzlich ist bei rc/rp nicht ein großes treiber paket als default eingebunden wie es bei jun's loader der fall war, man muss treiber als extension hinzufügen und bei tc geht das leicht da aus dem internet nachgeladen werden kann bei genaueren angaben zur hardware (nic's mit pci id'd) wäre es möglich etwas über die notwendigen treiber zu sagen i211 ist der onboard nic, das wäre igb.ko und der ist bei 2422+ nicht mit dabei intel ist da nur der i40e.ko dabei (Intel 40 Gigabit X710-AM2/XL710-AM1/XL710-AM2/X710-DA2/X710-DA4/XL710-QDA1/XL710-QDA2) alles andere muss der loader beisteuern (realtek 8168 ist ootb dabei wie bei 918/920) außerdem kann man sich noch bei den max. lan ports in die nesseln setzen, imho ist da bei den neueren loadern bisher nichts passiert so das die default limits von dsm gelten und das kann bei "kleineren" units ohne pcie slot (wie 918) bedeuten das ohne anpassen der synoinfo.conf nur max. 2 ports ootb gehen (wenn man dann 1 x onboard und 4 x als karte hat werde nur 2 von 5 ootb gehen wenn die treiber geladen sind und man kann durch umstecken rausfinden ob es der onbard ist oder zwei von den vier auf der karte) - ich habe mal einen blick in die synoinfo.conf der 2422 geworfen und da steht maxlanport="8", sollte also in dem fall kein problem sein was die sata ports angeht ist es in der regel das was der chipsatz "hätte" was dann gezählt wird und die reihenfolge ergibt sich vermutlich durch die pci id's außerdem hängt sich das wohl auch der loader noch mit emulationen rein so das es schwirieger wird etwas vorauszusagen ohne zu wissen was da genau läuft, idealerweise sollte sich tinycore darum kümmern aber wenn das nicht geht muss man sich im zweifelsfall die ahci controller und ports daran ansehen (kernel log) und eingreifen (SataPortMap, DiskIdxMap)

The following map and remap options have been found using strings in the uncompressed DS3622xs+ kernel. SataPortMap= DiskIdxMap= sata_remap= ahci_remap= The SasIdxMap string, is not present in the DS3622xs+ kernel. The reference is definetely outdate since we already know that the line in bold is not true anymore and SataPortMap can have values greater than 9. config SYNO_SATA_PORT_MAP bool "Modify SATA Hosts Port Number" depends on SYNO_FIXED_DISK_NAME default y help <DSM> #18789 Reads Sata-Port-Mapping information and forces the sata hosts to initialize specified number of ports. This makes the disk name not skip some characters. Notice - Do NOT set the port number out of the range that [0-9]. It supports as most 9 ports now. For example, SataPortMap=4233 means the 1st host use 4 ports, the 2nd host use 2 ports, the 3rd and 4th host use 3 ports.

Just to complete the test, I edited the first (main) VM from q35 to i440fx, and tried to spin it up - it gave me an error, due to the pci pass thru. So I removed the pci card from its hardware profile, and added it again (no pcie checkbox) and it powered right up with disks on the HBA starting at slot #1... So good to go! I did not re-build its loader, so NO change to its user_config.json which read like this: "SataPortMap": "1", "DiskIdxMap": "00"

Given your specific configuration with i440fx hardware emulation, I think you can put anything in SataPortMap and DiskIdxMap and it won't matter. TCRP will be updated to omit SCSI HBAs from device scanning to determine these values in the future. I would not worry about testing for performance. It makes sense there would be a difference. But whether that difference is meaningful? Hardware and CPU cycles are cheap.

According to that link, q35 seems to use less cpu power vs i440fx, not sure how to test that especially for a dsm install? I can tell you that when building the loader under the i440fx system, when running the ./rploader.sh satamap now command, it detected only the hba (albeit with no drives) and wanted to default to 0 connected drives, I choose 8 and enter. the resulting user_config.json entry looked like this "SataPortMap": "8", "DiskIdxMap": "00" And on powerup, dsm just loaded right up... of course it still had my previous installation still intact. Are there any tests I can run to compare performance? or any tests you would like any results from?

Since I am unable to edit the first post, I will add this here. With many thanks to user @flyride who graciously looked into an issue I was having, using an LSI HBA card in pci pass thru mode for my HDDs, but aways populating the DSM system in lower slots (for me it was slot #9 or slot #2 depending on the sataportmap), he discovered that by choosing system i440fx instead of Q35 fixed this issue. His thread is located here: As I mention in that post, I am not sure what advantages or disadvantages choosing i440fx vs Q35 have? But if you experience slot population issues, use i440fx as the system type and not Q35. The rest of the procedure remains the same.

I've been trying to sort out oddities reported in the TinyCore RedPill thread, and have completed some fairly exhaustive testing with the DS3622xs+ platform using ProxMox VE 7.2 (although I expect that these results would be consistent across all distributions of KVM code). Complaint: cannot get rid of a blank disk slot in Storage Manager while using LSI SCSI HBA. The issue was brought up by someone using a passthrough LSI SCSI HBA exclusively with no other disk controllers. But it isn't actually an LSI or even a KVM problem. It appears that all SCSI HBA's, whether physical or virtual, ignore the SataPortMap/DiskIdxMap logic, and add in at (total ports + 1) after all SATA controllers have been processed. When this happens, a status field is added to the device host in /sys/class: config SYNO_TRANS_HOST_TO_DISK bool "Transfer scsi host number to disk name and export to sysfs" default y help <DSM> #35892 Add an interface in sysfs to show disk name transfered from scsi host. usage: cat /sys/class/scsi_host/host*/syno_diskname_trans This behavior is confirmed on baremetal and ESXi as well. Most of the time, the ports line up and there isn't any apparent issue. Because of some idiosyncrasies with KVM (to be detailed below), it was very obvious in the single SCSI controller use case described above. I expect it's true for all non-SATA controllers/HBAs regardless of type. There is probably no simple fix, but we can partially mitigate it. Discovery: KVM seems to support SATABOOT / General SATABOOT discussion SATABOOT (i.e. booting from a disk image instead of a USB image) came along because ESXi cannot boot from a virtual USB key. So it is standard and required for ESXi installs on both RedPill and Jun loaders. I was able to confirm that RedPill SATABOOT was functional with KVM VM's. This is more diagnostic than practical, again for reasons you will see below. SATABOOT must be configured on a SATA controller (SCSI HBAs do not work). When RedPill encounters its loader as the boot device on a SATA controller, it "vanishes" that sd and replaces it with synoboot devices. With Jun's loader, the sd device continued to exist and was just unlinked in /dev and replaced with equivalent synoboot devices on the fly (a.k.a. in "userland"). This required a special DiskIdxMap after the MaxDisks limit so that the physical device wasn't accessible. That also meant that any other devices that were on that SATA controller were not mapped to usable ports. With RedPill, it's technically possible to use disks attached to the same controller as the SATABOOT device, but there will be a blank slot where RedPill vanished the SATABOOT sd. Since this leads to questions among some, it is best if no other devices are present on that SATA controller unless using a platform with Device Tree slot assignment (this is attempted to be enforced by rploader satamap via DiskIdxMap). Using SATABOOT and a SCSI controller (passthrough or virtual) will result in a "slot gap" as initially described because the SATABOOT device adds to total ports even if it is vanished. Since the SCSI controller often follows a SATA controller, the gap may not be obvious. Discovery: KVM hardware model behaviors: i440fx and q35 When you create a VM in any hypervisor, you must specify a virtual hardware template. In KVM, there are just two - i440fx and q35 i440fx is late 1990's era hardware emulation, but it does support ACPI so it is technically suitable for RedPill and DSM. Device passthrough is supported, but PCIe is emulated into PCI (since the chipset only supports PCI) which has some performance overhead. An Intel ACPI compliant SATA controller with 6 ports is emulated. Additional SATA controllers cannot be added. But the default controller for all disk types is VIrtIO SCSI as it is purported to be the most performant. It can be run in "single" mode where an individual controller is reserved for every disk, or a default mode supporting up to 14 disks on the one controller. q35 is circa-2007 hardware emulation supporting ACPI and modern PCIe virtual bus. It has somewhat better passthrough device performance. It has a quirk in that the hardware model ALWAYS includes an effectively broken SATA controller connected to an IDE bridge. It is not possible to connect devices to this controller. We should be able to ignore it except that both DSM and RedPill misbehave in its presence. Even though no disks can be attached to it, if we fail to specify an active port for it with SataPortMap, DSM will kernel panic during boot. We CAN do the Jun map trick to make sure the port mapping doesn't affect the rest of our devices. The same virtual SATA and SCSI disk controllers available on i440fx are available to q35. This allows us to run up to 6 disks on the virtual SATA controller, and 14 disks on the virtual SCSI controller, plus any passthrough physical devices. If we use q35 and a SCSI controller of any kind, we will experience a slot gap, because the required broken SATA controller port reservation adds to the total ports. If we also use SATABOOT, this will 1) preclude the use of virtual SATA disks and 2) create a second port gap prior to SCSI controllers. Summary of Findings: - Any KVM-based VM can use virtual SATA or passthrough SATA controllers, and they will work with no slot gap. - An i440fx VM can be used with a standard USB image and there will be no port gap regardless of the controller type. - rploader satamap needs to be updated to handle the q35 port reservation issue and some tweaks from the postscript below. Postscript Observation: apparent disk controller processing order (EDIT: this is conjecture, unable to create test conditions yet) If SATABOOT is active, that controller is processed first on DSM boot. Therefore we need to update satamap to query for vid/pid to see if we are trying to SATABOOT. This controller MUST be first in SataPortMap/DiskIdxMap, but it might not be the lowest ordered/"first" PCIe device. Otherwise I believe that SataPortMap/DiskIdxMap processes exclusively using low to high ordered PCIe addresses.

I'd love to, but like @phone guy says - it doesn't seem to work on proxmox. When i run rploader satamap, it finds the three controllers: - intel sata (no disks attached) - intel sata (redpill image attached) - sas hba (8 disks attached) I set the two intel controllers to 1 disk each which generates this: "SataPortMap": "118", "DiskIdxMap": "000102" In the past i'd use this to map the sas controller to start at 00, the second intel controller to start at disk 9 and the first controller to start at disk 10: "SataPortMap": "118", "DiskIdxMap": "090800" But the sas controller seems to totally ignore this mapping

Exactly, I have an old device with DSM 6.2.3 that is very stable and functional enough to use. Recently I'm trying to install 6.2.4 using tinycore-redpill instead of Jun's Loader and I always have problems. Could you please explain the difference between the SataportMap parameters of Jun Loader and RedPill? Maybe I have set this wrong. I am installing DSM in ESXi and put loader image at SATA 0:0 and pass-through physics SATA controller. So I set before are "SataPortMap": "19", "DiskIdxMap": "1000" to be able to hide the boot disk. But not work with RedPill. While I was still debugging continuously, I found that the recent update of tinycore-redpill removed the support of 6.2.4. So is there an easy way to get the 6.2.4 loader now, other than manually compiling it myself? Thanks.

DS3622xs+ has been tested with Intel 1st generation, and CPU generation is not restricted. DS3622xs+, DS3615xs, DS3617xs of the same DS36XX series can be mixed. However, SataportMap and HotPlug settings are closely related to the corrupted message during DSM installation. Today Pocopico has a guide on this topic. Please see the contents of this topic.

Thank you so much , after modifying SataPortMap to 1 and HddHotPlug to 1 it works so fine

Well for SataPortMap/DiskIdxMap/sata_remap/SasIdxMap, different models will have different options. e.g. 1621/2421/920 uses DTS, so syno i guess since its in their kernel tree, they will be moving that way. On older models the kernel contains these values and we are verifiying that are indeed taken into consideration. SasIdxMap, maybe is for models that supported SAS. I think these lower end models do not have SAS controllers at all. Someone can also verify by using : https://www.synology.com/en-us/compatibility?search_by=products&model=DS3622xs%2B&category=expansion_units&p=1&change_log_p=1

Users who want to stay on DSM 6.2.4 may be afraid that what works well in DSM 6 may not work in DSM 7. Jun Loader and RedPill may experience difficulties because there is a slight difference in the SataportMap setting. And, I think that this part may be a barrier because a little knowledge of Linux, which was not required in Jun loader, may be required in Redpill. However, as convenient and easily accessible tools such as Tinycore RedPill have been developed and provided, I believe this can be offset.

Ok, so I just rebuild the loader, using ./rploader.sh satamap now defauts, which were 1 and 5 (1 for first sata controller and 5 for second sata controller) which added this to user_config.json "SataPortMap": "15", "DiskIdxMap": "0001" But still HBA drives start at position #2

Ok, rebuilding loader again. Just to be thorough, first I run update now and fullupgrade now Then satamap now I left defaults in place, which were 1 for first controller and 5 for next controller tc@box:~$ ./rploader.sh satamap now Machine is VIRTUAL Hypervisor=KVM Found SCSI HBAs, We need to install the SCSI modules Downloading: scsi-5.10.3-tinycore64.tcz Connecting to repo.tinycorelinux.net (89.22.99.37:80) saving to 'scsi-5.10.3-tinycore64.tcz' scsi-5.10.3-tinycore 100% |*******************************************************************************************| 2632k 0:00:00 ETA 'scsi-5.10.3-tinycore64.tcz' saved scsi-5.10.3-tinycore64.tcz: OK Succesfully installed SCSI modules Found "00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02)" (1 drive(s) connected) How many ports should be mapped for this controller? [0-9] <1> Found "01:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2308 PCI-Express Fusion-MPT SAS-2 (rev 01)" (5 drive(s) connected) How many ports should be mapped for this controller? [0-9] <5> SataPortMap=15 DiskIdxMap=0001 Should i update the user_config.json with these values ? [Yy/Nn] y Done. Then added ext for acpi, v9fs and misc. Then ./rploader.sh build broadwellnk-7.1.0-42661 and reboot, select usb verbose from tcrp menu. and here I am back to dsm with disks on hba starting on slot #2.

Ok, things have changed since I ran the satamap command last @pocopico suggested not running satamap when using hba, so I never did. I never saw these results before, where it tells you how many controllers and asks how to map them. Here are those results (which did not work by the way) tc@box:~$ ./rploader.sh update now Checking Internet Access -> OK Checking if a newer version exists on the repo -> Version is current tc@box:~$ ./rploader.sh satamap now Machine is VIRTUAL Hypervisor=KVM Found SCSI HBAs, We need to install the SCSI modules Downloading: scsi-5.10.3-tinycore64.tcz Connecting to repo.tinycorelinux.net (89.22.99.37:80) saving to 'scsi-5.10.3-tinycore64.tcz' scsi-5.10.3-tinycore 100% |****************************************************************************************************************************| 2632k 0:00:00 ETA 'scsi-5.10.3-tinycore64.tcz' saved scsi-5.10.3-tinycore64.tcz: OK Succesfully installed SCSI modules Found "00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02)" (1 drive(s) connected) How many ports should be mapped for this controller? [0-9] <1> 0 Found "01:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2308 PCI-Express Fusion-MPT SAS-2 (rev 01)" (5 drive(s) connected) How many ports should be mapped for this controller? [0-9] <5> 8 SataPortMap=08 DiskIdxMap=0000 Should i update the user_config.json with these values ? [Yy/Nn] y Done. tc@box:~$ So I told it 0 drives on the first controller, and 8 drives on the hba lsi card which resulted in this being added to user_config.json "SataPortMap": "08", "DiskIdxMap": "0000" So I completed building the loader, launched my console and the vm, and it died in kernel panic, here is the output from the console [ 2.432607] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [ 2.432607] [ 2.433591] Kernel Offset: disabled [ 2.433591] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [ 2.433591] The only thing that changed is the satamap (08/0000)

A full output of lspci please. I think the issue is that you actually have idle SATA controllers active in your VM. You may not mean to have them, but they are present and affecting sataportmap and the slot numbering. When you run rploader.sh, does it ask you for the number of ports on controllers? How many controllers does it report? Maybe post the entire result of the ./rploader satamap now too if you don't mind. Be sure to ./rploader update now first.

What FILE did you use for the tinycore image (there are three)? Try SataPortMap=18 and DiskIdxMap 1000

1. Patform = DS3622xs+ in Proxmox VM 2. Disk controller = H200 flashed IT MODE (LSI9211 8i) 3. USB boot proxmox VM (rploader 0.7.1.5) using non EUFI tinycore-redpill.v0.4.6.img setting to usb boot after build complete 4. Sataportmap "1" diskidxmap "00" = all hdd connected to HBA start at slot #2 and slot #1 is empty. No other sata/scsi/emu hdd or sata controllers, only HBA pci pass thru I tried sataportmap "0" that doesn't work, never boots up. Panic? Not sure. sataportmap = 68 / diskidxmap = 0600 and disks start at slot 9 sataportmap = 8 / diskidxmap = 00 and disk start at slot 9 Only way to get HBA connected drives to start earlier at disk #2 is sataportmap 1 and diskidxmap 00 --- suggestions? { "extra_cmdline": { "pid": "0x0001", "vid": "0x46f4", "sn": "removed", "mac1": "removed", "mac2": "removed", "mac3": "removed", "mac4": "removed", "netif_num": "4", "SataPortMap": "1", "DiskIdxMap": "00" }, "synoinfo": { "internalportcfg": "0xffff", "maxdisks": "16", "support_bde_internal_10g": "no", "support_disk_compatibility": "no", "support_memory_compatibility": "no" }, "ramdisk_copy": {} }

I'd suggest you rebuild the loader with the latest rploader.sh script and see if you get a different result, but if you want to deconstruct it, post the current of all the following: 1. platform 2. disk controller types and all disks attached to which ports 3. SATABOOT or USB - and how that device is attached 3. sataportmap and diskidxmap

So now you should try this for 6 SATA + 8 LSI + 16 LSI: SataPortMap 68@ DiskIdxMap 00060e Maxdisks 30 internalportcfg 0x3FFFFFFF esataportcfg 0x00000000000 usbportcfg FFFC0000000

and verified again with DiskIdxMap= SataPortMap=2=F IRQ 72=2 , 73=13 , 74=22 -=> Total=37 I've tested "a" which is 0x61 which would be port number 49 and the kernel panics. So there must be a limit. Now next goal is to find it DiskIdxMap= SataPortMap=2OF IRQ 72=2 , 73=30 , 74=22 -=> Total=54