This seems like hard-to-find information, so I thought I'd write up a quick tutorial. I'm running XPEnology as a VM under ESXi, now with a 24-bay Supermicro chassis. The Supermicro world has a lot of similar-but-different options. In particular, I'm running an E5-1225v3 Haswell CPU, with 32GB memory, on a X10SLM+-F motherboard in a 4U chassis using a BPN-SAS2-846EL1 backplane. This means all 24 drives are connected to a single LSI 9211-8i based HBA, flashed to IT mode. That should be enough Google-juice to find everything you need for a similar setup!
The various Jun loaders default to 12 drive bays (3615/3617 models), or 16 drive bays (DS918+). This presents a problem when you update, if you increase maxdisks after install--you either have to design your volumes around those numbers, so whole volumes drop off after an update before you re-apply the settings, or just deal with volumes being sliced and checking integrity afterwards.
Since my new hardware supports the 4.x kernel, I wanted to use the DS918+ loader, but update the patching so that 24 drive bays was the new default. Here's how. Or, just grab the files attached to the post.
This tutorial assumes you've messed with the synoboot.img file before. If not, a brief guide on mounting:
"Mount new" button, select synoboot.img
On first dialog, "Use entire image file"
On main settings dialog, "mount all partitions" radio button under volumes options, uncheck "read-only drive" under mount options
You should know have three new drives mounted. Exactly where will depend on your system, but if you had a C/D drive before, probably E/F/G.
The first readable drive has an EFI/grub.cfg file. This is what you usually customize for i.e. serial number.
On the second drive, should have a extra.lzma and extra2.lzma file, alongside some other things. Copy these somewhere else.
Unpacking, Modifying, Repacking
To be honest, I don't know why the patch exists in both of these files. Maybe one is applied during updates, one at normal boot time? I never looked into it.
But the patch that's being applied to the max disks count exists in these files. We'll need to unpack them first. Some of these tools exist on macOS, and likely Windows ports, but I just did this on a Linux system. Spin up a VM if you need. On a fresh system you likely won't have lzma or cpio installed, but apt-get should suggest the right packages.
Copy extra.lzma to a new, temporary folder. Run:
lzma -d extra.lzma
cpio -idv < extra
In the new ./etc/ directory, you should see:
Open up jun.patch in the text editor of your choice.
Search for maxdisks. There should be two instances--one in the patch delta up top, and one in a larger script below. Change the 16 to a 24.
Search for internalportcfg. Again, two instances. Change the 0xffff to 0xffffff for 24. This is a bitmask--more info elsewhere on the forums.
Open up synoinfo_override.conf.
Change the 16 to a 24, and 0xffff to 0xffffff
To repack, in a shell at the root of the extracted files, run:
(find . -name modprobe && find . ! -name modprobe) | cpio --owner root:root -oH newc | lzma -8 > ../extra.lzma
Not at the resulting file sits one directory up (../extra.lzma).
Repeat the same steps for extra2.lzma.
Just copy the updated extra/extra2.lzma files back where they came from, mounted under OSFMount.
While you're in there, you might need to update grub.cfg, especially if this is a new install. For the hardware mentioned at the very top of the post, with a single SAS expander providing 24 drives, where synoboot.img is a SATA disk for a VM under ESXi 6.7, I use these sata_args:
for 24-bay sas enclosure on 9211 LSI card (i.e. 24-bay supermicro)
set sata_args='DiskIdxMap=181C SataPortMap=1 SasIdxMap=0xfffffff4'
Close any explorer windows or text editors, and click dismount all in OSFMount. This image is ready to use.
If you're using ESXi and having trouble getting the image to boot, you can attach a network serial port to telnet in and see what's happening at boot time. You'll probably need to disable the ESXi firewall temporarily, or open port 23. It's super useful. Be aware that the 4.x kernel no longer supports extra hardware, so network card will have to be officially supported. (I gave the VM a real network card via hardware passthrough).