Leaderboard

You will NEVER be able to login to Synology account & quick connect without a REAL synology SN matching the current loaded DSM. The serials only match the form factor or real SN but are totally random and will NEVER work for Synology online services. In other words : if you run DS3622xs+ loader, you NEED a real SN and MAC address from a REAL DS3622xs+, it won't work with any other real SN (DS918+, DS3617xs, etc...) Edit : and no need to duplicate your post in other topics.. Once is enough.

On my Syno, I'm running Sonarr/Radar/Jackett The packages are available on community repo from Synology. But I'm running them with docker instead of community packages. I'm running another container a part : watchtower. It monitors other docker's running containers and auto update them each time there is an update available on docker registry hub. Whereas with syno community package, if maintainer does not update it for month, you are stuck to the current release available on community package. Once you understand docker's performance, trust me, you won't go back. But we are far away from the original topic here...

On original synology, you get a warning during upgrade for all packages that dont exist and/or not supported. Data for this application will still be on your data drives but if the app is not supported it will not be installed.

Anyone want try DS3622xs+ can fork this github repo: https://github.com/dogodefi/redpill-loader-action and run build3622xs+ actions. Such as :https://github.com/dogodefi/redpill-loader-action/actions/workflows/build3622xs+.yml Now DS3622xs+ has some issues: 1. It will cycle many times during the loader startup process Module [ixgbe] is removed. <redpill/bios_shims_collection.c:37> mfgBIOS: nullify zero-int for VTK_SET_GPIO_PIN <redpill/bios_shims_collection.c:37> mfgBIOS: nullify zero-int for VTK_SET_GPIO_PIN Although it is possible that this does not affect data security, it is not a perfect loader. 2. Like DS3617xs, you need to disconnect the Internet when installing for the first time (or edit /etc/hosts through the serial port of the loader, add 127.0.0.1 update7.synology.com) I hope that friends who are willing to explore can solve the above problems together.

@Orphée check https://www.portainer.io/ is also nice addon for Syno Docker

or Docker is maybe the best solution now with DSM7

I would like to build my own spk starting from already exist. I have already tested a "workaround" make tar of ts3 folder from dsm 6.3 system, untar on new system. in this way you lost ability to start and stop via panel, but application runs well Thanks for advice

HPSA ext module works great. Thank you very much! @pocopico

It will be "incompatible" and not running, you will only be able to uninstall it.

I think it will be deleted. Let my check if i can go back to Dsm6 to do a test

Depends. Some applications are on the data drive and some on the DSM drive.

The disks are always partitioned with three partitions. The first one holds the DSM installation, the second one is the swap and the third one holds the data. This will happen on all drives. If you reinstall DSM you are messing with the first partition. If you select to keep settings then also most DSM configuration settings will be preserved as well. Data is always untouched. You will have to reinstall DSM but the data will be untouched.

That is a good question, i dont know.

Обновил Tinycore до 0.4.5, поменял очередность сетевых карт и WOL заработал.

Sorry for my missing information. Yes, It's DS3615xs. I'll try it tonight.

cool thx ! so then i can confirm that my Test migration from DS3617xs to DS3622xs+ was successfully (Baremetal) i used 1 HDD with some Test Data and everything was still available. Steps i did 1. block internet to DS3617xs 2 turn off the DS 3 switch the Loader (USB Stick) 4 Boot up and wait until the DS come up and reachable in the Network (ping) 5 use the pat file from the tinyloader and start migration, i used the Option dont keep settings( 2.Option), maybe someone can use NR1 as test 6 wait until the migration process has reached 100%, then the DS should rest as usual, 7 wait until the DS is back online and you can process with DSM7 Wizard to complet.

