Leaderboard

Actualy mounting sdb2 and modifiying initrd/etc/model.conf worked! I replaced B02:D05:F0 with B02:D03:F0 for all System Disks and modifed Usb Port 1 to use D02:D01.F0 and Usb Port2 to use D02.D02.F0, but didn't touch the networks. That was a marvelous tip!

On Workstation it boots up, but gets no dhcp ip assigned... probably an issue with the windows firewall On ESXi it boots up, gets a dhcp ip assigned, but the harddisk is not found. I am able to login on Workstation and ESXi using the MAC (without : and capital letters) as password. I created a python script to identify the assigned DEV_BUS.DEV_PORT (The 0 in front of digit DEV_PORTs is for sorting purposes only and not present in the model.conf) this is the output: B00:D03:F0.01 Usb Port 5 B00:D03:F0.02 Usb Port 4 B00:D03:F2.01 Usb Port 8 B00:D03:F2.02 Usb Port 9 B00:D17:F0.00 System Disk 11 B00:D20:F0.01 Usb Port 3 B00:D20:F0.02 Usb Port 2 B00:D20:F0.03 Boot Disk 1 B00:D20:F0.04 Usb Port 1 B00:D28:F0.01 Usb Port 6 B00:D28:F0.02 Usb Port 7 B00:D28:F4.00 System Network 3 B00:D28:F5.00 System Network 4 B00:D28:F6.00 System Network 1 B00:D28:F7.00 System Network 2 B00:D31:F3.00 System I2C B02:D03:F0.00 System Disk 1, System Disk 18, System Disk 6 B02:D03:F0.01 System Disk 17, System Disk 5 B02:D03:F0.02 System Disk 16, System Disk 4 B02:D03:F0.03 System Disk 3, System Disk 15 B02:D03:F0.04 System Disk 2, System Disk 14 B02:D03:F0.05 System Disk 13 B02:D03:F0.06 System Disk 12 B02:D03:F0.08 System Disk 19 B02:D03:F0.09 System Disk 20 B02:D03:F0.10 System Disk 21 B02:D03:F0.11 System Disk 22 B02:D03:F0.12 System Disk 7 B02:D03:F0.13 System Disk 8 B02:D03:F0.14 System Disk 9 B02:D03:F0.15 System Disk 10 B255:D19:F0.00 Memory I2C 1 Some combinations exist more than once. Did you take care to make the unique on your image?

if your are also using VMware workstation it might address the devices differently you can modify the model.conf manually without regeneration from the firmware. You simply mount /dec/sdb2 while in tinycore and execute # mkdir /home/tc/initrd; cd initrd; gunzip -c /mnt/sdb2/boot/initrd.boot | cpio -id Then once you are done with the modifications you run the re_repacking command to repack and copy the files over to boot disk. If you start over the process again you will loose the additional modules but if you don’t need them then it’s not a bug problem Well I guess PCI bridge only matters in physical world where someone might connect a compatible PCI card e.g a 10G or an FC HBA etc. Now as for the network I’m running with the impression that you should also modify to match your configuration otherwise the default admin password which is taken from the first System Nework card will not work. Did you manage to install using the provided VM configuration ?

@Napalmd if you plan to utilize surveillance station, then yes you should patch that one too - I updated the script on Github accordingly:)

Even if DSM is Linux, the Synology utilities that make DSM what it is definitely not Linux standard. udev is completely customized. smartd is completely customized. The disk cache is customized. RAID5 is customized. And all the configuration that you can do through the DSM UI is through Synology's own binaries, not the Linux standard utilities. So if you want to configure a 60-drive array (or whatever) you might be able to get the Linux side of DSM to mount it, but Synology's utilities won't touch or will immediately scramble it. Not too long ago I tried to help a guy with an array recovery and the system was left in a Linux functional state where his data was all accessible, but then he decided to use DSM utilities to "fix" something and poof- all gone. Synology wants things the way they want them. They don't code their stuff to be fully interoperable with standard Linux. That's why the loaders and all the core scripts, patches etc are trying to keep DSM in a completely pristine, unadulterated state.

you can test it in a vm, esxi or virtualbox, virtual disk can be "thin" so it will not take much space to have 60 disks ohh, it does, they have modded there kernel and also have there own kernel modules they dont publish so even with the recently published kernel source from 6.2.2 (v24992) you cant build your own kernel, the way it is now we use synologys original kernel that comes with dsm and add kernel modules but if modules need support in the kernel it is not present in synologys binary (like with hyper-v or amd) then we cant do much, only a custom kernel could do this (like it was the case with 5.x) but they change parts of the kernel in there way if needed and as there stuff is part of the kernel we use you would need to read kernel source and maybe some scripts of dsm to find out how its done and would need to adapt or extend scripts to change or improve this, not sure if this is even worth the effort, there are only very few people needing support for >24 drives and with 18TB disks around you can have more the 400TB in one system the grub cfg would be just a plain file on the 1st partition of the usb, the extra.lzma containing the path is on the 2nd the patch try's to apply on boot and when already done is skipped and when doing a update and the original file (synoinfo.conf) is restored it will be reapplied, its easy to mod the patch for 918+ (like from 16 to 24) as all the code to patch is in the patch because the original unit only has 4 drives and to make it usable it needed to be extended, as the default for 3615 and 3617 is 12 drives it was newer needed to change and there is no code in the patch to mod, so you would need to make you own extended patch with manually doing it an then use diff to make a new patch that would be integrated into extra.lzma its not that difficult as we have 918+ so see how its done and would need to do the same in 3615/17 not if you have no control over the code, like in this case, xpenology is a hacked appliance and synology try's to keep freeloaders out - not really that hard but there are changes on on new major versions and there is code signing of kernel modules for a while, its to expect they that with 7.0 they will do some more protection, but they are not putting in much effort to shut us out, there would be a lot of things that could be done pretty easy but we have not seen this kind of changes inside a running dsm line like 6.0, 6.1, 6.2