mprinfo Posté(e) le 13 avril 2020 Auteur Signaler Posté(e) le 13 avril 2020 @jojo tu as redémarrer pour voir si le problème était résolu ? Car je n'ai au aucun soucis sur DS3615xs et DS3617xs
jojo Posté(e) le 13 avril 2020 Signaler Posté(e) le 13 avril 2020 oui, je l'ai redémarré depuis ESXI, et il est bien mort ! Vive la machine de test
mprinfo Posté(e) le 13 avril 2020 Auteur Signaler Posté(e) le 13 avril 2020 Tu es sous quelle version ?Tu as quel loader ? Envoyé de mon BLA-L29 en utilisant Tapatalk
jojo Posté(e) le 14 avril 2020 Signaler Posté(e) le 14 avril 2020 j'ai fait l'upgrade de DSM de DSM 6.2-23739 Update 2 versa 6.2.2.-24922 (comme toi) Loader : ??? le même que toi, car je ne fais que des choses que tu as validées. Comment puis-je en voir la version ?
jojo Posté(e) le 14 avril 2020 Signaler Posté(e) le 14 avril 2020 j'ai retrouvé dans ma doc 1.03b pour le loader
mprinfo Posté(e) le 14 avril 2020 Auteur Signaler Posté(e) le 14 avril 2020 @jojo ça a donc fonctionnéTu as trouvé le problème ?Oui le loader est le 1.03bEnvoyé de mon BLA-L29 en utilisant Tapatalk
jojo Posté(e) le 15 avril 2020 Signaler Posté(e) le 15 avril 2020 j'ai dû tout réinstaller, ma VM, etc ... et restore du backup Puis Snapshot Puis retentative d'upgrade, et là ça a replanté. La seule différence que je vois avec toi, c'est que tu as un 3617xs, et moi un 3615xs. Espérons que le restore du scnapshot fonctionnera
jojo Posté(e) le 15 avril 2020 Signaler Posté(e) le 15 avril 2020 une vrai "mer...", même le retire du snapshot ne fonctionne pas. Ce serait alors un problème avec mon ESXI ?
mprinfo Posté(e) le 15 avril 2020 Auteur Signaler Posté(e) le 15 avril 2020 Tu oublies une chose ta vm ne sert que pour le bootloaderDSM lui est installé sur tes disques monté en rdmEnvoyé de mon BLA-L29 en utilisant Tapatalk
Lazer Posté(e) le 15 avril 2020 Signaler Posté(e) le 15 avril 2020 Tout à fait, pour ta VM de tests, il faut que DSM soit installé sur un disque virtuel de quelques Go (et pas un disque complet en RDM) et que tu snapshots ce disque virtuel. Car comme dit mprinfo, ça ne sert à rien de snapshoter le bootloader (disque virtuel de... 32 Mo je crois)
mprinfo Posté(e) le 16 avril 2020 Auteur Signaler Posté(e) le 16 avril 2020 @jojo tu es sur ton dsm de test ?Peux tu me donner une image de ta configAprès si cela ne fonctionne pas je peux me connecter à ton esxi pour identifier et corriger le problème Envoyé de mon BLA-L29 en utilisant Tapatalk
jojo Posté(e) le 16 avril 2020 Signaler Posté(e) le 16 avril 2020 Pour mon SynoTest, on est d'accord que toute le config DSM se trouve sur le second disque (chez moi, un petit disque virtuel de 30 GB sur mon Datastore). J'ai un autre disque de 60 MN avec mon boot loader. Quand je fais unsnapshot avec ESXI, je fais quoi ? Le disque 1 (=bootloader) ou le disque 2 (= DSM). Ou rien ou les 2 ?
Lazer Posté(e) le 17 avril 2020 Signaler Posté(e) le 17 avril 2020 Le disque 2. Où les 2 même comme ça t'es tranquille.
mprinfo Posté(e) le 17 avril 2020 Auteur Signaler Posté(e) le 17 avril 2020 Le problème avec le dsm test de@jojo c'est qu'il a bien le bootloader sur sata 0:0 Par contre son disque dsm+data est en scsi 0:0 alors qu'il devrait être en sata 1:0 J'ai fais des tests la mise à jour passe si sata 1:0 Ca planté lorsque c'est scsi 0:0 Il n'a donc pas bien suivi le tuto que j'avais donné à ce sujet Par contre je sais pas comment ça ce pas pour le rdm si tu changes scsi et sata En disque virtuel on perd les données@lazer une idée Envoyé de mon BLA-L29 en utilisant Tapatalk 1
Lazer Posté(e) le 17 avril 2020 Signaler Posté(e) le 17 avril 2020 Euh non là désolé je sais pas. Tu sais que je suis toujours sur une vielle version de Diskstation 6.1.x D'ailleurs il faudrait que je profite du confinement pour tenter une mise à jour. J'ai mon volume Synoboot de 50 Mo sur IDE 0:0 Et mes disques pour DSM sur SCSI 0:x (x allant de 0 à N)
mprinfo Posté(e) le 17 avril 2020 Auteur Signaler Posté(e) le 17 avril 2020 @lazer regarde le début du tuto tu n'es pas dans les clous pour faire une mise a jour il faut avoir 2 contrôleurs sata donc toi est ton esxi 5.5 AUREVOIR le premier controleur sata 0 est pour le bootloader le second controleur sata 1 est pour les disques dsm 1:0, 1:1, 1:2 ...etc il faut mettre la carte réseau en E1000E je sais pas si cela passe en E1000
Lazer Posté(e) le 17 avril 2020 Signaler Posté(e) le 17 avril 2020 Je suis pas sûr d'avoir compris. En IDE le Synoboot sur DSM 6.2 ne fonctionne pas ? Tu veux dire qu'il faut SATA à la place ? Et que ESXi 5.5 ne sait pas le faire ? Par ailleurs la suite de ton message est incohérente car en contradiction avec le tuto en première page, puisqu'il est bien spécifié d'utiliser SCSI pour les disques de DSM, et non pas SATA. Du coup je ne sais pas ce qu'il faut faire....
mprinfo Posté(e) le 17 avril 2020 Auteur Signaler Posté(e) le 17 avril 2020 Le 09/11/2017 à 06:11, mprinfo a dit : Installation de DSM sous ESXI Voici les caractéristiques qu'il faut pour une VM ESXi 6 : Un controleur de disques SATA Un controleur de disques SCSI de type VMWare Paravirtual Le vmdk contenant le bootloader doit être rattaché au controleur de disque SATA (0,0) - Mode de disque Dépendant Le(s) vmdsk contenant les données doivent être rattaché au controleur disque SCSI - Mode de disque indépendant / persistant Le controleur réseau doit être de type E1000 Le reste dépend de vos envies (nb vCPU, RAM, controleur USB, port série, etc.) Ne pas faire la mise a jour vers DSM 6.2.1 @lazer je précise que ce n'est pas compatible avec la version DSM 6.2.1 c'est vrai que c'est pas vraiment clair car même moi je m'y perd Il faut 2 controleurs sata est je crois que c'est impossible sous ESXi 5.5 Le 21/11/2018 à 21:12, Lazer a dit : Merci Bon bah déjà je suis marron, sous ESXI 5.5 on ne peut pas ajouter de contrôleur SATA. Et je n'ai pas franchement prévu de faire la mise à jour d'ESXI 6.5.... la suite c'est ICI
Lazer Posté(e) le 17 avril 2020 Signaler Posté(e) le 17 avril 2020 Ah ok, faut suivre, c'est pas simple. Bref, je reste avec ma version alors, c'est plus simple.
jojo Posté(e) le 17 avril 2020 Signaler Posté(e) le 17 avril 2020 Il y a 12 heures, Lazer a dit : Le disque 2. Où les 2 même comme ça t'es tranquille. Je dais que j'aurais besoin du snopshot du disque 2, mais que fait ESXI, car il ne me demande rien
jojo Posté(e) le 17 avril 2020 Signaler Posté(e) le 17 avril 2020 Il y a 8 heures, mprinfo a dit : l n'a donc pas bien suivi le tuto que j'avais donné à ce sujet je n'avais pas reçu de notification par mail de son existence, mais en effet, il a réglé mon problème ! => MERCI 1
mprinfo Posté(e) le 18 avril 2020 Auteur Signaler Posté(e) le 18 avril 2020 je viens de faire une mise a jour des premiers post 1
mprinfo Posté(e) le 29 avril 2020 Auteur Signaler Posté(e) le 29 avril 2020 Mise a jour 6.2.3-25423 ok sur mon DSM de test mais on voit le boolloader A lire pour ceux qui utilisent des drivers Extension : https://xpenology.com/forum/topic/21663-driver-extension-jun-103b104b-for-dsm622-for-3615xs-3617xs-918/ ATTENTION AVANT DE FAIRE LE MISE A JOUR BIEN LIRE CE TOPIC https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/ Voici la traduction Lors de l'exécution de DSM 6.2.3 sous ESXi, les chargeurs de démarrage 1.03b et 1.04b de Jun ne parviennent pas à créer / dev / synoboot(cela peut être résolu en installant un script extrait du chargeur pour le réexécuter une fois le démarrage terminé) DSM 6.2.3 affiche les périphériques SATA (c'est-à-dire le chargeur de démarrage sur 1.04b) qui sont mappés au-delà de la limite MaxDisks lorsque les versions précédentes ne DSM 6.2.3 met à jour les masques de bits du port de disque synoinfo.cfg qui peuvent casser certains tableaux à nombre de disques élevé et provoquer un comportement étrange avec le périphérique du chargeur de démarrage Contexte: La définition du PID / VID pour une installation baremetal permet au chargeur de Jun de prétendre que la clé USB est un véritable chargeur flash Synology. Sur une installation ESXi, il n'y a pas de clé USB - à la place, le chargeur exécute un script pour trouver son propre périphérique de démarrage, puis le refait en tant que / dev / synoboot. C'était très fiable sur 6.1.x et le chargeur 1.02b de Jun. Mais en passant à DSM 6.2.x et aux chargeurs 1.03b et 1.04b, il y a des circonstances où / dev / synoboot est créé et le périphérique de démarrage d'origine n'est pas supprimé. Le résultat est que parfois le périphérique de chargement est visible dans Storage Manager. Quelqu'un a découvert que si le contrôleur était mappé au-delà du nombre maximal de périphériques de disque (MaxDisks), tout périphérique de démarrage / dev / sd errant était supprimé. L'ajustement de DiskIdxMap est devenu un autre moyen de "masquer" le périphérique de chargement sur ESXi et Jun ' Maintenant, DSM 6.2.3: la mise à niveau modifie au moins deux comportements DSM fondamentaux: Les périphériques SATA qui sont mappés au-delà de la limite MaxDisks ne sont plus supprimés, y compris le chargeur (apparaissant comme / dev / sdm si DiskIdxMap est défini sur 0C) Les masques de configuration de port de disque sont réécrits dans synoinfo.conf: internalportcfg, usbportcfg et esataportcfg et sur 1.04b, ne correspondent plus avec MaxDisks par défaut = 16. REMARQUE: Si vous avez plus de 12 disques, cela cassera probablement votre baie et vous devrez les modifier à nouveau (et ce n'est pas seulement un problème ESXi)! De plus, lors de l'exécution sous ESXi, DSM 6.2.3 interrompt le script de synoboot du chargeur de Jun de sorte que / dev / synoboot n'est pas créé du tout . Impacts négatifs: Le périphérique de chargement peut être accidentellement configuré dans Storage Manager, ce qui entraînera une panne du système Les partitions du chargeur peuvent être mappées par inadvertance en tant que dossiers USB ou eSata dans File Station et être endommagées L'absence de périphériques / dev / synoboot peut entraîner l'échec des futures mises à niveau, lorsque la mise à niveau souhaite modifier rd.gz dans le chargeur Le déballage du script synoboot de Jun révèle qu'il récolte les nœuds de périphérique, supprime complètement les périphériques et les refaits en / dev / synoboot. Il essaie d'identifier le périphérique de démarrage en recherchant une partition plus petite que la plus petite partition de baie autorisée. C'est une stratégie ambiguë pour identifier le périphérique, et quelque chose de nouveau dans 6.2.3 le fait échouer lors de l'état initial du système de démarrage. Il existe quelques options de configuration technique qui peuvent amener le script à sélectionner le bon périphérique, mais elles sont difficiles et dépendent de la version du chargeur, de la plate-forme DSM et du démarrage BIOS / EFI. Cependant, si le script de Jun est réexécuté après le démarrage complet du système, tout est comme il se doit. Extraire le script du chargeur et l'ajouter aux actions post-démarrage est donc une solution universelle à ce problème: Téléchargez le script FixSynoboot.sh ci-joint Copiez le fichier dans /usr/local/etc/rc.d chmod 0755 /usr/local/etc/rc.d/FixSynoboot.sh Ainsi, le propre code de Jun sera réexécuté après le démarrage initial après que les paramètres d'initialisation du système qui interrompent la première exécution du script ne s'appliquent plus. Cette solution fonctionne avec 1.03b ou 1.04b et est simple à installer. Cela devrait être considéré comme requis pour ESXi exécutant 6.2.3, et cela ne nuira à rien s'il est installé ou porté vers un autre environnement.
mprinfo Posté(e) le 29 avril 2020 Auteur Signaler Posté(e) le 29 avril 2020 Voici la solution pour les non linuxien on active dans DSM on ouvre winscp comme cela on aura pas accès au compte root mais au compte admin pour avoir accès au root directement il faut une clef d'installer on sélectionne le répertoire tmp et on copie le fichier FixSynoboot.sh que l'on a récupéré sur le site xpenology dans tmp on change les attributs en 755 on lance telnet on ce connecte en root : sudo -i on tape son mot de passe c'est le même que admin on exécute la commande suivante : cp /tmp/FixSynoboot.sh /usr/local/etc/rc.d C'est terminer on peut tout fermer et redémarrer DSM
sepult Posté(e) le 29 avril 2020 Signaler Posté(e) le 29 avril 2020 Toujours au fait des dernières nouvelles @mprinfo ! merci en parcourant le topic sur xpenology, je me suis aperçus qu'un membre a réalisé la bascule de son Gen8 vers esxi 7. comme ici par exemple : https://homeservershow.com/forums/topic/17689-attempt-at-installing-esxi-70-on-gen8/ as-tu tenté ?
Messages recommandés