JacquesF

Bonjour, Atheros, c'est très souvent le pilote pour les cartes Wifi. Pas forcé que ce soit ton cas, mais si tu n'as qu'une seule prise RJ45 sur ta carte mère, alors c'est bien ça. Jacques

Bonjour, Petite précision, le HTTPS peut aussi servir à authentifier le client et à refuser l'accès au serveur si la vérification échoue. Personnellement, mon serveur (pas mon NAS) est accessible via l'extérieur et dispose d'un certificat auto-signé, que je suis d'ailleurs le seul à utiliser... Mais la connexion doit vérifier les informations du certificat du client sinon l'accès est rejeté. C'est une fonctionnalité qui peut être très pratique pour les machines privées accessibles depuis le net. Jacques

Bonjour, A priori, rebrancher un à un les autres disques ne fera rien. La détection des disque le défini comme /dev/sdg, donc comme un disque connecté sur un contrôleur SATA, USB ou IDE éventuellement. Cela pourrait venir d'un disque émulé par le bios, mais sur une carte ASUS, je n'y crois pas. Sur un serveur HP, on aurait pu voir peut-être ainsi un disque accessible via ILo mais la carte mère est une carte relativement basique. A tout hasard, est-ce qu'un cache SSD n'aurait pas été validé dans la configuration ? même si je ne vois pas ce qu'il viendrait faire ici, mais dans cet écran, on retrouve ni plus ni moins que l'état des devices Disk détectés. A suivre Jacques

Sur certains disques durs (WD par exemple), il existe une mini partition contenant des programmes Windows spécifiques au disque. C'est peut-être la trace de ce type de partition, qui sait... Jacques

Bonjour, Dommage que le more du fichier sfdisk.log n'aille pas plus loin dans le post, il s'arrête à /dev/sdf alors que d'après le fdisk, le périphérique en cause est /dev/sdg Il faudrait les lignes suivantes pour avoir une idée si on trouve ou non ce disque dans les logs (appui sur la barre d'espace pour la page suivante, Entrée pour la ligne suivante). Donne aussi le résultat de la commande grep sdg /var/log/disk.log voir ce qui est indiqué dans ce fichier de traces. Visiblement, le disque de 8Go ne possède même pas de table de partitions, ça ressemble plus à un bug qu'à un vrai disque présent (même simulé). peut-être la trace d'une clef USB défectueuse ou retirée. Je suppose que le NAS a eu un reboot entre temps pour tenter de faire disparaître ce disque. A suivre donc Jacques

Bonjour, Ce disque est nommé "Config disk" donc il s'agit probablement d'une partition trouvée au boot. Personnellement, je regarderai ce qu'on trouve (via SSH) avec les commandes fdisk -l et more /var/log/sfdisk.log au niveau des différents disques. Ensuite, jeter un œil dans les logs au démarrage (dans /var/log/messages par exemple avec la commande more) voir si le disque apparaît et suite à la détection de quel objet. Pas d'autres idées pour le moment (sauf si il y a eu du iSCSI de configuré éventuellement). Jacques

Pour répondre à la question, le port 23 c'est celui du serveur Telnet... (et le 21 FTP donc) Connexion à distance en clair, mot de passe visible etc... A fermer absolument de l'extérieur, pour les accès internes, ça dépend de la taille et de la sécurisation du réseau local. Et de toute manière, pour les ports 5000 et 5001, il faut vraiement utiliser des comptes qui ne soient pas implicites (pas admin donc) et des mots de passes forts. Ensuite, comme on peut accéder via HTTPS et ainsi chiffrer la connexion, il n'y a aucun intérêt à laisser le port 5000 ouvert pour des connexions en clair depuis l'extérieur. Ces réglages sont à faire sur le parefeu. Jacques

A première vue, c'est du Google Translate... Pas évident de comprendre tout ça. Je pense que le tutorial est le lien le plus utile en effet. 1) Le boot se fait via la clé USB 2) Cette clé doit être laissée sur le NAS 3) Le BIOS doit démarrer sur la clé 4) Les disques (4x4 To) contiendront le système Xpenology ET les données 5) Créer un RAID avec les disques pour la sécurité. J'ai peut-être répondu aux questions Jacques

