Leaderboard

for one thats only true for 918+ and the other thing is even when present since loader 1.04b existed it only came to attention years later, there seem to be lot of users not having trouble with it, there might be other factors involved like what bios version the controller hast a what chip version you could test it with 3 disk in a raid5 and hibernation on, i di provide a extra version with the old driver (that can do sn and smart) you are safe when using 3617, just do a migration with 1.03b 3617 loader and thats it, you cant use hardware transcoding with that but most/all devices can replay higher grade streams so in most cases (in LAN) there is no real need for on the fly transcoding yes, you cant downgrade in a migration step

Bonjour, Un périphérique USB est identifié par un numéro d'identifiant unique en 2 partie, la première identifiant le constructeur, la seconde le produit. Exemple d'un lsusb sur ma machine linux perso : [jacques@jacques ~]$ lsusb Bus 002 Device 002: ID 8087:8000 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:8008 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 002: ID 174c:3074 ASMedia Technology Inc. Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 006: ID 046d:0825 Logitech, Inc. Webcam C270 Bus 003 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub Bus 003 Device 003: ID 0b05:17cf ASUSTek Computer, Inc. Bus 003 Device 002: ID 174c:2074 ASMedia Technology Inc. Bus 003 Device 008: ID 2101:020f ActionStar Bus 003 Device 007: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 003 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub [jacques@jacques ~]$ J'ai un port série sur un adaptateur USB qui est identifié par 067b:2303 et par exemple une webcam Logitech c270 identifiée 046d:0825. Avec ces codes, le noyau sait quels drivers il doit charger pour mettre en service les périphériques. J'ai eu un problème avec un matériel utilisant un port série USB dont le périphérique créé dans /dev n'avait pas les bons droits. Pour corriger ça, j'ai créé une règle udev qui défini pour le périphérique 0590:0090 des droits d'accès sur le device et appelle un script pour exécuter des commandes nécessaires avant de mettre en service le port. Ceci est placé dans une règle nommée 99-obpm.rules et située dans le dossier /etc/udev/rules.d/ À titre d'exemple, voici cette règle : [jacques@jacques ~]$ cat /etc/udev/rules.d/99-obpm.rules KERNEL=="hidraw*", ATTRS{idVendor}=="0590", ATTRS{idProduct}=="0090", MODE="0666", RUN+="/home/jacques/bin/UpdateUsbOBPM.sh" [jacques@jacques ~]$ Il y a de bons tutos sur les règles udev, mais je n'ai pas gardé les liens quand j'ai du régler mon problème. À partir du moment où le device est créé avec le bon nom et les bons droits, et que le pilote correct est chargé, il n'y a pas de raison de ne pas pouvoir y accéder ensuite. Bons tests Jacques

It seems to me a strange thing, mystifying… Try attached .so. libsynonvme.so.1

Поставил тут себе несколько фигней (Piwigo, NextCloud, TorrentMonitor) и захотелось, чтоб ссылочки на рабочем столе на них были. А не тут то было. Синелоджики позаботились о нас ))) Фигнам, а не ссылочки Нашел вот такую вот прикольную штуковину: https://github.com/vletroye/Mods Теперь ссылочки есть

10 - What is the relation between DSM updates and the loader? Synology delivers three types of updates to DSM: - Major updates: x.x (e.i DSM 6.1) - Intermediate updates: x.x.x (e.i DSM 6.1.4) - Critical updates: x.x update x (e.i DSM 6.1.7 update 1 or DSM 6.1 update 1) Whenever an update is released it is strongly advised to first make an update on a test machine prior updating your "production" machine. This goes for all types of updates but more so for major and intermediate updates where there tend to be enough changes to DSM's kernel for the loader not to work anymore. In fact it is safe to say that 100% of the time the loader will not work and an updated version of the loader will be required. Critical updates have posed less issues with the current loader (jun's loader) BUT if memory serves me well, loaders pre-dsm 6.0 also required that they be updated for the critical updates to work. In other words, whenever a DSM update is released you always need to keep in mind that it can potentially brick your machine because the loader might not be able to handle that update. Which means that the loader would first need to be updated prior you being able to apply the update that was released by Synology. So before you start updating your machine always come to the forum first and have a read here: https://xpenology.com/forum/forum/78-critical-updates/. This is where users report whether DSM updates work with the current loader or not. I strongly suggest you pay a visit to these topics. They shows the relation between loader versions and DSM versions: DSM 6.x: https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/ DSM 7.x: https://xpenology.com/forum/topic/62221-tutorial-installmigrate-to-dsm-7x-with-tinycore-redpill-tcrp-loader/