DJR72

Pour le 1 oui c'est exactement cela. C'est tout bête, mais dans un cas comme celui, si tu es en total black out, avoir une clé de boot de secours te permettra au moins de vérifier / d'éliminer le fait que ton OS boot correctement. A ce propos, sache que le système envoie toutes les infos sur le port série...ce qui n'est pas forcément pratique, mais cela reste une possibilité pour "voir" ce qui se passe au boot. Il existe un système de connectique à base de câble série vers USB qui permet une connexion au port série et ainsi de voir ce qui se passe...et même de se connecter en mode console Pour le 2) un rsync permet effectivement de faire une copie d'un disque, de faire des svg différentielles etc...dans notre cas cela peut permettre de sauvegarder les données du système, ainsi que toute les données. Toutefois, ce n'est pas un miroir du disque car pour cela c'est une autre procèdure / utilitaire : dd Donc en synthèse : une clé USB + un câble série vers USB te permettent rapidement d'y voir plus clair et d'accéder (sans le réseau) à la console du syno. A noter que l'accès en mode console n'a pas besoin d'avoir le ssh de mis en oeuvre, tu y accèdes avec ton compte admin...tout simplement le rsync, peut te permettre de sauvegarder sur un disque externe, monté sur un port USB par exemple, tout ou partie de ton système et de tes données. Pour le système, si celui-ci n'était pas correctement repris, je pense que reconfigurer certains paramètres via l'interface graphique est certes contraignant mais offre une garantie de bon fonctionnement

Bonjour, Bien que j'arrive après la bataille, deux conseils si je puis me permettre : crée une autre clé usb avec la même config, c'est à dire celle qui fonctionne actuellement en particulier les réglages contenus dans le fichier grub.cfg active le ssh, cela permet de faire : des sauvegardes en ligne de commande via un simple rsync par exemple voir d'où vient le problème / faire un minimum de diag ...(quitte à demander de l'aide sue le forum comme tu viens de le faire ;-))) et au passage de vérifier que le serveur fonctionne toujours, même si l'interface web utilisateur est down

Hello, Si le service DDNS proposé par la box SFR ne fonctionne pas avec OVH, il existe des paquets sous linux qui font ça très bien. Pour tout vous dire j'ai mis cela en place chez un ami abonné chez Orange (fibre) qui possède un syno (718+) et dont les adresses @IP changent ...disons très, très, très souvent. J'ai pris l'option de lui configurer une VM Linux sur son syno avec les paquets : ddclient pour le ddns (un service qui fonctionne en mode autonome dès lors où la VM est UP) certbot-dns-ovh qui permet, si besoin, de gérer le renouvellement de certificats let's encrypt avec via le nom de domaine OVH Du coup, il n'a plus à se préoccuper de son @IP publique que cela soit pour let's encrypt ou pour l'adresse @IP du DNS OVH. Pour la VM 500Mo ont réservé mais c'est tout juste 100Mo utilisé par le linux (archlinux dans notre cas) Aujourd'hui sa VM sert : De Gateway SSH avec une connexion par clés (sans mot de passe donc) permettant ainsi de ne pas avoir à ouvrir le ssh du syno sur le net (...) De reverse proxy HTTPS SSH A mettre en oeuvre un proxy socks via un plugin sur le navigateur (voir capture ci-après) Du coup pour se connecter au syno / à son réseau local il utilise soit un tunnel ssh soit un tunnel ssh over ssl et dans les 2 cas la mise en place un proxy socks permettera, depuis son navigateur, d'atteindre les applications hébergées sur le syno...puis de ressortir sur le net depuis son réseau local...mais ceci est une autre histoire ;-)) Tunnel ssh + proxy socks : ssh -D 10998 monuser@mavmsyno.mondomain.ovh -p 55528 Tunnel ssh over SSL + proxy socks : ssh -D 10998 monuser@mavmsyno -o 'ProxyCommand=proxytunnel -z --proxy=proxyentreprise:3128 --remproxy=mondomain.ovh:443 --dest=%h:%p -X' Si vous savez vous servir d'un client ssh au travers de putty par exemple, ce n'est pas si compliqué que cela tout en ouvrant un champ des possibles plutôt ...sympa ? Aller, c'est la trêve des confiseurs !

