sygirard a écrit 50 commentaires

J'ai une distribution CentOS sur une partition des disques en RAID1

Les disques RAID1 on deux partitions qui forment deux RAID1 :
- la première avec CentOS
- la deuxième avec les datas

Et je veux pouvoir booter dessus si pas le disque solo justement.

Ne trouvant pas de solution à mon problème, j'ai cherché du coté de l'installation de GRUB.

Ta solution ne m'aide pas vraiment vu que je n'ai pas le même système, mais … elle a au moins eu le mérite de m'orienter dans mes recherches.
Vu que je ne trouvais rien pouvant régler mon problème via mdadm.

Les deux disques en RAID1 avec CentOS, sont créés par un script qui fait tout (partition, dépacktage, etc …) via un CentOS live custom, ainsi que l'installation de GRUB (pas grub2, grub tout court)

Je faisais ceci :
root (hd0,0)
setup (hd0)
root (hd1,0)
setup (hd1)

Il faut plutôt faire cela :
device (hd0) /dev/sdb
root (hd0,0)
setup (hd0)
device (hd0) /dev/sdc
root (hd0,0)
setup (hd0)

Ça marche beaucoup mieux ainsi.

Merci

Je suis pas sous debian, mais sous OpenSuse 12.1

J'ai pas update-initramfs. Je comprends qu'il faille le lancer pour qu'il prenne en compte le nouveau mdadm.conf, mais j'ai l'impression que c'est pas le cas pour mon OpenSuse et ma CentOS.

Un de mes problèmes est réglé, par contre le deuxième.

Je récapitule. J'ai de base :
- sda : Linux OpenSuse avec GRUB sur MBR
- sdb et sdc : En RAID1, et Linux CentOS avec GRUB sur MBR des deux disques

Si je laisse mes disques ainsi, si au démarrage du BIOS je choisi de booter sur sdb ou sdc, CentOS démarre et mon RAID1 reste OK

Si j'enlève sda, que je laisse démarrer le BIOS tout seul, mon CentOS démarre, beaucoup plus lentement, et mon RAID1 est KO sur le premier des deux disques.

Pourquoi ?

Supprimer le contenu du fichier /etc/mdadm.conf n'a pas résolu mon problème, par contre j'avais deux disques RAID1 actifs en /dev/md126 et /dev/md127.

Alors j'ai voulu essayer quelque chose. J'ai juste viré la partie UUID de chaque lignes du fichier mdadm.conf, ce qui donne :

ARRAY /dev/md1 metadata=1.0 name=PiRaid:1
ARRAY /dev/md0 metadata=1.2 name=PiRaid:0

Et là, tout va à merveille. Il y a quelque chose que je pige pas. Ça règle mon problème, c'est bien. Mais j'aimerai comprendre.

Enfin bref, je veux pas aller trop vite mais au final, s…perie de UUID.

Alors j'ai suivi ton idée.

Avec ma manip, si je démarre SysRescue avec un seul disk RAID, je vois bien mon RAID1 actif, tout va bien.

Si je démarre mon système avec un disque, il démarre pas, me propose une console. Je me connecte, tape le "cat /proc/mdstat" classique, et là il me met que md0 et md1 ne semble pas actif.

Je vais voir ce que ça donne si je vire les deux lignes du fichier /etc/mdadm.conf

Ouais ben non j'ai rien dis. Je devais pas avoir les yeux bien ouverts.

Avec "tune2fs -l /dev/sdaX" j'ai ce qu'il faut.

Merci

Je sais pas si je dois prendre en compte ce que tu dis, vu que j'utilise la commande suivante pour formater mon système :

mkfs.ext4 -m 0 /dev/sdaX

C'est quoi dans ce cas la méthode de Gparted pour afficher l'espace utilisé dans les partitions de l'ensemble des disques présent sur le PC ?

Il monte, obtient les informations, et démonte les disques ?

Car une fois Gparted lancé, aucun disque n'est monté.

Bon, j'ai réussi à faire afficher du 1920x1080 à mon écran.

Pour cela, j'ai pris un écran identique qui fonctionne, j'ai généré avec nvidia-xconfig un fichier edid (edid.bin).

Ce fichier edid.bin est utilisé dans ma configuration xorg.conf dans la section Device : Option "CustomEDID" "DP-3:/etc/X11/edid.bin"

