All Activity

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 7.2.1 69057 Update 4 - Loader version and model: RR v24.4.7 | DS3622xs+ - Using custom extra.lzma: NO - Installation type: BAREMETAL - HP Prodesk 400 G2 Mini - i3-6100T - 8GB DDR4 - Additional comments: 1. Created new USB boot disk, using RR v24.4.7 .img 2. Used menu.sh to create the loader 3. findsynology > Recover 4. Once back into DSM, performed update to U5 from the web console, reboot

in a original system the usb vid/pid would always be the same (f400/f400), not sure if they would check that for upgrading to a different system as it is by default the same on original systems we can start guessing and try to check and test in /etc/synoinfo.conf is a entry "dsm_installtion_id" that looks like it could be the culprit when the new loader re-creates (changes) a new synoinfo.conf from its loader config it might get lost in best case it might solve the problem by just placing the old value after installing and reboot, but it also could be a value that is created as a fingerprint on every boot and we dont know how its created so it ends up different on a loader changed system also a reminder there are things like "synowedjat" https://xpenology.com/forum/topic/68080-synology-backdoor/ so synology is identifying and tracking every system individually and thats need fingerprinting and id's, the SN and MAC's is not the only thing for sure @AuxXxilium or @Peter Suh might know more about hat individual id? i guess that kind of scenario is not part of the loaders (migration from a different loader and reading stuff from the old installation, i'd guess they look for there own loader config file on the boot media and what the user inputs there) that rabid hole can be pretty deep in worst case, for a simple use it might be easier to just document it and know that when using hyperbackup and replication scenarios the id of systems will change and these things will have to start from scratsch

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 7.2.1-69057 update-4 - Loader version and model: redpill.v0.9.4.9 - DS3622xs+ - Using custom extra.lzma: NO - Installation type: Proxmox VE 8.1.4 - Additional comments

Not yet, as far as I know.

Outcome of the update: SUCCESSFUL DSM version prior update: DSM 7.2.1-69057 update-3 Loader version and model: ARPL-i18n / DS3622xs+ Installation type: BAREMETAL - MB: ASUS P5Q Deluxe / CPU: Q6600 Additional comments: Manual update from control panel Bootloader not updated

L'update 4 ne m'a jamais été proposé,(il me semble que ça dépend des modèles)

Are there any options to run xpenology on a baremetal setup with nvme storage only?

There was one thing I didn't mention. The point is that not all MOBOs work with this power reservation setting. (I understand that S5 in the CMOS BIOS is involved.) In particular, there are reports from users that MSI's products are incompatible with REDPILL. (The NIC does not respond for no particular reason, etc.)

Bonjour, Est ce qu'il y a une raison pour que tu n'ai pas mis d'abord l'update 4 et ensuite l'update 5 ? Je ne sais pas si l'update 5 incorpore les fonctionnalités/correctifs de l'update 4. Peut être que quelqu'un pourra répondre à cette question, pour ma part je suis les updates dans l'ordre logique Gastonzz

Finalement, durant le reboot, sur le GRUB de arc, j'ai fait un démarrage de dsm au lieu de dsm direct boot (qui est par défaut) et dsm a démarré normalement. Tout semble ok maintenant. Désolé pour le dérangement mais ça aidera peut être d'autres dans la même situation.

as my 7.1 long term informations where older i looked it up, looks like there is a catch to that (at least now) only older units (presumably kernel 3.10, mostly 2015 units and older) will get one more year up to 6/2025, namely the ds3615xs, the other commonly used types like 3617 or 3622 will loose update support 6/2024 and will have to be updated to 7.2 (if security updates are important) https://kb.synology.com/en-global/WP/Synology_Security_White_Paper/3 looks like i will have to upgrade my dva1622 in the next 3 month to 7.2 there was also a "Synology E10G18-T1" with that performance problem so it might stretch to more nic's or its something different but if exchanging the driver on the already running system clears the speed problem then it would be clearly that issue edit: i looked up the syno nic, its a "newer" model, not tehuti bsed, its marvell aquantia (aka AQtion Aquantia AQC) and the driver module to look for is "atlantic.ko", sadly "modinfo" is not part of dsm but you would see driver realted information when the driver is loaded ( dmesg |grep atlantic) also a sign of a original driver would be if its signed by synology, you could check this by looking in raw/hex at the end of the driver "xxd /lib/modules/8021q.ko" for one that usually is still original and "xxd /lib/modules/atlantic.ko" you will see "Module signature appended" at the very end of the driver when its a driver provided by synology forgot to mention it but my test system was using arc loader, as most loaders have there own driver set its worth checking the driver version and comparing to the original driver from synology (if there is one), in some cases it might not work using synology's drivers as there might not cover other oem versions of nic's, seen that with ixgbe drivers on 6.2 (but also tehuti and other intel drivers and realtek 2.5G nic driver) so it might not work to "downgrade" the driver to syno's original in some cases, that might result in a non working nic, it might find the device but if the phy chip is not supported the it will not show any connection or the driver might not load at all so in case of experiments like that its handy to keep a 2nd nic inside that can be used if the 10G nic fails to work after changing the driver