Bonjour, Je prends le train en route pour dire que je suis moi même chez SFR et concernant l'@ip elle susceptible de bouger, lors d'un reboot par exemple. Il semblerait qu'il y ait une solution avec le service Synology DDNS voir https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/Network/What_Is_Synology_DDNS_Service

Vi, nous sommes d'accord pour les virtio ; j'ai moi même constaté que d'une version DSM à l'autre cela ne fonctionnait pas toujours. Sinon, concernant le NAT et le PAT sur ton routeur d'entrée c'est une bonne chose mais, je présume que tu le sais déjà, un simple telnet sur un port non conventionnel te renverra une empreinte SSH-2.0-OpenSSH_8.1 en clair. Mais bon il n'y a pas de solution miracle, on peut juste faire au mieux pour se protéger Sur ce bon Noël !

Bonjour, Dans les cas désespérés, sachez qu'il est toujours possible de monter la partition / disque contenant le DSM dans un linux quelconque. Pour ma part, j'ai déjà fait le test / ce type de manips sous linux : faire un mount de la partition DSM dans une autre VM Linux ou, si l'hôte hébergeant votre hyperviseur est un linux, vous pouvez aussi le faire directement. (Archlinux et l'hyperviseur open source KVM dans mon cas) Cela fonctionne, bien qu'il faille quelque peu batailler sur la partie reconnaissance de disque. Une fois le disque / partition montée nous avons à faire à un linux (certes customisé) ce qui veut dire que les fichiers sur lesquels vous pouvez intervenir sont : /etc/ssh/sshd_config dans lequel vous pouvez (ré)autoriser la connexion en root si besoin /etc/shadow dans lequel certains comptes peuvent être désactivés en positionnant un 1 entre les derniers deux points :1: Ci-après un extrait de mon fichier /etc/shadow avec une installation de base ou didier est l'utilisateur qui a été créé lors de la première connexion (niveau admin donc). NB : j'ai raccourci les passwd des users admin, didier et guest pour avoir un affichage plus compact admin:$6$CWdHt5aUA$YQKx1hnsOfZc1MxlbT3z7rUFF1:18237:0:99999:7::1: anonymous:*:10933:0:99999:7::: avahi:*:10933:0:99999:7::: bind:*:10933:0:99999:7::: daemon:*:10933:0:99999:7::: dbus:*:10933:0:99999:7::: didier:$6$5yqFZ/oBp$J7A/U9yWstr35WFCc7MxaKiMin:18237:0:99999:7::: dovecot:*:10933:0:99999:7::: FileStation:*:18237:0:99999:7::: ftp:*:10933:0:99999:7::: guest:$6$rU8yySyQcgO5DlNr$cqZUEo1FLOeEfA9v8CF1:18245:0:99999:7::: une copie du fichier /etc/passwd (un extrait) dans lequel vous verrez que didier et admin appartiennent tous les deux au groupe 100 admin:x:1024:100:System default user:/var/services/homes/admin:/bin/sh anonymous:x:21:21::/nonexist:/usr/bin/nologin avahi:x:84:84::/:/bin/false bind:x:53:53::/:/usr/bin/nologin daemon:x:2:2::/:/bin/sh dbus:x:81:81::/:/usr/bin/nologin didier:x:1026:100::/var/services/homes/didier:/bin/sh Et pour terminer le fichier group (un extrait) dans lequel on voit que didier et admin appartiennent au même groupe #$_@GID__INDEX@_$226662$ administrators:x:101:admin,didier Au passage, je rappelle pour les non linuxiens qu'il est toujours possible d’accéder en ssh en tant que root; et donc de s'affranchir du compte administrateur. Pour cela il faut commencer par faire un sudo passwd root, mettre le mot de passe de votre choix, puis débloquer la possibilité de se connecter en root dans le fichier /etc/ssh/sshd_config. Pendant que vous y êtes, je suggère (fortement) de désactiver les connexions avec mot de passe pour privilégier les connexions via des clés ssh. Cela vous mettra au moins à l'abri d'une attaque par dictionnaire de mot de passe. Pour rappel, les bonnes pratiques visent à ne pas utiliser le compte root mais de passer par un sudo. Toutefois, cela peut vous êtes très utile d'autant que ce compte vit sa vie complètement de manière indépendante en dehors du compte administrateur (...) Sinon, pour ceux qui souhaitent se connecter en port série sous l'hyperviseur open source KVM la commande est : virsh console [nom_de_la_VM appelé aussi domain] --console --force C'est aussi beaucoup simple (et sécur) que de monter les disques j'en conviens ! ;-))...j'aurais peut être du commencer par là, non ?