Bonsoir, Regarde le tuto d'installation avec le loader de Jun. Il doit y avoir un lien vers le fichier extra.lzma qui contient des drivers additionnels, entre autre pour certaines cartes réseaux. Il suffit de le rajouter sur la clef USB, s'il est présent il est chargé automatiquement au démarrage. Peut-être que ça règlera ton soucis. Jacques

Bonjour, D'après la copie d'écran, il y a une erreur sur le système de fichier principal (erreur non réparée), /dev/md0 est le raid supportant DSM (monté en tant que /). Comme le boot ne permet pas facilement de prendre la main sur le système, le mieux serait (à mon avis) : 1) de faire une sauvegarde de la configuration (sans supprimer celles existantes, rien ne dit que le contenu sera lisible si le système de fichiers est corrompu) 2) Démarrer le NAS avec un Live-CD (System Rescue CD ou SuperGrub Disk par exemple, enfin tout Live-CD basé sur Linux) et monter la partition /dev/md0 dans un répertoire de travail 3) Lancer fsck sur la partition en faute (fsck /dev/md0 éventuellement avec l'option -y pour valider les réponses à Yes), voir le manuel de la commande pour plus d'information (man fsck), on trouve des tas d'exemples sur le web 4) Si la réparation semble s'être bien passée, redémarrer le NAS normalement 5) Sinon, réinstaller le DSM sans toucher aux autres systèmes de fichiers Jacques

