Jump to content
XPEnology Community

TinyCore RedPill Loader (TCRP)


pocopico

Recommended Posts

With the following i have assigned and i can use 28 disks on my test VM

- loader on SATA 0:0

- 1 on SATA 0:1

- 1 on SATA 1:0

- 16 drives on HBA 0 from SCSI0:0 to SCSI0:15

- 10 on SCSI HBA 1 from SCSI1:0 to SCSI1:9.

 

    "SataPortMap": "58",
    "DiskIdxMap": "0A00",

 

 

 "synoinfo": {
    "internalportcfg": "0xffffffff",
    "maxdisks": "32"
  },

 

image.thumb.png.7db87c2af9e769ba03a686649c08638e.png

Link to comment
Share on other sites

Yes, that works.

 

The last complaint is doing that makes the USB disk mapper into the /dev/sd namespace broken and USB drives appear in the internal mapping range despite correctly configuring the synoinfo.conf bitmasks.

 

I don't think it can be fixed without the standard and proper alignment of sataportmap and maxdisks which breaks access to >9-port controllers.  Of course it would be a moot point with SupportPortMappingV2.

Edited by flyride
Link to comment
Share on other sites

1 час назад, pocopico сказал:

If you do not specify SataPortMap and DiskIdxMap at all, what does that give you ? Can you please pass the block names from within DSM with

Скрытый текст

root@test_DSM3622:~# fdisk -l |grep Disk | grep sd
Partition 2 does not start on physical sector boundary.
Partition 3 does not start on physical sector boundary.
Partition 4 does not start on physical sector boundary.
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdc: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdd: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdg: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdh: 298.1 GiB, 320072933376 bytes, 625142448 sectors
Disk /dev/sdi: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdj: 465.8 GiB, 500106780160 bytes, 976771055 sectors
Disk /dev/sdk: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdm: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdl: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdn: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdo: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdq: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdr: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sds: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdp: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sde: 298.1 GiB, 320072933376 bytes, 625142448 sectors
Disk /dev/sdu: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdt: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdv: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sdw: 465.8 GiB, 500107862016 bytes, 976773168 sectors

Скрытый текст

BOOT_IMAGE=/zImage withefi syno_hw_version=DS3622xs+ console=ttyS0,115200n8 netif_num=5 earlycon=uart8250,io,0x3f8,115200n8 mac1=00xxxxxxxxC0 sn=2xxxxxxxxxAJ HddHotplug=0 DiskIdxMap=00060e syno_hdd_detect=0 vender_format_version=2 syno_hdd_powerup_seq=0 root=/dev/md0 SataPortMap=6888

 

Скрытый текст

2 MPT Ports found

     Port Name         Chip Vendor/Type/Rev    MPT Rev  Firmware Rev  IOC
 1.  ioc0              LSI Logic SAS2008 B2      200      14000700     0
 2.  ioc1              LSI Logic SAS2116 B1      200      11000100     0

 

SAS2008's links are down, down, 3.0 G, down, 3.0 G, 3.0 G, 3.0 G, 3.0 G

 B___T___L  Type       Vendor   Product          Rev      SASAddress     PhyNum
 0   0   0  Disk       ATA      TOSHIBA MQ01ABD0 1U    4433221102000000     2
 0   1   0  Disk       ATA      TOSHIBA MQ01ABD0 1A    4433221105000000     5
 0   2   0  Disk       ATA      TOSHIBA HDWJ105  1A    4433221106000000     6
 0   3   0  Disk       ATA      ST9500423AS      SDM5  4433221107000000     7
 0   4   0  Disk       ATA      TOSHIBA HDWJ105  1A    4433221104000000     4