Ça à l'air de bien fonctionner, mais ça me plait pas vraiment.

Je voudrais vraiment imposer une résolution en 1920x1080 (ou 1680x1050 selon type de machine), EDID ou pas EDID.

Si quelqu'un à une idée de comment je pourrai faire ça ?

Sinon, je me débrouillerai avec deux fichiers edid.bin selon le type de machine et ça ira bien.

Mon problème c'est comme si le driver nvidia n'arrivait pas à récupérer les infos EDID de l'écran.

QUESTION : est-ce que cela peut être dû au driver nvidia lui-même, à Linux ou autre partie soft ?

Par cette question j'essaie juste de m'assurer que le problème ne vient pas de mon installation.

Merci
Sylvain

J'ai testé mon écran avec un PC sous Windows … oui je sais, pas bien.

Et bien mon Windows 7 arrive très bien à s'afficher en résolution max de 19620x1080.

j'ai essayé d'autres distribution live avec cet écran, elles crashent toutes au moment du chargement du driver écran.
Même SystemRescue crashe … c'est que c'est grave.

Quelqu'un pourrait-il me dire ce que vérifie Linux de plus que Windows ? On va partir du principe que linux fait plus de vérification matériel avant de se lancer.

Parce que j'ai tout essayé, du "nomodeset", "nofb" ou autre paramètre noyau, et c'est option xorg aussi :
Option "UseEDID" "False"
Option "UseEDIDFreqs" "False"
Option "ExactModeTimingsDVI" "True"
Option "ModeValidation" "NoDFPNativeResolutionCheck, NoEdidModes, NoMaxPClkCheck, NoVertRefreshCheck, NoHorizSyncCheck, NoEdidMaxPClkCheck"
Option "NoLogo" "True"

Rien ne change

Et puis je pense que ce que je veux faire n'est pas faisable car j'ai une carte graphique avec 2 sorties écrans, et je voudrais un écran avec driver nvidia et l'autre avec framebuffer. Pas possible.

Ben en fait, pour qu'on se comprenne bien, j'ai pas vraiment besoin de faire une pause.

Il faut juste que je sois assuré qu'au moment au j'active le rétroéclairage, l'image soit affichée complétement à l'écran.

Je ne maitrise pas le temps d'ouverture d'une image par le système via une application.

Framebuffer était pour moi une manière de m'assurer que l'image s'affichait très rapidement .. plus rapidement que par application Qt et serveur X traditionnel

C'est à dire ?

La synchronisation verticale de mon écran ? Il faut que j'essaie de la rendre plus rapide ?

Ça ne change rien non plus. Il veut rien savoir …

Je pense que le problème vient de la … que la gestion du DDC ne fonctionne plus sur cet écran.

Je voudrais donc m'affranchir de ce problème

J'y ai pensé aussi. C'est même la première chose que j'ai fais avant d'essayer xrandr … mais ça change rien.

J'ai bien essayé aussi de mettre les modes video dans le fichier /etc/X11/xorg.conf

Mais pas mieux …

Pas un problème de câble … puisque l'écran fonctionnait très bien avant (bon fonctionnement pendant 1 an)

Sauf que le but ici est de proposé une solution rapide qui permette l'utilisation de la machine en attendant un nouvel écran

Bon ça me va.

Merci à toi

Ce qui est le cas. On communique beaucoup entre notre application sur le PC et l'automate.
Ce dernier permet de piloter les parties mécanique de al machine.

Donc est-ce que ma configuration DHCP est propre et suffisante pour éviter tout problème si inversion de cable ?

Si ce n'est pas le cas, faut-il que j'ajoute des règles iptables ? Si oui, pourrais-tu m'aider à trouver la règle qui fera que seul les trames venant de mon automate puissent passer par le port eth1 .. car comme je le disais, j'ai déjà essayé de trouver une règle qui détecte une certaine chaine dans l'entête, mais j'ai l'impression que c'est possible uniquement pour le corps de la trame. Mais j'ai peut-être pas tout compris

Merci pour ton aide

Car c'est la seule méthode préconisée par le constructeur de l'automate.

Qui dit ceci :