rc.sysv => run command System V (ancien mode de démarrage unix/linux S99 => S=Start, 99 = démarrer le script en tout dernier (après S01, s02, sXX) Résultat, ce script est lancé à chaque démarrage de la machine, pour configurer les interfaces ethernet 0 et 1 avec le WOL activé je suppose. Plutôt que s'embêter avec Winscp et le mot de passe root, il est plus simple de créer le script dans un dossier partagé dans /volume1/NomDuDossier, de se connecter en SSH et de passer admin avec sudo puis de copier le script dans /usr/syno/etc/rc.sysv avec la commande mv (move) ou cp (copy). mv /volume1/NomDuDossier/S99ZZZ_Shutdown.sh /usr/syno/etc/rc.sysv/ Ensuite, mettre les droits avec un chmod 775 /usr/syno/etc/rc.sysv/S99ZZZ_Shutdown.sh suivi d'un chown root:root /usr/syno/etc/rc.sysv/S99ZZZ_Shutdown.sh Cela devrait suffire pour récupérer un script avec les bons droits et au bon endroit. Jacques

Bonjour, Concernant l'aggrégat de ports, côté NAS c'est du 802.3ad géré par du bonding soft classique sous linux. Donc, que la carte le gère nativement ou non, je ne crois pas que cel ait une quelconque importance. Côté switch par contre, il faut que celui-ci soit capable de le faire. Enfin, une petite remarque, à moins d'avoir plusieurs clients simultanés pour un débit soutenu, assurer 4 gb sur le lien c'est peut-être du luxe. Et il faut que le switch de raccordement soit capable d'assurer réellement ce débit vers le NAs et les clients à la fois, donc probablement pas le switch d'une box. Jacques

Bonjour, Concernant les mises à jour en DSM6, je les ai personnellement toutes faites via l'interface, classiquement quoi. Et je n'ai eu aucun soucis. Le forum en anglais indique en général pour chaque post la configuration de la machine, la mise à jour faite et la nécessité ou non de redémarrer. Cela devrait te permettre de vérifier avant d'appliquer une mise à jour. Ensuite, les mises à niveau de sécurité ne sont pas toujours urgentes, tout dépend du contexte. Si ton NAS est à usage personnel, dans le réseau de la maison et sans accès depuis l'extérieur, rien ne presse en principe. Sinon, il faut aussi regarder si la mise à niveau te concerne (fonctionnalité ou paquets utilisés ou non) avant de l'appliquer systématiquement. Maintenant, je suis d"accord avec Marcos, je conserverai le Xpenology (un Gen8 fonctionne plutôt pas mal, c'est ce que j'ai et sans avoir changé le proc) et est récent. Jacques

Il est tout à fait possible de rester avec du SHR sous DSM6, il y a un post dédié à ce sujet dans le forum. C'est ce que j'ai fait personnellement, l'avantage du SHR étant que c'est un raid soft qui est très souple dans la configuration et la modification des disques. Et comme c'est lisible sous n'importe quel linux, j'aime bien... Ensuite, en raid soft linux, les disques sont identifiés par des informations placées en fin de disque, donc en principe la position sur le contrôleur SATA n'a pas d'importance pour recréer la grappe raid. DSM6 formate par défaut les volumes en BRTFS au lieu de EXT4, mais si les disques sont déjà partitionnés avec des volumes de données cohérents, je ne vois pas pourquoi il reformaterait ceux-ci. Il saura les lire tout simplement. Maintenant, la recommandation est toujours la même, faire une sauvegarde des données avant... En principe, aucun formatage n'est fait sur les volumes de données sans un message de confirmation, donc toute proposition de recréer un volume ou de formater des données devrait être refusée. Ensuite, le retour de ton expérience sera des plus intéressant je pense, et pourrait prendre place sous forme d'un tuto peut-être. Jacques

Bonjour, SMB signifie System Message Block et c'est un protocole de transfert de fichiers mis au point par IBM. CIFS signifie Common Internet File System et est, comme d'habitude avec MS, une mise en œuvre particulière de SMB. En bref, cela revient au même ou presque, il s'agit plus d'une appelation qu'autre chose. Sous Linux, cas du NAS, un export des systèmes de fichiers (ext4 ou brtfs) se fait vers le monde Windows via SAMBA via le protocole SMB. Mais un montage linux vers un système de fichiers Microsoft, ou exporté via SAMBA, se fera sous l'appellation CIFS dans le fichier fstab... En bref, CIFS est équivalent à SMB, mais les évolutions SMB2 et 3 apportent des améliorations qui ne sont pas reprises par CIFS. Voir cette page pour plus d'informations. Jacques

Synology (et donc Xpenology) permet de créer des LUN iSCSI ou des Targets. Les disques SAN servent beaucoup en virtualisation mais on peut aussi les utiliser sous linux simplement. Une distribution comme CENTOS (RedHat libre et gratuite), mais elle n'est pas la seule, permet de créer des cibles iSCSI qui pourront être adressée via le réseau (il est préférable d'utiliser une interface dédiée, dans ton cas un câble direct) entre le SAN (ou la machine offrant les services iSCSI) et le NAS) depuis Xpenology. Par rapport à une solution eSATA avec Port Multiplexeur, on y gagne en débit à mon avis, et il est possible d'offrir plusieurs disques comme cibles iSCSI de cette façon. Ensuite, tout ce qui est envisageable avec des disques physiques locaux l'est au niveau du NAS (Raid 6, SHR, etc...). L'inconvénient : il faut que le second serveur tourne sous une distribution offrant ce service, avec les ressources processeur et RAM suffisantes pour ne pas dégrader les performances (en terme de proc, ça ne doit pas être trop gourmand, pour ce qui est de la RAM et de l'accès aux disques, il doit bien exister des recommandations quelque part sur le web). De plus, il ne faut pas oublier de démarrer le SAN avant le NAS... sinon les volumes ne seront pas accessibles. Je ne sais pas comment se comporte Synology avec un SAN invisible au démarrage, ça fait partie des tests à faire, ou à rechercher sur leur site. En revanche un SAN ou un export NFS absent au démarrage sous ESXi, ça ne repasse pas vraiment en service une fois le SAN ou le NAS accessible, ça je l'ai vérifié plus d'une fois. Quelques pistes pour explorer cette solution : La technologie iSCSI sous Linux et Windows Server Le support du protocole iSCSI dans Linux CentOS / Red Hat Linux: Install and manage iSCSI Volume Centos 7 : Installation et configuration d'un initiator et target ISCSI Jacques