L'inconvénient de passer en direct sur le hardware c'est que vous êtes très (trop) fortement dépendant de celui-ci. Comme suggéré plus haut, essayez de partir avec un boot plus ancien comme le DS3615xs 6.1 Jun's Mod V1.02b.img Si vous avez un I5 et un peu RAM virtualisez le DSM et nous n'aurez pas ces pbs d'hardware

Merci pour ta réponse. Juste un truc qui me chiffonne quant tu dis Intel e1000e est une ref de carte lan, tu voulais sans doute parler des disques sata vs virtio. Proxmox, j'avais regardé il y a qq années mais je ne voulais pas d'une soluce "semi-fermée". J'avais commencé avec XEN sur Debian, puis VirtualBox sur Debian aussi. J'ai quitté Debian car j'avais des pb de drivers pas à jour (impossible de faire un shutdown ;-(() et pis les montées de versions commençaient vraiment à me prendre la tête. Du coup j'étais mûr pour passer sur des systèmes linux en rolling release tel qu'Archlinux. Ce qui me plait bien en autre avec cette distrib c'est que l'install est minimaliste et du descends un système en 20mn from scratch ! Cerise sur le gateau, ils mettent à disposition une série de tools qui te permette de te faire une iso customisée dans laquelle tu peux embarquer tes paquets préférés. Bref, j'ai donc une iso avec laquelle je peux faire à peu près tout ce que je veux, cloner un disque en local ou sur le lan, installer un archlinux, etc...Cà marche tellement bien que j'arrive même à installer un serveur archlinux à distance chez des potes non informaticiens en faisant un rebond via teamviewer par exemple , mais je mégare !! En parlant de rebond, ma cible sera un os linux avec quelques VM dont une pour le DSM. Parmi les VM j'aurais, comme actuellement du reste, une VM avec un apache (fonctionne aussi avec ngnix) qui me fait un reverse proxy ssh. Il y a pas mal d'avantages à cela : pas d'ouverture du port SSH sur le net tu peux la descendre qd tu veux ...pis surtout personne ne bloque le port 443 en sortie !! Donc avec qq binaires sur une clé usb, un zip dans mail ou un dossier dans le cloud (bref nul besoin d'être admin sur le poste zindows) tu rentres chez toi depuis n'importe où (ou presque car il ya tout de même certaines entreprises qui ne laissent en sortie que des listes blanches...mais bon elles ne sont pas légion tout de même). Bref, ce que j'essaye de te faire entrevoir c'est qu'avec une VM qui te fait un reverse proxy SSH tu limites ta surface d'attaque sans compter que, bien évidemment on ne rentre en ssh qu'avec un système de clé (comprendre pas de user / mdp). C'est ce que je viens de mettre en place chez un ami qui à (oh surprise) un syno et qui ne voulais pas l'exposer directement sur le net car il semblerait que certains ransongiciels sur friands des synos (...). On finalise actuellement la conf fail2ban pour les éventuelles attaques sur apache, mais là encore pas grand chose d'exposé: un shaarli tout au plus (...) A la question comment une fois la session ssh établie attaquer l'interface du syno ? Tout simplement avec un transfert de ports / proxy socks. En fait avec ce principe tu peux ressortir sur le net en passant par chez toi, ce qui peut être très pratique parfois. On peut même pousser jusqu'à faire un tunnel ssh pour faire du RDP, VNC, Teamviewer ou que sais-je encore. N'hésite pas à revenir vers moi si tu veux plus de précisions sur cette soluce qui, il est vrai, est la bête noire de ceux qui veulent faire de la sécurité en entreprise. Et donc du coup, c'est pas illégal en soit car après tout on ne fait que sortir par le port 443 de l'endroit où nous sommes. Certains te dirons qu'ils utilisent ce type de stratagème pour surfer depuis les endroits publics pour éviter les problèmes de man in the middle, mais là nous sommes bien loin de nos xpenology ! Merci pour tes conseils en tout cas ;-))

