Installation HP GEN8 - ESXI 6.5U1 + VM DSM 6.2.2

[mprinfo]

@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]

oui, je l'ai redémarré depuis ESXI, et il est bien mort !

Vive la machine de test

[mprinfo]

Tu es sous quelle version ?
Tu as quel loader ?

Envoyé de mon BLA-L29 en utilisant Tapatalk

[jojo]

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]

j'ai retrouvé dans ma doc 1.03b pour le loader

[mprinfo]

@jojo ça a donc fonctionné
Tu as trouvé le problème ?
Oui le loader est le 1.03b

Envoyé de mon BLA-L29 en utilisant Tapatalk

[jojo]

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]

une vrai "mer...", même le retire du snapshot ne fonctionne pas. Ce serait alors un problème avec mon ESXI ?

[mprinfo]

Tu oublies une chose ta vm ne sert que pour le bootloader
DSM lui est installé sur tes disques monté en rdm

Envoyé de mon BLA-L29 en utilisant Tapatalk

[Lazer]

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]

@jojo tu es sur ton dsm de test ?
Peux tu me donner une image de ta config

Aprè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]

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]

Le disque 2.

Où les 2 même comme ça t'es tranquille.

[mprinfo]

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
 

[Lazer]

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]

@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]

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]

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]

Ah ok, faut suivre, c'est pas simple.

Bref, je reste avec ma version alors, c'est plus simple.

[jojo]

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]

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

[mprinfo]

je viens de faire une mise a jour des premiers post

[mprinfo]

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

 

1. 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é)
2. 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
3. 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:

1. 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)
2. 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:

1. Le périphérique de chargement peut être accidentellement configuré dans Storage Manager, ce qui entraînera une panne du système
2. Les partitions du chargeur peuvent être mappées par inadvertance en tant que dossiers USB ou eSata dans File Station et être endommagées
3. 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:

1. Téléchargez le script FixSynoboot.sh ci-joint
2. Copiez le fichier dans /usr/local/etc/rc.d
3. 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]

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]

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é ?