Bonjour, Juste une petite remarque au niveau du raid soft/hard. Le gros avantage du raid logiciel est d'être indépendant du matériel... ça parait évident, mais le jour où c'est la carte contrôleur qui lâche, et que celle-ci est un modèle spécifique au fabricant (HP ou autre), il est inutile de vouloir relire les données avec un autre type de contrôleur. Alors qu'en raid soft, n'importe quel OS linux saura reconstruire la grappe raid et accéder aux données (voir la procédure donnée sur le site de Synology pour récupérer ses données via une distribution Ubuntu). En fait, à part la sécurité assurée par la batterie (sur toute carte contrôleur de type professionnel) je trouve (AMHA) que le risque de perdre ses données personnelles suite à la panne de la carte RAID est largement supérieur au risque de manquer une écriture lors d'une coupure de courant. Dans un environnement professionnel, comme j'utilisais des serveurs de la même marque, le raid Hard était privilégié en revanche. Et personnellement, pour l'usage normal d'un NAS, les différences de performances entre le hard et le soft sont sans grand intérêt. Jacques

Bonjour, Ce que tu peux peut-être envisager, c'est d'alimenter tes disques avec l'ancien boîtier et les relier en eSATA ou en SATA (mais dans ce cas, la câble doit être très court et d'excellente qualité au niveau blindage, difficilement compatible avec la présence d'un boîtier externe) à un contrôleur SATA placé dans le NAS. Si la température ne monte pas trop dans le premier boîtier; il serait plus simple de placer les disques dedans, quitte à investir dans du format 2,5" au lieu du 3,5" pour la place. Le reste c'est tout de même tordu. Autre solution envisageable, un linux tournant sur le second PC et permettant d'accéder à ses propres disques en iSCSI depuis le NAS. Mais bon, ça commence à être lourd comme configuration à mon humble avis. Jacques

Bonjour, Typiquement, une VM de test pour Xpenology, inutile de dédier un disque pour faire les tests de compatibilité. Des VM d'OS en test, l'espace disque nécessaire (si on a besoin de plus) pouvant être un montage NFS, sur un autre serveur ou éventuellement sur le NAS Xpenology (attention en ce cas à l'ordre de démarrage des VM est à déclarer les dépendances entre elles éventuellement. Il y a beaucoup de VM sous linux se contenant de très peu d'espace disque. Jacques

Bonjour, En principe, si c'est un des disques qui a hébergé les données, tu as du créer un RAID dessus (RAID 5 ou SHR). En démarrant avec un CD live Linux, type RescueCD ou contenant Gparted, il est possible de faire disparaître les données donnant les informations pour le montage automatique du raid. De mémoire mdadm --zero-superblock /dev/sdX (X étant la lettre identifiant le disque en question). Ensuite, repartitionner le disque avec gparted et le formater ou non, cela pourra être fait sous un autre système si c'est plus facile pour toi. Enfin comme toujours avec les disques durs, vérifier au moins deux fois avant de taper la commande qu'on adresse bien le bon disque ! Jacques

Je n'ai pas testé la mise à niveau, j'ai refait une installation from scratch en DSM6. Donc, je ne sais pas si lors de la mise à jour le compte admin est sollicité à partir de l'authentification du DSM5 ou si c'est une authentification dans la version 6. Le plus simple, ce serait de démarrer le serveur à partir d'un LiveCD (via une clef USB) comme SystemRescueCD (qui possède une interface graphique, mais la dernière version semblait ne pas tenir compte correctement du codage du clavier, et coder un mot de passe en QWERTY, c'est chaud). Une fois le système linux démarré, appliquer la procédure pour accéder aux disques (voir le site de Synology pour les explication dans la restauration des données). Accéder à la partition système (elle contient le répertoire etc) puis accéder à ce répertoire etc. Chez moi (DSM6), la partition système est répartie sur tous les disques et est accessible par le raid md0 (en ext4), il n'y a pas de SHR pour ça, ce qui simplifie l'accès. Un LiveCD devrait monter automatiquement le raid md0 et permettre l'accès aux données. Editer le fichier shadow (il peut être nécessaire de retirer la protection en écriture par la commande chmod 640 shadow avant d'éditer le fichier). Si on le fait avec vi, il est possible d'outrepasser (en root) la protection et de modifier tout de même le fichier sans avoir à changer les droits avant. Dans ce fichier, il y a une ligne qui commence par admin et ressemble à ça : admin:MOT_DE_PASSE_CHIFFRÉ:17512:0:99999:7::1: La chaîne de caractère du mot de passe est longue, et est comprise en les 2 premiers signes ":". Si tu efface le mot de passe et le remplace par ça : $1$BQx9e/$g.fi2H2K.yAPu0LKyK02I1 alors le mot de passe du compte admin sera admin une fois le système redémarré. (En principe, si tu efface le mot de passe entre les 2 ':', il n'y a plus d'authentification en ce cas, mais les règles d'accès au système peuvent poser problème.) Dans le cas où les autorisations d'écriture du fichier shadow ont été modifiées, il faut les remettre par un chmod 440 shadow. Personnellement, c'est ce que je ferai, c'est vrai que je suis à l'aise avec linux, mais ce n'est pas trop compliqué tout de même. Bon courage Jacques