Maintenant je vais prendre le temps de répondre aux questions. Mes serveurs sont sous archlinux sans desktop, c'est à dire que je discute avec eux en ssh ce qui me suffit amplement pour pour l'usage que j'en ai. J'ai aussi la possibilité de lancer la console graphique de KVM (virt-manager) via un client X avec mon portable sous Windows 10. Voilà grosses mailles pour la quincaillerie. Concernant le boot IMG, comme on le verra dans le script, un LV déclaré en USB fonctionne parfaitement, mais il est vrai que j'ai quelque peu tatonné avant de fixer cette solution. Au final on peut (au choix) : booter sur le fichier .img directement en ayant effectué ses modifs via le moyen qui convient le mieux via un LV disque USB (perso c'est la solution que je retiens car cela correspond mieux au mode de gestion de mes systèmes) une image ISO (pas testé car ce la ne correspondait pas à ma cible) Quant au disque contenant le DSM, le syno fonctionne avec les UUID (fort heureusement du reste) et on peut (une fois le système monté) le balader ... Effectivement, les disques sont en ext4 ou btfrs en fonction du choix lors de la création du volume (de mémoire). Perso, je cherchais à valider que je pouvais (re)lire un disque DSM et un disque de data via un linux lambda (archilinux dans mon cas). Pour le disque DSM c'est de l'ext4 avec un RAID dans lequel est monté la partition système et le swap. Lorsque l'on cherche à monter le disque (le LV dans mon cas) le système couine car les partitions sont marquées comme faisant partie d'un RAID ...non connu du système ; ben vi hein !!. Après pas mal de recherches, j'ai fini par monter la partition du LV contenant le DSM via un simple mount : mount -t ext4 /dev/sdx1 /mnt Et bam ! voilà ma partition contenant tout le DSM avec dans /volume1/entware-ng tous les packages et l'installation opkg. Donc ce fut la première étape validée pour moi. Après j'ai monté un nouveau volume (LV) pour simuler un disque dédié aux datas. Bon là je n'ai pas eu d'autres choix que de passer la la création d'un groupe RAID, puis d'y assigner mon LV (en entier pour mes tests). J'ai créé un partage, j'y ai collé des datas via un rsync depuis mon serveur linux : les perfs pas top à cause de l'empilement des FS (File System), puis après avoir arrêté la VM, j'ai monté le LV contenant les datas dans un archlinux de base. Le système avait fait un mappage automatique de la partition du syno vers vers /dev /md127. Je l'ai découvert car en voulant monter la partition btrfs le système me répondait qu'elle était occupée ! Après qq recherches j'ai finalement fais un : mdadm --stop /dev/md127 Puis j'ai pu monter ensuite les partitions du LV avec un simple mount -t btrfs /dev/sdx3 /mnt/synodata Bref, au final j'ai pu relire et récupérer les données de mon disque syno. Il ne me reste plus qu'à faire une dernier test avec des LV en raid pour voir si je peux aussi facilement monter les partitions et les lire et j'aurai valider que je peux effectivement confier mes disques de données au DSM et virer mes vieux serveurs au profit d'une conf plus compacte dans un Fractal Design Node 304 par exemple. A suivre... PS dites moi si vous souhaitez un tuto plus explicite pour comment monter un xpenology sous KVM