Ja, das geht. Auch kannst Du direkt ein modding auf ein 18/19er-Modell mit machen. Dafür habe ich dieses Thema hier aufgemacht:

Attention ! Suite a la derniere mise a jour Proxmox , le nouveau kernel bloque le demarrage (carte mere N100) , pour ma part , jai du epingler le 6.5.13 , car le 6.8.4 : bloque le chargement des le demarrage ! A suivre...

Не..... И даже не учусь ....)))

Ist das Problem behoben? Wenn nein, dann schreibe mal bitte welche CPU verbaut ist, und welcher Lader genutzt wird.

Hallo, eine CPU mit einer TDP von 65w ist als NAS wegen des Stromverbrauchs und der Abwärme ungeeignet. Außerdem gibt es mit INTEL CPUs keine Probleme, um ein neueres DSM zu nutzen. Alles mit TDP <10w ist sinnvoll. Das geht z.B. los ab Intel N3150 https://ark.intel.com/content/www/de/de/ark/products/87258/intel-celeron-processor-n3150-2m-cache-up-to-2-08-ghz.html Bei neueren CPU-Familien sollte man nur die "Apollo Lake" wegen der begrenzten Lebensdauer außen vor lassen.

I would like to once again urgently point out the need to back up every DOM of Synology + models. It's done in a few seconds. Simply run via SSH with root: dd if=/dev/synoboot of=/volume1/myShare/DS412+synoboot-6.2.4u5.img where "myShare" is your share for general purpose. Of course, it only makes sense if the file is then downloaded from the Synology to another location.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 7.2.1 69057 Update 4 - Loader version and model: latest loader mshell by Peter Suh - DS3622xs+ - Using custom extra.lzma: NO - Installation type: baremetal on Fujitsu Celsius W530

Peter thanks for your reply. Again thank you for your hard work on the loader. After a complete rebuild the PC will shut down and not power on. Really strange. Yes I did notice that even though the error appeared the boxes were checked and the PC shutdown at night but will not power on in the morning. I will try removing the weekend task and just use the weekday and see if that is the issue. I don't know about a true Sysology NAS since all of my OEM NAS's are QNaps.

волшебник)))

Да вот вам а здоровье ....))) Сайт иногда тупит и не всегда сразу даёт скачать, так что пробуйте и пробуйте SurveillanceStationClient

The above error message appears not only here but also in other places. However, it does not affect the actual operation of the scheduler. The last changed settings will remain the same. Please try out StartUp and Shutdown in action. However, I'm not sure if it's a Synology bug or a REDPILL bug, but there is a problem with the schedule operating because weekdays and weekends are differentiated. Maybe your weekend doesn't work out the way you want it to. I experienced this phenomenon a long time ago and was not using the weekend setting. Didn't this problem occur with the genuine product?

The Intel 10G ixgbe modules of DS3617xs(broadwell) and DS3622xs+(broadwellnk) operate somewhat specially. Both models must use the vanilla ixgbe that was originally built into the original model. I don't know if the TCRP of pocopico you used has adjustments for this vanilla module. rr and my mshell have this vanilla ixgbe adjustment. ixgbe compiled separately from redpill should only be used on other than these two platforms broadwell / broadwellnk. These two files are vanilla module files that are imported directly from the original module in Synology. The module pack is managed by overwriting this file on top of the ixgbe compiled by redpill. https://github.com/PeterSuh-Q3/arpl-modules/blob/main/vanilla/broadwell-4.4.302/ixgbe.ko https://github.com/PeterSuh-Q3/arpl-modules/blob/main/vanilla/broadwellnk-4.4.302/ixgbe.ko I hope you try it with rr or mshell.

6MBit like 1000 times less? thats like not working at all i have my main with 7.1.1 and backup system with 7.2.1, the later one does 250 MByte/s with a bunch of older disks and hyperbackup rsync (not tested wit iperf) so from the 7.1.1 to 7.2.1 is no problem the main 7.1.1 from a win11 system makes 1G Byte/s as long as it fills up ram and then drops to 650MB/s, cant ask for more (good nvme ssd on win11 and 20GB single file) just tested it for 7.2.1 from win11 and its the same as with 7.1.1, 1GByte/s as long as its ram and then ~600MByte/s (no iperf neede here if it looks that good already) (win11 and 7.1 is a sfp+ mellanox and 7.2 a rj-45 Tehuti TN9210 based (might be similar to you syno card) there are some base differences even with systems having the same dsm version, 3615 is kernel 3.10 but 3617 and 3622 are both 4.4 so looks no like its not related to that as 3615 and 3617/22 seem to perform both badly but anyway try arc loader arc-c (sa6400) with 7.2.1 that's kernel 5.x and might be different any switch involved there might be differences when connecting directly or through a switch as of how speed is negotiated what speed does the system show (ethtool eth0 | grep Speed) when its only 6Mbit/s its interesting but if you want to save time consider just keep it with 7.1, as its a LTS version and afair will get the same support as 7.2, if there are no features you need from 7.2 you dont miss anything when just using 7.1

На офф. сайте остались только 2.x.x версии. Остальные поудаляли. Если у кого-то есть в наличии - поделитесь пожалуйста.