1. Each remote install client (Automation Runtime) receives an IP address from the DHCP server
2. In addition, they try to query the B&R-specific parameters from DHCP server
3. If B&R-specific parameters are provided by a DHCP server, the received data is used to try to establish a connection to the remote install server and to read the remote install configuration file. If no connection to the remote install server is possible, then AR boots.
4. The remote install configuration file is evaluated on the remote install client (Automation Runtime), and the version of the BR modules to be installed corresponds to the node number or MAC address. The application and/or the operating system is stored on the remote install client's Compact Flash. The next time it's booted, the installed software will be used.

si le firmware vient regarder en FTP, alors ton DHCP ne te sert à rien sauf à avoir des emmerdes

Tu conseillerais quoi alors comme méthode dans ce cas ?

1°) bind uniquement sur l'interface INTERNE

Tu entends par là que mon serveur DHCP doit être uniquement sur le port Ethernet interne ? Si oui, c'est déjà le cas (eth1 dans fichier /etc/sysconfig/dhcpd)

2°) deny unknow-client;

On est d'accord que cette option se met au même niveau que "default-lease-time 7200;" par exemple ?

3°) jouer de la classe

Ce que j'ai fais.

Je veux juste me garantir comme je te disais que la méthode "pool" dans mon "subnet" est la bonne méthode à appliquer.
Si oui, c'est bon j'ai fini ^{^}

On copie les mises à jour sur le PC dans un répertoire destiné au ftp, mais c'est le firmware qui vient voir à l'acquisition de l'IP s'il a une mise à jour à télécharger et appliquer.
Voir ma classe dans la conf du serveur pour ça.

Je la remet complète ici :

ddns-update-style none;
deny unknow-client;

ignore client-updates;
allow booting;
allow bootp;

class "ma_classe" {
   match if substring (option dhcp-client-identifier, 0, 9) = "\000MON_UID";
   option vendor-encapsulated-options "/NAME=config.xml /ADDRESS=192.168.1.1 /PROTOCOL=ftp";
}

subnet 192.168.1.0 netmask 255.255.255.0 {
   option routers                192.168.1.1;
   option subnet-mask            255.255.255.0;
   option time-offset            -18000;
   option broadcast-address      192.168.1.255;
   pool {
      allow members of "ma_classe";
      range 192.168.1.2;
   }
}

c'est pas un peu sortir le char pour enculer une mouche ?

MDR :-D !!! oui c'est un peu ça.

J'ai déjà deux cartes réseaux sur le PC. Une pour le réseau usine, et une pour le réseau interne à la machine.
Avant on mettait à jour l'automate par clé USB, et j'étais donc dans la configuration que tu me conseilles, c'est à dire une interface en DHCP client, et une autre en IP fixe, et l'automate en IP fixe également.

Donc comme tu vois, j'avais déjà eu cette idée.

Sauf qu'aujourd'hui on a besoin du DHCP pour des mise à jour automatique de version de firmware de l'automate via ftp au moment du démarrage de ce dernier. C'est à dire que lorsqu'il fait sa requête pour une IP, avant de démarrer le soft complétement, il regarde si une mise à jour est disponible et l'applique si c'est le cas.

Voilà pourquoi j'ai un serveur DHCP sur le PC.

Et je cherche seulement à faire en sorte que mon serveur n'impacte pas le réseau usine d'un client si un opérateur inverse les cables réseau dans la machine.

Je me suis mal exprimé.

Pour moi une machine c'est une partie mécanique, la carcasse si tu préfères, un PC avec mon serveur DHCP, et un automate qui recevra l'IP fixe.

Des machines j'en aurai 50, 100 voir plus qui vont partir chez des clients chaque année.

Tu comprends donc que pour une question de maintenance j'ai besoin que cette configuration soit la même sur toutes les machines.

Donc oui j'ai utilisé une class (voir code que j'ai copié au dessus) que je rappelle ici :

class "ma_classe" {
   match if substring (option dhcp-client-identifier, 0, 9) = "\000MON_UID";
   option vendor-encapsulated-options "/NAME=config.xml /ADDRESS=192.168.1.1 /PROTOCOL=ftp";
}

Ma question était surtout sur l'utilisation de mon pool. Est-ce que c'est bon l'utilisation que j'en fait, ou pas ?

Après j'ai vu que pour une seule IP il vaut mieux mettre "range 192.168.1.2;" plutôt que "range 192.168.1.2 192.168.1.2;"

Mise à part ça, je voulais surtout qu'on me dise si ma configuration était perfectible ou non ?

Je note le "deny unknown-clients" que tu m'as donné.