OK, sorry de ne pas avoir répondu plus tôt mais je viens de finaliser un script bash qui permet d'automatiser la création d'une VM xpenology sous KVM. Au passage j'ai résolu mon pb pour accéder aux messages lors du boot de la VM via les commndes virsh (voir à la fin du script) Je mettrais le lien vers GitHub ASAP PS : Testé et validé avec la version DSM_DS3615xs_15217.pat et le bootloader DS3615xs 6.1 Jun's Mod V1.02b.img #!/usr/bin/env bash # Script de création d'une VM sous KVM pour xpesynology # Nom du VG utilisé pour la création des VM VGName=lvm-kvm # Path pour le device mapper utilisé pour les montages kpartx / loosetup # nécessaire pour monter le file system afin de modifier le fichier grub.cfg devmapp=/dev/mapper # Nom du fichier IMG (bootloader) ImgFile=SynoBoot_DS3615xs-6.1_V1.02b.img # Nom de la VM que nous allons créer # --> nom du fichier IMG sans son extension VMname=$(echo $ImgFile | sed "s/.img//" ) # Nom du LV qui recevera la copie l'image (fichier img) # --> nom du fichier IMG sans son extension LVBootName=$(echo $ImgFile | sed "s/.img//" ) # Taille du LV --> correspondant au fichier bootloader (IMG) ImgSize=$(du $ImgFile | awk '{print $1/1000}') # Nom du LV complet avec son path LVBootFullName=/dev/$VGName/$LVBootName # Nom du LV pour le DSM (system) LVDSMName=Syno_system.6.2-test # Taille du LV pour le DSM # NB : 10Go mini sinon erreur lors de l'installation LVDSMSize=10G # Full name pour le LV DSM LVDSMFullName=/dev/$VGName/$LVDSMName # Point de montage pour la partition contenant le fichier grub.cfg SynoBoot=/mnt/synology # Optionnel : # - Numéro de série à mettre dans le fichier grub.cfg # - Laisser à la valeur 0 (zéro) sinon # Pour rappel le lien pour générer un serial: # https://xpenogen.github.io/serial_generator/index.html MySerialNumber=xxxxxxxxxxx # Optionnel : # - timeout à mettre dans le fichier grub.cfg # - Laisser à la valeur 0 (zéro) sinon MyTimeOut=3 # Optionnel : # - Passer le boot en mode verbeux # - Laisser à la valeur 0 (zéro) sinon Verbose=1 # Exemple de paramètres utilisés pour la création de la VMExemple de paramètres utilisés pour la création de la VM # Nbr de CPU VMcpus="2" # RAM VMram="1024" # Type OS VMOStype="linux" # Nom de l'OS VMOSvariant="archlinux" # Disque USB --> BootLoader VMBootDisk="path=$LVBootFullName,bus=usb,target.dev=sdb,boot.order=1" # Disque pour le DSM (system) VMDSMDisk="path=$LVDSMFullName,bus=sata,target.dev=sda,address.type=drive,address.controller=0,address.bus=0,address.target=0,address.unit=0" # Remote display : VNC, spice, ... VMgraphics="spice" # Conf Network : en bridge chez moi modèle de la carte VMnetwork="network=bridge,model.type=e1000e" #----------------------------------------------------------------------- DeleteVM(){ # Check VM exist virsh dominfo $1 >>/dev/null 2>&1 if [ $? -eq 0 ]; then echo "virsh destroy $1" virsh destroy $VMname sleep 1 echo "virsh undefine $1 --remove-all-storage" virsh undefine $1 --remove-all-storage sleep 1 fi } #----------------------------------------------------------------------- # Etape 1 : Creat LV + Recopie du fichier image dans le LV # NB : Cela sera l'équivalent du fichier IMG dans un LV.... # # Pour cette étape on part du postula que : # - le fichier de boot zip est téléchargé, # - l'extraction du zip a été effectué # - le DSM DSM_DS3615xs_24922.pat est téléchargé #----------------------------------------------------------------------- # Check + Delete VM if exist DeleteVM $VMname # 1.4 Suppression du LV if exist if [ -b $LVBootFullName ]; then echo "Suppression de $LVBootFullName" lvremove -f $LVBootFullName fi sleep 1 # Ajustement / arrondi au Mo supp if [[ $ImgSize =~ ^[+-]?[0-9]+[\.,]?[0-9]*$ ]]; then LVBootSize=$(( ${ImgSize%[.,]*} + 1 ))m else LVBootSize=$(( ${ImgSize%[.,]*} + 1 ))m fi # 1.4 Creat du LV if not exist if [ ! -b $LVBootFullName ]; then echo "lvcreate $VGName -n $LVBootName -L $LVBootSize --wipesignatures n" lvcreate $VGName -n $LVBootName -L $LVBootSize --wipesignatures n fi sleep 1 # 1.4 Affichage / vérif du LV # echo lvdisplay $LVBootFullName # lvdisplay $LVBootFullName # sleep 1 # 1.5 Copie du fichier img dans le lv echo dd bs=512K status=progress if=$ImgFile of=$LVBootFullName dd bs=512K status=progress if=$ImgFile of=$LVBootFullName sleep 1 # 1.6 Check du LV ...on doit sensiblement avoir la même chose... # on fixe les éventuels pb de GPT sgdisk $LVBootFullName -e >>/dev/null 2>&1 parted $LVBootFullName unit s print >>/dev/null 2>&1 echo fdisk -l $LVBootFullName fdisk -l $LVBootFullName # 1.7 Afficher les partitions contenues dans le fichier img echo fdisk -l $ImgFile fdisk -l $ImgFile sleep 2 #------- Fin de l'étape 1 #----------------------------------------------------------------------- # Etape 2 : Adaptation / Modification du fichier grub.cfg pour # - Modifier le n° de série # - Mettre le boot en mode verbeux le cas échéant # - Augmenter/changer la value du timeout # # Les noms contenant des tirets doivent être transfomés avec 2 tirets # car le montage par kpartx les transfome comme suit : # nom lvm .............: /dev/lvm-kvm/Syno_DS3615xs-6.2.v1.03b # nom remappé par kpartx : /dev/mapper/lvm--kvm-Syno_DS3615xs--6.2.v1.03b # # NB : On aurait un résultat équivalent avec la commande loosetup #----------------------------------------------------------------------- printf "\n" mapplvm=$(echo $LVBootFullName | sed 's/^\///;s/dev\///;s/-/--/g;s/\//-/') sleep 1 # On récupère dans un array le nom des partitions mappées par kpartx kix_lvm=( $(kpartx -av $LVBootFullName 2>&1 | grep -owE "($mapplvm+[0-9]+)") ) # Affichage du premier poste du tblx pour vérifier que tout est OK # echo ${kix_lvm[0]} # sleep 2 # On monte la partition contenant le fichier grub.cfg à modifier echo mount $devmapp/${kix_lvm[0]} $SynoBoot mount $devmapp/${kix_lvm[0]} $SynoBoot sleep 1 # Check si le fichier grub.cfg existe if [ -f $SynoBoot/grub/grub.cfg ]; then echo "Le fichier $SynoBoot/grub/grub.cfg existe" fi # Optionnel # Generate serial : https://xpenogen.github.io/serial_generator/index.html # Si changement du serial number demandé if [ $MySerialNumber != "0" ]; then # Remplacement de la chaine de caractères pour le serial number ... echo "Change seial number --> sn=$MySerialNumber" sed -i "s/^set sn=.*$/set sn=$MySerialNumber/" $SynoBoot/grub/grub.cfg cat $SynoBoot/grub/grub.cfg | grep -ai "set sn=" sleep 2 fi # Si changement du timeout demandé if [ $MyTimeOut != "0" ]; then echo "Timeout --> set timeout=$MyTimeOut" sed -i "s/^set timeout=.*$/set timeout=$MyTimeOut/" $SynoBoot/grub/grub.cfg cat $SynoBoot/grub/grub.cfg | grep -ai "set timeout=" sleep 2 fi # Si changement mode verbeux demandé if [ $Verbose != "0" ]; then # On cible la chaine de caractères "elevator quiet syno_port_thaw" # pour la sustituer à ............."elevator syno_port_thaw" echo "Verbose mode..." sed -i 's/elevator quiet syno_port_thaw/elevator syno_port_thaw/' $SynoBoot/grub/grub.cfg cat $SynoBoot/grub/grub.cfg | grep -ai "syno_port_thaw" sleep 2 fi # umount de la partition précédemment montée echo umount $SynoBoot umount $SynoBoot sleep 1 # Retirer les mapp (...) echo kpartx -dv $LVBootFullName kpartx -dv $LVBootFullName #----------------------------------------------------------------------- # Etape 3 : Creation de la VM avec : # - Le LV contenant l'imge du boot # - un LV de 10Go pour accueillir le système (DSM) # 3.2 Suppression du LV if exist if [ -b $LVDSMFullName ]; then echo "Suppression de $LVDSMFullName" lvremove -f $LVDSMFullName fi sleep 1 # 3.3 Creat if not exist if [ ! -b $LVDSMFullName ]; then echo "lvcreate $VGName -n $LVDSMName -L $LVDSMSize --wipesignatures n" lvcreate $VGName -n $LVDSMName -L $LVDSMSize --wipesignatures n fi sleep 1 # Creation du fichier xml contenant la définition de la VM virt-install \ --name=$VMname \ --memory=$VMram \ --vcpus=$VMcpus \ --os-type=$VMOStype \ --os-variant=$VMOSvariant \ --disk=$VMBootDisk \ --import \ --disk=$VMDSMDisk \ --graphics=$VMgraphics \ --network=$VMnetwork \ --print-xml > $VMname.xml sleep 1 # Create VM via le fichier xml généné par virt-install echo virsh define $VMname.xml --validate virsh define $VMname.xml --validate sleep 1 # Demarrage de la VM en se mettant en ecoute : echo virsh start $VMname virsh start $VMname # Affichage des infos du boot de la VM # cf mode verbeux demandé dans le fichier grub.cfg echo virsh console $VMname --force virsh console $VMname --force # Voilà la VM est démarrée et l'installaion peut commencer # en se connectant via l'url http://find.synology.com/ # NB pour sortir de la console faire CTRL + $ sur un clavier azerty ;-)) # enjoy !

