Leaderboard

So I migrated my xpenology server from DS918+ model to DS3622xs, and the nvme cache no longer works since the model number no longer exist in libsynonvme.so.1. I dig into the libsynonvme.so.1 and found it might check your pcie location to have the nvme drive works properly. After inspect the file, I found it just checks /etc.defaults/.extensionPorts and we just need to modify that. Here are the steps: 1. Check your nvme pci location(in my case it's 0000:00:01.0😞 udevadm info /dev/nvme0n1 P: /devices/pci0000:00/0000:00:01.0/0000:01:00.0/nvme/nvme0/nvme0n1 2. Modify /etc.defaults/.extensionPorts to have the port number match your nvme location. cat /etc.defaults/extensionPorts [pci] pci1="0000:00:01.0" 3. I did not even restart and the nvme cache drive already appears. Hope this helps anyone who is looking to solve this. Update: If you worry a system update will revert this modification, just add a startup script with root: sed -i 's/03.2/[your_pci_last_three_digs]/g' /etc.defaults/extensionPorts In this way, no matter what version you goes, this will always stay.

Thread moved here.

TCRP is a completely separate "mini" OS that loads before DSM. Enabling "friend" functionality causes it to load a TCP/IP stack and attempt to gain a DHCP lease so it can connect to the Internet and download updates *for TCRP*, not DSM. You can configure TCRP to also use a static address (in the user_config.json), but whether you use DHCP or static for TCRP it has no impact on the networking config for DSM. You could also create a static lease on your DHCP server, tied to the NICs MAC address. That way TCRP and DSM will always get the same IP address.

Где вы видели в 6-ой версии DSM SynologyPhotos? Этот пакет есть только в DSM-7. Поэтому очень трудно понять, о чем вы спрашиваете. Про специализированный пакет из DSM-6 Вам написали выше. Нет, если не сумеете сами написать и задействовать особый сценарий - скрипт. Все медиафайлы Сино всегда хранит в исходном качестве. Обрабатываются только отдаваемые клиенту потоки.

The TCRP friend loader is neither Jot nor Jun, but has the advantages of both. No PostUpdate required, and loader latency is not as high as Jun loader. For the TCRP friend loader you need to rebuild the loader with the DS920+F option you know.

Thanks for the advice. I was able to get the M.2 cache working on DS3622xs+ following the instructions

I just opened an issue for the chelsio nics at https://github.com/fbelavenuto/arpl-modules/issues thanks

M SHELL now also supports TCRP friends. You can use the command like below. curl --location "https://github.com/PeterSuh-Q3/tinycore-redpill/raw/main/my.sh.gz" -O; tar -zxvf my.sh.gz; ----------------------------------------------------------------------------------------- Usage: ./my.sh <Synology Model Name> <Options> Options: postupdate, noconfig, noclean, manual, realmac, userdts - postupdate : Option to patch the restore loop after applying DSM 7.1.0-42661 after Update 2, no additional build required. - noconfig: SKIP automatic detection change processing such as SN/Mac/Vid/Pid/SataPortMap of user_config.json file. - noclean: SKIP the RedPill LKM/LOAD directory without clearing it with the Clean command. However, delete the Cache directory and loader.img. - manual: Options for manual extension processing and manual dtc processing in build action (skipping extension auto detection). - realmac : Option to use the NIC's real mac address instead of creating a virtual one. - userdts : Option to use the user-defined platform.dts file instead of auto-discovery mapping with dtcpatch. Please type Synology Model Name after ./my.sh - for friend mode ./my.sh DS918+F ./my.sh DS3617xsF ./my.sh DS3615xsF ./my.sh DS3622xs+F ./my.sh DVA3221F ./my.sh DS920+F ./my.sh DS1621+F ./my.sh DS2422+F ./my.sh DVA1622F ./my.sh DS1520+F ./my.sh FS2500F ./my.sh DS1621xs+F ./my.sh RS4021xs+F ./my.sh DVA3219F ./my.sh RS3618xsF ./my.sh DS1019+F