SAS2116's links are down, down, down, down, 3.0 G, 3.0 G, 3.0 G, 3.0 G, 3.0 G, 3.0 G, 3.0 G, 3.0 G, 3.0 G, 3.0 G, 3.0 G, 3.0 G

 B___T___L  Type       Vendor   Product          Rev      SASAddress     PhyNum
 0   0   0  Disk       ATA      TOSHIBA HDWJ105  1A    443322110d000000    13
 0   1   0  Disk       ATA      TOSHIBA HDWJ105  1A    443322110e000000    14
 0   2   0  Disk       ATA      TOSHIBA HDWJ105  1A    443322110f000000    15
 0   3   0  Disk       ATA      TOSHIBA HDWJ105  1A    443322110c000000    12
 0   4   0  Disk       ATA      TOSHIBA HDWJ105  1A    4433221108000000     8
 0   5   0  Disk       ATA      TOSHIBA HDWJ105  1A    4433221109000000     9
 0   6   0  Disk       ATA      TOSHIBA HDWJ105  1A    443322110a000000    10
 0   7   0  Disk       ATA      TOSHIBA HDWJ105  1A    443322110b000000    11
 0   8   0  Disk       ATA      TOSHIBA HDWJ105  1A    4433221104000000     4
 0   9   0  Disk       ATA      TOSHIBA HDWJ105  1A    4433221106000000     6
 0  10   0  Disk       ATA      TOSHIBA HDWJ105  1A    4433221105000000     5
 0  11   0  Disk       ATA      TOSHIBA HDWJ105  1A    4433221107000000     7

 

 

Edited by -iliya-
Link to comment
Share on other sites