Not exactly. I build a 6.2.4 fresh install DS3615xs. I had also a fresh built 7.0.1 DS3622xs+ confirmed as running (just to be sure all settings was OK (sata etc...) I stopped both VMs, I deleted 16GB virtual disk (SATA 1:0) from DS3622xs+ and added/replaced with the 16GB virtual disk from 6.2.4 VM At boot I was "ready to migrate" I gave the 7.0.1 pat file to launch migration, it rebooted as usual, done.

Hello, Je ne vais donc pas paraphraser mes VDD, juste donner mon expérience du coup. @mprinfo Tout l'intérêt du RDM est justement de pouvoir passer de baremetal à ESXi et vis versa sans soucis. Et cela fonctionne bien. Personnellement je fais tourner ESXi 7.0 sans aucun problème, je n'ai rien downgrade de particulier mais j'utilise une carte LSI SAS en passthrough, Ce downgrade était à priori nécessaire pour les performances disques avec mauvais driver, mais en ESXi 7.0 je ne suis pas sur du tout que ce soit encore nécessaire. Et au contraire avec le RDM il faut utiliser le AHCI et ne surtout pas laisser la P120i gérer le raid. @kevinevic La première question à te poser et de savoir si ça a un réel intérêt pour toi d'utiliser ESXi ou non. Si ton usage se résume à 99% Synology, il vaut peut être mieux rester sur du baremetal, et faire tourner ce qui peut l'être avec Docker (Jeedom tourne très bien sous docker). Ceci étant dit, comme déjà évoqué, tout dépend du matériel que tu as. Dans mon cas perso, j'ai un HP Microserver Gen8 Xeon avec 16Gb de RAM. De mon point de vue perso, inutile d'envisager un hyperviseur (ESXi ou Proxmox pour ne citer qu'eux) si tu as moins de 16Gb de RAM, parce que tu vas très vite être limiter par le manque de RAM disponible si tu compte faire tourner plusieurs machines virtuelles. Je pense que l’intérêt principale d'un hyperviseur et de permettre de s'affranchir des contraintes de configurations exotiques de la machine hôte/physique (Carte mère, type de carte réseau, drivers associés etc...). A partir du moment où tous les périphériques sont détectés/fonctionnels dans ton hyperviseur, tout le reste est "émulé" dans tes machines virtuelles : - nombre de vCPU (nombre de cores) - quantité de RAM allouée à la VM - carte réseau conventionnelle (comme E1000e sur ESXi). - création d'un port COM virtuel accessible en telnet depuis le réseau (utile pour débug Xpenology quand la carte réseau n'est pas détectée) Une VM qui tourne sur hyperviseur a un gros avantage, elle est déplaçable de façon presque "transparente". Si ta machine physique tombe en panne, tant que tes disques sont intacts et tes VM accessibles, tu remonte une autre machine, pas forcément identique, tant que ESXi (ou proxmox) est capable de tourner dessus, tes VM fonctionneront à nouveau sans aucune modification sur la nouvelle machine. Cependant, faire tourner un hyperviseur veut dire qu'il faut comprendre son fonctionnement, surveiller les mises à jour éventuelles. Cela ajoute une couche de configuration/supervision. Est-ce vraiment nécessaire ? Toi seul saura répondre à cette question. Pour ma part, j'ai commencé avec un Xpenology en baremetal sur un HP N54L, je faisais tourner Jeedom dessus avec un container docker. Mais j'avais besoin de pouvoir faire tourner de temps en temps des machines virtuelles (ubuntu/linux) J'ai fini par remplacer le N54L par un HP Microserver Gen8 et je suis passé par ESXi pour faire tourner Xpenology. J'ai alloué 4Gb de RAM à Xpenology, me laisser 12Gb (un peu moins en considérant que ESXi a besoin de RAM pour fonctionner) pour les autres VM que je faisais tourner. J'ai également changé de domotique de Jeedom pour Home Assistant. Il y avait une version clé en main pour ESXi, au delà du fait que j'ai trouvé Home Assistant plus pratique à l'usage. Et contrairement à toi j'ai fait le cheminement inverse, j'ai basculé Home Assistant sur un raspberry pi dédié, pour ne plus avoir de domotique HS à chaque fois que je décide d'administrer l'ESXi (l'arrêter pour changer les disques et faire des tests Xpenology, etc...) Sur le HP Gen8, je fais tourner ESXi sur une clé USB bootable (port interne sur la CM) J'ai un SSD qui sert de datastore pour stocker les VM. Et mes 4 disques 4To sont branchés sur une carte PCI-e LSI SAS2308 HBA que j'envoie en passthrough dans la VM Xpenology. Pour les disques, j'ai choisi cette option pour garder le SMART data accessible dans DSM, pour que DSM puisse m'avertir si un disque tombe en carafe. Mais ça implique de gérer les drivers mpt3sas de la carte dans le loader. Ce que RedPill c'est bien faire aujourd'hui, même si ce loader est encore à considérer comme en "béta". Quand tu utilises un hyperviseur avec Xpenology, la question que tu dois te poser est de savoir comment gérer les disques de Xpenology. Le plus simple est de créer des disques "virtuels" prenant l'intégralité de chacun des disques. Avantage : simplicité d'intégration dans la VM Inconvénient : Incompatible avec autre chose que ESXi. Impossible de les débrancher/transférer simplement en baremetal. Pas de remontées SMART data des disques non plus. 2 autres choix sont possibles : - RDM (Raw Device Mapping) : Cette solution permet de mapper un disque physique à un fichier "disk" virtuel. Cela permet de présenter une image disque virtuel dans la VM mais qui écrira exactement sur le disque comme si c'était physiquement le disque branché dans la VM. Cette solution permet justement de pouvoir basculer/revenir en baremetal si besoin est, car les disques ont été intégralement gérés/initialisés par DSM. Le petit inconvénient reste que les données SMART data ne sont toujours pas accessible dans DSM. - Sinon une carte PCI-e LSI SAS HBA en mode IT que tu donnes en passthrough dans la VM. Cette option requiers certains prérequis. Le premier étant que ton CPU doit être compatible passthrough. Les xéons sont compatibles, mais pas les céléron. Donc si ton Gen8 est équipé d'un Celeron G1610t, c'est mort, faut changer de CPU. Il faut que cette carte soit reconnue par le loader. C'est le cas avec le loader DS3615xs de Jun's. Ca fonctionne plutôt bien. Cela a été plus compliqué au début avec le nouveau loader Redpill. mais on arrive à une situation qui se stabilise actuellement et mes derniers tests valident le fonctionnement de ma carte en passthrough. Mes VM actuellement dispo à titre d'exemple : Ce n'est que mon expérience perso au fil du temps, mais je ne suis pas un expert des hyperviseurs pour autant. J'espère que nos réponses te seront utiles.