Bonsoir, Pas évident à régler, à moins qu'il n'y ait pas beaucoup de disques dans le NAS. Dans ce cas, il est assez facile de les connecter à un PC et de démarrer celui-ci sous linux, avec un LiveCD par exemple. La méthode pour récupérer les données en cas de crash (sur le site de Synology) permet d'avoir un point de départ pour monter la partition système et accéder ensuite aux fichiers passwd ou shadow pour supprimer la présence de mot de passe. Autrement, est-ce que tout simplement lorsque le mot de passe de remplacement est saisi, celui-ci est-il conforme aux règles de complexité du DSM ? Bon courage, et surtout ne rien faire dans la précipitation dans ce genre de problème. Et une fois le compte admin restauré, en créer un second avec les mêmes droits. Personnellement, j'ai activé SSH et j'ai copié une clée public dans le dossier .ssh de root, ce qui fait que je m'authentifie directement en root sans passer par le mot de passe d'admin, ce qui me permet de le changer en cas d'oubli) Jacques

Ok, merci pour cette réponse. Merci pour l'aide et bonne journée Jacques

Cette procédure permet de créer un datastore directement sur la carte SD supportant VmWare ESXi. Elle a été testée sur un Proliant Gen8 1610T avec VmWare ESXi 6.5 avec une carte SD de 16 Go. En utilisant la carte SD ou la clé USB (la VM Xpenoboot étant démarrée et n'ayant pas d'accès disque, la carte n'est pas sollicitée ensuite), cette méthode évite d'avoir à installer un disque dur supplémentaire pour stocker les fichiers de configuration de la machine virtuelle (moins de 100 Mo suffisent). Les commandes sont données sous Linux, pour ceux qui utilisent Windows, je recommande d'utiliser un LiveCD Linux contenant (impérativement) gdisk afin de retrouver un environnement similaire. On peut récupérer une image ISO avec l'outil directement sur le site gparted.org. 1) Installer VmWare ESXi sur la carte microSD (ou la clé USB), la place prise est de l'ordre de 4 Go seulement. 2) Arrêter le serveur et le redémarrer avec le LiveCD ou si vous utilisez Linux, placer la carte SD dans votre lecteur de carte sur votre PC. 3) Rechercher le nom du périphérique associé à la carte SD (ou la clé USB) : (ici il n'y a que les lignes intéressantes) [root@jacques ~]# dmesg | tail [20710.163993] sd 18:0:0:2: [sdj] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB) [20710.190258] sdj: sdj1 sdj5 sdj6 sdj7 sdj8 sdj9 4) La carte SD (ou la clé) est donc associée au périphérique /dev/sdj dans l'exemple 5) Utiliser gdisk pour modifier la table de partitions (et en faire un backup au cas où...), cette table est au format GPT : Lors de la création de la partition (en fin de disque), j'ai conservé les valeurs proposées par défaut, donc il suffit de faire ENTRÉE pour valider le choix Les commandes sont indiquées dans le menu accessible par la touche "m" et celles utilisées sont : p : affiche le contenu de la table de partitions b : sauvegarde de la table actuelle avant les modifications n : création d'une nouvelle partition (le code abrégé pour VMFS est FB00, le GUID est AA31E02A-400F-11DB-9590-000C2911D1B8) i : affiche les informations sur la partition choisie w : sauvegarde la table GPT et quitte le programme [root@jacques ~]# gdisk /dev/sdj GPT fdisk (gdisk) version 0.8.10 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Command (? for help): p Disk /dev/sdj: 31116288 sectors, 14.8 GiB Logical sector size: 512 bytes Disk identifier (GUID): 1EF374F4-FAB2-472E-B44B-DB42579DF55C Partition table holds up to 128 entries First usable sector is 34, last usable sector is 31116254 Partitions will be aligned on 32-sector boundaries Total free space is 158 sectors (79.0 KiB) Number Start (sector) End (sector) Size Code Name 1 64 8191 4.0 MiB EF00 5 8224 520191 250.0 MiB 0700 6 520224 1032191 250.0 MiB 0700 7 1032224 1257471 110.0 MiB FC00 8 1257504 1843199 286.0 MiB 0700 9 1843200 7086079 2.5 GiB FC00 Command (? for help): b Enter backup filename to save: sdj-gpt.bak The operation has completed successfully. Command (? for help): n Partition number (2-128, default 2): 10 First sector (34-1257503, default = 7086080) or {+-}size{KMGTP}: Last sector (7086080-31116254, default = 31116254) or {+-}size{KMGTP}: Current type is 'Linux filesystem' Hex code or GUID (L to show codes, Enter = 8300): FB00 Changed type of partition to 'VMWare VMFS' Command (? for help): p Disk /dev/sdj: 31116288 sectors, 14.8 GiB Logical sector size: 512 bytes Disk identifier (GUID): 1EF374F4-FAB2-472E-B44B-DB42579DF55C Partition table holds up to 128 entries First usable sector is 34, last usable sector is 31116254 Partitions will be aligned on 32-sector boundaries Total free space is 158 sectors (79.0 KiB) Number Start (sector) End (sector) Size Code Name 1 64 8191 4.0 MiB EF00 5 8224 520191 250.0 MiB 0700 6 520224 1032191 250.0 MiB 0700 7 1032224 1257471 110.0 MiB FC00 8 1257504 1843199 286.0 MiB 0700 9 1843200 7086079 2.5 GiB FC00 10 7086080 31116254 11.5 GiB FB00 Command (? for help): i Partition number (1-10): 10 Partition GUID code: AA31E02A-400F-11DB-9590-000C2911D1B8 (VMWare VMFS) Partition unique GUID: 835EA227-E905-4B14-86BB-DAD6E2AB31A4 First sector: 7086080 (at 3.4 GiB) Last sector: 31116254 (at 14.8 GiB) Partition size: 24030175 sectors (11.5 GiB) Attribute flags: 0000000000000000 Partition name: '' Command (? for help): w Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! Do you want to proceed? (Y/N): Y OK; writing new GUID partition table (GPT) to /dev/sdj. The operation has completed successfully. [root@jacques ~]# 6) Ejecter la carte ou la clé et redémarrer le serveur sur celle-ci, et si ce n'est pas déjà fait autoriser les connexions locales ou SSH à la console : Touche "F2" à l'écran de connexion ESXi puis "Options de dépannage" et "activer ESXi Shell" et/ou "Activer SSH" 7) Se connecter à la console (les exemples ici sont via SSH avec authentification par clé publique/privée) : [jacques@jacques ~]$ ssh root@vmware X11 forwarding request failed on channel 0 The time and date of this login have been sent to the system logs. WARNING: All commands run on the ESXi shell are logged and may be included in support bundles. Do not provide passwords directly on the command line. Most tools can prompt for secrets or accept them from standard input. VMware offers supported, powerful system administration tools. Please see www.vmware.com/go/sysadmintools for details. The ESXi Shell can be disabled by an administrative user. See the vSphere Security documentation for more information. 8) Identifier le nom de la partition créée pour le datastore : [root@vmware:~] cd /dev/disk [root@vmware:/dev/disks] ls -l total 31116176 -rw------- 1 root root 15931539456 Dec 11 19:40 mpx.vmhba32:C0:T0:L0 -rw------- 1 root root 4161536 Dec 11 19:40 mpx.vmhba32:C0:T0:L0:1 -rw------- 1 root root 12303449600 Dec 11 19:40 mpx.vmhba32:C0:T0:L0:10 -rw------- 1 root root 262127616 Dec 11 19:40 mpx.vmhba32:C0:T0:L0:5 -rw------- 1 root root 262127616 Dec 11 19:40 mpx.vmhba32:C0:T0:L0:6 -rw------- 1 root root 115326976 Dec 11 19:40 mpx.vmhba32:C0:T0:L0:7 -rw------- 1 root root 299876352 Dec 11 19:40 mpx.vmhba32:C0:T0:L0:8 -rw------- 1 root root 2684354560 Dec 11 19:40 mpx.vmhba32:C0:T0:L0:9 lrwxrwxrwx 1 root root 20 Dec 11 19:40 vml.0000000000766d68626133323a303a30 -> mpx.vmhba32:C0:T0:L0 lrwxrwxrwx 1 root root 22 Dec 11 19:40 vml.0000000000766d68626133323a303a30:1 -> mpx.vmhba32:C0:T0:L0:1 lrwxrwxrwx 1 root root 23 Dec 11 19:40 vml.0000000000766d68626133323a303a30:10 -> mpx.vmhba32:C0:T0:L0:10 lrwxrwxrwx 1 root root 22 Dec 11 19:40 vml.0000000000766d68626133323a303a30:5 -> mpx.vmhba32:C0:T0:L0:5 lrwxrwxrwx 1 root root 22 Dec 11 19:40 vml.0000000000766d68626133323a303a30:6 -> mpx.vmhba32:C0:T0:L0:6 lrwxrwxrwx 1 root root 22 Dec 11 19:40 vml.0000000000766d68626133323a303a30:7 -> mpx.vmhba32:C0:T0:L0:7 lrwxrwxrwx 1 root root 22 Dec 11 19:40 vml.0000000000766d68626133323a303a30:8 -> mpx.vmhba32:C0:T0:L0:8 lrwxrwxrwx 1 root root 22 Dec 11 19:40 vml.0000000000766d68626133323a303a30:9 -> mpx.vmhba32:C0:T0:L0:9 La partition créée sur la carte était la 10, on la retrouve ici sous le nom "mpx.vmhba32:C0:T0:L0:10" (mpx.vmhba32:C0:T0:L0 est l'identifiant du disque complet) 9) Formater la partition avec l'outil vmkfstools : [root@vmware:/dev/disks] vmkfstools -C vmfs5 -b 1m -S datastore-sd /vmfs/devices/disks/mpx.vmhba32:C0:T0:L0:10 -C : type de système de fichiers (ici version 5) -b : taille des blocs (ici 1 Mo) -S : nom du datastore (ici "datastore-sd") create fs deviceName:'/vmfs/devices/disks/mpx.vmhba32:C0:T0:L0:10', fsShortName:'vmfs5', fsName:'datastore-sd' deviceFullPath:/dev/disks/mpx.vmhba32:C0:T0:L0:10 deviceFile:mpx.vmhba32:C0:T0:L0:10 ATS on device /dev/disks/mpx.vmhba32:C0:T0:L0:10: not supported . Checking if remote hosts are using this device as a valid file system. This may take a few seconds... Creating vmfs5 file system on "mpx.vmhba32:C0:T0:L0:10" with blockSize 1048576 and volume label "datastore-sd". Successfully created new volume: 5a2ee03f-33d3d6c4-a104-d0bf9c465a4c 10) Se déconnecter et redémarrer le serveur, le datastore sera disponible directement sur la carte (ou la clé) et suffit largement pour installer la VM Xpenoboot.

Merci beaucoup pour le lien vers le ramdisk d'IG88. Installation réussie avec les drivers contenus dedans... Sachant que le module tg3 existe dans les deux, la différence doit être dans le firmware de la carte... Il ne reste plus qu'à tout reconfigurer. Bonne journée et merci encore Jacques