15 минут назад, pocopico сказал:

    "SataPortMap": "58",
    "DiskIdxMap": "0A00",

 

 

 "synoinfo": {
    "internalportcfg": "0xffffffff",
    "maxdisks": "32

no problem to connect 16 over HDD, problem is that USB connect as internal and only after connect all (maxdisk=24) 24 sata HDD, USB connected as external.

I found that the USB disk takes the place of the internal one starting from position 21 - that is, it turns out that regardless of Maxdisk=24-26-30-32-36 USB disks ignore this parameter

Edited by -iliya-
Link to comment
Share on other sites

6 minutes ago, flyride said:

Yes, that works.

 

The last complaint is doing that makes the USB disk mapper into the /dev/sd namespace broken and USB drives appear in the internal mapping range despite correctly configuring the synoinfo.conf bitmasks.

 

I don't think it can be fixed without the standard and proper alignment of sataportmap and maxdisks which breaks access to >9-port controllers.  Of course it would be a moot point with SupportPortMappingV2.

 

As a best practice, in general, i think that you should never exceed syno design max disk counts per model (DS3622xs 36 disks), otherwise you are looking for trouble.

Link to comment
Share on other sites

5 minutes ago, -iliya- said:

no problem to connect 16 over HDD, problem is that USB connect as internal and only after connect all (maxdisk=24) 24 sata HDD, USB connected as external.

I found that the USB disk takes the place of the internal one starting from position 21 - that is, it turns out that regardless of Maxdisk=24-26-30-32-36 USB disks ignore this parameter

What was your internalportcfg and what the usbportcfg ?

Link to comment
Share on other sites

8 минут назад, pocopico сказал:

 

As a best practice, in general, i think that you should never exceed syno design max disk counts per model (DS3622xs 36 disks), otherwise you are looking for trouble.

I basically didn't plan to exceed 36 drives, I now have a task to transfer my working 3617 DSM6.2.3 to DSM7 there I have 16 drives on 9201-16i and 6 drives per MB - that is 22 in total, I thought to add 2 more SSDs to use in VMM

Link to comment
Share on other sites

1 minute ago, -iliya- said:

I basically didn't plan to exceed 36 drives, I now have a task to transfer my working 3617 DSM6.2.3 to DSM7 there I have 16 drives on 9201-16i and 6 drives per MB - that is 22 in total, I thought to add 2 more SSDs to use in VMM

 

Operationally, if you have all your HDDs in place, the USB work correctly.  Why don't you just go with that and understand USB won't map right if you insert while HDD's are down.

Link to comment
Share on other sites

5 минут назад, pocopico сказал:

What was your internalportcfg and what the usbportcfg ?

now for tests I made this configuration on 30hdd  

 

  "SataPortMap": "68",
    "DiskIdxMap": "00060e"
  },
  "synoinfo": {
    "internalportcfg": "0x3FFFFFFF",
    "esataportcfg": "0x00000000000",
    "usbportcfg": "0xFFFC0000000",
    "maxdisks": "30",

also i try to maxdisk 24 and

internal x0ffffff

usb 0x0f00000000

Link to comment
Share on other sites

1 minute ago, -iliya- said:

I basically didn't plan to exceed 36 drives, I now have a task to transfer my working 3617 DSM6.2.3 to DSM7 there I have 16 drives on 9201-16i and 6 drives per MB - that is 22 in total, I thought to add 2 more SSDs to use in VMM

 

The best resolution post of your problem i've found so far is : 

 

https://xpenology.club/fix-xpenology-problems-viewing-internal-hard-drives-esata-hard-drives/

 

 

Link to comment
Share on other sites

4 минуты назад, flyride сказал:

Operationally, if you have all your HDDs in place, the USB work correctly.  Why don't you just go with that and understand USB won't map right if you insert while HDD's are down.

Yes, I thought about it, but the problem arises when USB drives are connected and a reboot occurs - then USBs occupy internal ports and then damage to the RAID5 array can occur since 2-3-5 drives are replaced by USB drives.
My USBs are often connected all the time - so I can access them via the local network and not switch drives between computers - this is really convenient, because DSM automatically shares it over the network when a USB is connected

Link to comment
Share on other sites

4 минуты назад, pocopico сказал:

 

The best resolution post of your problem i've found so far is : 

 

https://xpenology.club/fix-xpenology-problems-viewing-internal-hard-drives-esata-hard-drives/

 

 

yes, I read this article and, by its analogy, tried to create the correct combinations of internal and usb - but for some reason USB does not want to shift correctly.
In the internalportcfg and usbportcfg in your loader, I can specify before compiling and later I see these changes in /etc/synoinfo.conf
  /etc.defaults/synoinfo.conf
I'm trying to figure out why USB doesn't move beyond port 21

Link to comment
Share on other sites

21 minutes ago, -iliya- said:

Yes, I thought about it, but the problem arises when USB drives are connected and a reboot occurs - then USBs occupy internal ports and then damage to the RAID5 array can occur since 2-3-5 drives are replaced by USB drives.
My USBs are often connected all the time - so I can access them via the local network and not switch drives between computers - this is really convenient, because DSM automatically shares it over the network when a USB is connected

 

If the maxdisks count also the USB disks then the total is exceeding your values (11 blocks * 4 = 44). And as per your internalportcfg, 30 disks will be represented as internal disks.  

 

    "internalportcfg": "0x3FFFFFFF",
    "esataportcfg": "0x00000000000",
    "usbportcfg": "0xFFFC0000000",
    

    1111 1111 1111 1100 0000 0000 0000 0000 0000 0000 0000  usbdisks = "usbportcfg": "0xFFFC0000000",
    0000 0000 0000 0011 1111 1111 1111 1111 1111 1111 1111  internal disks = "internalportcfg": "0x3FFFFFFF",

 

I would decrease the internalportcfg from 30 to 24  and leave 8 for USB and increase maxdisks to 32 which is 8 blocks of 4.

 

1111 1111 0000 0000 0000 0000 0000 0000  usbdisks = "usbportcfg": "0xFF000000"
0000 0000 1111 1111 1111 1111 1111 1111  internal disks "internalportcfg": "0xFFFFFF"

 

Edited by pocopico
  • Like 1
Link to comment
Share on other sites

2 минуты назад, pocopico сказал:

maxdisks count also the USB disks

I understand correctly that maxdisk is the total number including both sata and esata and USB?

And what values are better to set here? If on MB 6sata + 16 LSI?

"SataPortMap": "68",
    "DiskIdxMap": "00060e"

Link to comment
Share on other sites

Just now, -iliya- said:

I understand correctly that maxdisk is the total number including both sata and esata and USB?

And what values are better to set here? If on MB 6sata + 16 LSI?

"SataPortMap": "68",
    "DiskIdxMap": "00060e"

 

As already @flyride told you SataPortMap is a single digit decimal value. We cannot do anything for that. If with no SataPortMap set you can see all disks listed, then leave it like that. SataPortMap on our case, acts like a disk count limiter for an HBA. So better try without DiskIdxMap and SataPortMap first.

 

You can verify the correct setting by editing the linux line in GRUB and press F10. 

 

After DSM boots you can check the disk names with : 

 

fdisk -l |grep Disk |grep sd 

 

and figure out the proper values for your SataPortMap/DiskIdxMap.

 

For  changing the 

 

    "internalportcfg": "0x3FFFFFFF",
    "esataportcfg": "0x00000000000",
    "usbportcfg": "0xFFFC0000000",

 

you will have to recreate the loader. 

Link to comment
Share on other sites

2 minutes ago, -iliya- said:

maxdisks count also the USB disks

 

 I don't think this is correct.  AFAIK maxdisks always correspond to the internal SATA only, even when Syno has external DX517 etc.

 

5 minutes ago, -iliya- said:

And what values are better to set here? If on MB 6sata + 16 LSI?

"SataPortMap": "68",
    "DiskIdxMap": "00060e"

This is what you need if you are going to use 6 SATA + 8 LSI + 16 LSI

You then need 30 maxdisks and bitmaps to match 30 SATA disks.

 

18 minutes ago, -iliya- said:

Yes, I thought about it, but the problem arises when USB drives are connected and a reboot occurs - then USBs occupy internal ports and then damage to the RAID5 array can occur since 2-3-5 drives are replaced by USB drives.

Does this really happen?  I would think that the SATA drives are mapped first in the boot prior to USB.  Have you tested this?

 

I do understand if you have a SATA drive failure, then reboot, that a USB drive would then map into the SATA namespace, but the SATA drive already failed, so what is the problem?  Fix and reboot.

 

Also, if two or more array members are missing, there will be no RAID5 start, so no damage possible to the array.  So again, just fix and reboot.

 

I think you already have your solution to all this.

  • Like 1
Link to comment
Share on other sites

7 минут назад, flyride сказал:

Does this really happen?  I would think that the SATA drives are mapped first in the boot prior to USB.  Have you tested this?

 

I do understand if you have a SATA drive failure, then reboot, that a USB drive would then map into the SATA namespace, but the SATA drive already failed, so what is the problem?  Fix and reboot.

 

Also, if two or more array members are missing, there will be no RAID5 start, so no damage possible to the array.  So again, just fix and reboot.

 

I think you already have your solution to all this.

Yes, I checked it when I forgot to disconnect USB and restarted DMS - the array status was critical, but since the sata disks were out of ports at that moment, DSM could not mark them as bad, rebooting with USB disconnected helped and the array instantly recovered.
As a temporary solution, you can use all sata ports and boot the system without USB - you can even stick a sticker on the case, but there is a risk that when I'm on vacation, etc., and there will be a long power outage( i'm use UPS 3000VA), then starting without me will lead to problems with the array.