Bonjour, Merci de ta sollicitation. Comment dire oui, après quelques jours d'une série essais-erreurs en tout genre j'ai maintenant (cela date d'il y a moins de 2 hh) un xpesyno up to date !! J'ai pas mal galéré autour du boot USB qui avait un comportement pas toujours prévisible...d'autant que je montais tantôt l'image (img) tantôt une copie de l'image (via dd sous linux) dans un disque (non sata) de type Virtio. En réalité cela fonctionne assez bien le disque virtio permet bien de ne pas booter sur un fichier de type IMG et au passage de virtualiser les FS de boot et système sous LVM. Mais voilà, étant parti au début sur sur une version 6.1 pour une installation réputée fonctionnelle (cf post concernant la méthodo d'installation) j'ai effectué les diverses MAJ pour finir au top level des MAJ. Et là, waoouuu j'ai passé plusieurs jours (pas à plein temps hein ! ;-)) à comprendre pourquoi je perdais la visibilité de mon syno entre 2 boot : pas de réseau. Bref, le temps de comprendre ce qui ce se passe (...) d'autant que recopier / reformater le disque virtio via l'image (img) ne fonctionne pas toujours (un truc de dingue quoi, mais je vais creuser). Au passage savez-vous comme mettre le boot en mode verbeux histoire d'avoir sur la console les messages lors du boot ?. J'ai bien essayé de virer le mot de clé "quiet" dans le grub.cfg comme dans toute bonne distrib linux...sans succès. Cela serait TRES utile (voir indispensable) lorsque cela ne se comporte pas comme prévu au démarrage Donc ma config fonctionne actuellement avec une image (synoboot) 6.2 v.1.03b dispo sur le site et un DSM en 6-2-2-24922 (youpiiiii) Avant de me lancer définitivement dans l'aventure, je vais maintenant voir comment les disques (de données) sont fichus histoire de voir comme les "récupérer" / lire en dehors de l'OS xpenology. J'ai commencé à regarder le disque système pour voir : à priori du RAID 1 pour le système et le swap, je n'ai pas encore réussi à les monter sous un linux (archlinux pour moi) lambda pour le moment mais j'avoue ne pas y avoir passé bcp de temps. Sinon, le boulot réalisé est impressionnant au niveau reverse engineering bravo, respect ! Par ailleurs, j'apprécie le gestionnaire de paquets me permettant d'installer mes p'tits tools linux avec lesquels j'aime bien travailler et grâce auxquels je retrouve un environnement de travail assez familier (avec /sous ssh) Dites moi si un modop KVM vous parait pertinent car effectivement il y a pas mal des choses sur PROXMOX diffusent çà et là sur les forums US. En synthèse, c'est vrai que c'est assez simple à mettre en oeuvre...une fois que l'on a le bon boot avec le bon DSM !! PS : le laisse le post ouvert pour le cas où quelqu'un aurait une réponse quant à la possibilité d'avoir un boot en mode verbeux

