extra unused "ghost" slots appearing with DSM 6.2 running on esxi from somewhere

[katbyte]

It seems there is a number of extra slots appearing and i can't figure out where they are coming from:

the first slot is used by the 50mg partition, and the rest via PCI passthrough and all the ports on the HBAs are filled. vm config is:

 

anyone have any ideas? i assume they are from the SATA controller but i'm not sure why or how to fix it

[flyride]

Did you pick "ESXi" from the grub boot options?  If not, please do.  The 50MB partition is your loader and should be hidden if you have selected the correct boot option.

[katbyte]

yep, that's the one i've been using. just rebooted to double check:

 

Edited July 8, 2021 by katbyte

[flyride]

Not clear what's wrong without seeking a bit more information.

 

Take a look at this and see if it applies to you.

 

If that doesn't solve it, post your SataPortMap and DiskIdxMap settings.

[katbyte]

Thanks! that does appear to be what is happening, however after following the directions i'm still seeing the boot drive in DSM, but i can confirm the script ran as i didn't see /dev/synoboot* before, but i do now:

 

 

i tried to find where to locate those properties, and i think they are in the grub config? of that is true the values in there are:

 

#for testing on VM
set sata_args='SataPortMap=4'

 

and there is no DiskIdxMap.. given the other strings i've seen something is quite wrong here it seems

 

would changing SataPortMap=0 cause it to make the first SATA controller have 0 ports? or 1 make it at least just the single boot disk?

 

grub config here: https://gist.github.com/katbyte/19da277e8b3272ef31563c21261d5c86

 

Edited July 9, 2021 by katbyte

[katbyte]

for those who come after DO NOT SET SataPortMap=0 it will break everything!! haha - to fix fire up a debian VM with the boot VMDK added to it (or use an existing one), lsblk to find it, mount, edit grub.cfg so its NOT 0, save, shutdown and start DSM back up - rather happy i went virtual as its dead easy to revert my bricking DSM!

 

i set it to 1 and now i get a more reasonable allocation of disks with the first one being the boot disk:

 

 

so i'm going to guess i need to set it to 065 (no disks, 6 disk HBA, 5 disk HBA) and when i swap HBAs 0455 (none, 4, 5, 5) - but i'm still not sure if i need to set any other as i'm not skipping ports?

[flyride]

SataPortMap=065 will break your system just as well as 0.  SataPortMap=1 should work fine unless you are running out of slots with very high port density controllers.

 

Is your boot loader disk set to SATA0:0 (it should be)?

 

If you are really missing DiskIdxMap in the grub string, that is your main issue.  If you are running DS3615/17xs, set DiskIdxMap=0C, for DS918+ set DiskIdxMap=10

 

It does look like you are running DS918+ however (EDIT: definitely DS918+ as it is visible on your boot screen).  The grub configuration on DS918+ is not really ideal for multiple controller systems, most use DS3617xs for this.

Edited July 9, 2021 by flyride

[katbyte]

yes this should fix it enough as i only plan to have 14 in here for a long while, but i'm definitely interested in learning more! bootloader is at SATA0:0 so i presume i need to set DiskIdxMap. if i understand it correctly each hex pair maps the "pci device to disk number", so 0C10 means 1st controller to disk 12, 2nd to disk 17 and without adding any more values the rest start numbering at disk 1? 

 

i'll snapshot the VMDK later today and play around with it.

 

in what way is is the DS918 grub config not ideal for multiple controllers? i have 2 working fine and planning to add a 3rd when it arrived on monday - so that might not work without some changes? i went with DS918 as it seemed the newest and can support NVME if i ever decided to pursue that adventure.

[flyride]

The higher end SAS/RAID controller support is better on DS3617xs and DS3615xs (SOHO/prosumer vs. entry-level retail DS918+), and the xs models have RAIDF1 support when DS918+ does not.

 

4 hours ago, katbyte said:

0C10 means 1st controller to disk 12, 2nd to disk 17 and without adding any more values the rest start numbering at disk 1? 

 

Yes, except you can't assign any disks beyond the MaxDisks limit, they won't be accessible (by design).  Your example will deny access to disks on the 2nd controller.

 

For DS3615xs/DS3617xs, MaxDisks is 12 decimal by default, so DiskIdxMap=0C causes the first controller (virtual SATA) to map beyond the slot range (hiding the loader)

For DS918+, MaxDisks is 16 decimal by default (via Jun inline patch), so DiskIdxMap=10 causes the first controller to map beyond the slot range, hiding the loader

Edited July 9, 2021 by flyride

[Guest]

You may want to read the following post. Setting these values randomly to like 0 is not a good idea  

 

 

[katbyte]

heh so i learned @kiler129 - and that is a great link explaining how these values work! However even when i use DiskIdxMap=10 there is still a mysterious extra disk present at the start:

 

set sata_args='DiskIdxMap=10 SataPortMap=1'