Link to comment
Share on other sites

12 minutes ago, pocopico said:

Perform a ./rploader.sh clean now first.

Sorry for the mistake.

this is the commands I ran that gave the error:

 

   ./rploader.sh clean now

   ./rploader.sh build broadwellnk-7.0.1-42218

 

[ There doesn't seem to be a config for DS3622xs+ platform running 7.0.1-42218 (checked /home/tc/redpill-load/config/DS3622xs+/7.0.1-42218/config.json) ]

 

error2.thumb.png.12750ae191eaf05b0dd237ca0505422a.png

Link to comment
Share on other sites

1 minute ago, techfriend63 said:

Sorry for the mistake.

this is the commands I ran that gave the error:

 

   ./rploader.sh clean now

   ./rploader.sh build broadwellnk-7.0.1-42218

 

[ There doesn't seem to be a config for DS3622xs+ platform running 7.0.1-42218 (checked /home/tc/redpill-load/config/DS3622xs+/7.0.1-42218/config.json) ]

 

error2.thumb.png.12750ae191eaf05b0dd237ca0505422a.png

 

Hi can you follow my instructions again ? I think you've got something wrong.

Link to comment
Share on other sites

4 minutes ago, -iliya- said:

Yes, I checked it when I forgot to disconnect USB and restarted DMS - the array status was critical, but since the sata disks were out of ports at that moment, DSM could not mark them as bad, rebooting with USB disconnected helped and the array instantly recovered.
As a temporary solution, you can use all sata ports and boot the system without USB - you can even stick a sticker on the case, but there is a risk that when I'm on vacation, etc., and there will be a long power outage( i'm use UPS 3000VA), then starting without me will lead to problems with the array.

 

Please be assured that array corruption will not occur because USB drives are in the slots where there used to be SATA.  Every array member has member information in a superblock metadata.  So the worst that can happen is that the array won't start.  You might not be able to fix it however until someone can get to the device to remove USB.

 

Just curious though, in the above example of reboot problem, what happens if you eject the USB's using the DSM UI?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...