Ok, merci de l'info. Je vais aller regarder de plus près

Bonjour, Je suis sur un DELL precision.390, Intel(R) Core(TM)2 Duo CPU (E7500 @ 2.93GHz) 8Go de RAM sous ArchLinux(up to date ;-)) Au niveau disques j'ai : un SSD sur lequel le système est installé un SDD dédié au VM via LVM (ref 2 disques de 6To ref WDC WD60EFRX-68L Mon hyperviseur est KVM qui lui même utilise QEMU et j'ai qq VM qui fonctionnent que cela soit du Windows 10, ou d'autres linux ArchLinux sans pb depuis qq mois / années ;-)) Avant de me lancer dans xpenology, j'ai souhaité en faire un test via une VM, jusque là rien d'extraordinaire. J'ai donc créé une VM avec : un disque de type USB pour le fichier IMG un disque SATA de 10Go Le processus de boot se passe bien et j'arrive à formater le disque de 10Go, ensuite la VM reboot et c'est là que cela se gâte car après le reboot, la VM devient inaccessible / invisible : aucune trame n'arrive vers mon serveur DNSMASQ. Bref, je tourne en rond depuis hier soir et j'avoue avoir épuisé toutes les solutions que j'ai pu glaner de ci, de là et très franchement je sèche (...) Les versions que j'ai essayé avec le disque USB sont celles dont les liens sont dispo ici https://xpenology.com/forum/topic/8024-liens-vers-toutes-les-versions-des-loaders/ J'ai donc testé les images contenues dans Synoboot_3615.zip : l'installation se fait mais disparition de la VM lors du reboot (pas ip) DS3615xs 6.1 Jun's Mod V1.02b.img : installation OK, cela reboot et on boucle sur la demande de réparation DS3615xs 6.1 Jun's Mod V1.02b (MBR_Genesys).img : idem que le précédent Lorsque l'installation est faite / terminée, si je monte le disque que j'ai alloué à la VM, je vois bien qu'il est formaté (ci-après une capture ) Bien évidemment je n'ai eu aucune erreur, du moins visible. Maintenant j'aimerai (re)valider avec vous le principe d'installation : Dois-je installer avec DS3615xs 6.1 Jun's Mod V1.02b.img ou le bootloader ? ou peut importe les deux images font le même job ? De même, si j'ai bien compris le principe, la VM devra booter sur la clé USB (disque dans le cas de la VM) car le système ne s'installe pas sur le disque SATA c'est bien cela ? Le doute m'assaille : concernant l'adressage du disque SATA, QEMU n'attache pas le disque SATA sur le contrôleur SATA00, mais sur le contrôleur SATA01. Du coup, si l'on regarde bien l'adressage du disque dans la conf XML QEMU cela donne un truc du genre : <disk type="block" device="disk"> <driver name="qemu" type="raw" cache="none" io="native"/> <source dev="/dev/lvm-kvm/xpenology-01"/> <target dev="sdg" bus="sata"/> <address type="drive" controller="1" bus="0" target="0" unit="0"/> </disk> la configuration du grub.cfg (dont je présume qu'il est mis à jour lors de l'install) pour le sata est set sata_args='sata_uid=1 sata_pcislot=5 synoboot_satadom=1 DiskIdxMap=0C SataPortMap=1 SasIdxMap=0' Est-ce correct ? Dans tous les cas, merci de votre aide qui me sera précieuse. PS : Je posterai par la suite un p'tit tuto pour les linuxiens fainéants qui souhaitent éditer directement le fichier img sans passer par windows ou autres outils. L'astuce consiste à monter le fichier img dans un répertoire et puis effectuer les modifications souhaitées.