Grégoire COUTANT a écrit :
Re,
Bonjour,
Le 13/06/2014 12:57, daniel huhardeaux a écrit :
Si le BIOS est à jour, que les paramètres de celui ci sont conformes à
la configuration, un appel au support Gigabyte me parait une bonne
initiative.
Déjà tenté il y a deux semaines, ils m'ont répondu qu'ils n'affichent
pas linux en support donc ne répondront pas :-(
Tu peux aussi chercher sur le net s'il existe des retours de ces
machines avec Debian.
Idem, pas trouvé.
Ca parait bête, mais je creuse vraiment sur le net pour chercher avant
d'appeler à l'aide sur la ml :-)
J'aborde la question différemment, je maitrise mal tout ce qui est boot
d'une manière générale, mais où sont défini les noms des disques lors du
boot ?
Contrairement à un BSD où on peut demander gentiment au noyau de
conserver un ordre en fonction des contrôleur, Linux le gère au petit
bonheur la chance en fonction de l'ordre d'insertion des modules ou du
temps de réponse des différents contrôleurs. J'ai un souvenir ému d'un
serveur Sun/Sparc qui s'est mis à ne plus rebooter après une mise à jour
du noyau parce que le timeout sur le reset d'un contrôleur SCSI avait
changé et qu'ainsi, l'ordre des disques entre le U320 et le SAS avait
été inversé.
mdadm et fstab s'en tirent normalement avec un truc assez dégueulasse,
les UUID (voire les labels). Exemple avec l'un de mes serveurs (raid1
sauf pour home en raid6) :
rayleigh:[~] > cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
LABEL=root / ext3 errors=remount-ro 0 1
LABEL=boot /boot ext3 defaults 0 2
LABEL=usr /usr ext3 defaults 0 2
LABEL=local /usr/local ext3 defaults 0 2
LABEL=opt /opt ext3 defaults 0 2
LABEL=var /var ext3 defaults 0 2
LABEL=home /export/home ext4 defaults 0 4
LABEL=swap none swap sw 0 0
rayleigh:[~] > cat /etc/mdadm/mdadm.conf
...
ARRAY /dev/md/7 metadata=1.2 UUID=f22435dc:ac391915:df97fe67:2fb3a4d7
name=rayleigh:7
ARRAY /dev/md/8 metadata=1.2 UUID=4d2cfb3d:9de95777:5b19f126:5c88f571
name=rayleigh:8
ARRAY /dev/md/9 metadata=1.2 UUID=ed49a2d2:50a7e42c:a00ef705:0c328631
name=rayleigh:9
ARRAY /dev/md/10 metadata=1.2 UUID=f03255f5:66a34f36:1223b4ed:1a589457
name=rayleigh:10
ARRAY /dev/md/11 metadata=1.2 UUID=5375295c:23c73b21:41955ed9:aaecd8af
name=rayleigh:11
ARRAY /dev/md/12 metadata=1.2 UUID=2ae6545d:f2c4d713:1bdae8f1:42a9eba5
name=rayleigh:12
ARRAY /dev/md/13 metadata=1.2 UUID=484d82b3:15daae00:bb629b5c:a9112265
name=rayleigh:13
ARRAY /dev/md/14 metadata=1.2 UUID=a3616535:445ab7c7:163f5c50:d641a2b0
name=rayleigh:14
Les numéros d'ID sont haut parce que j'ai dû changer les volumes raid à
la suite d'une série défectueuse de disques Seagate (qui a dit que
c'était normal ?).
Ça nous donne ceci :
rayleigh:[~] > df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/md9 16G 3,3G 12G 22% /
udev 10M 0 10M 0% /dev
tmpfs 397M 2,1M 395M 1% /run
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 3,2G 0 3,2G 0% /run/shm
/dev/md7 991M 78M 863M 9% /boot
/dev/md10 158G 13G 137G 9% /usr
/dev/md11 158G 5,5G 144G 4% /usr/local
/dev/md13 416G 5,1G 390G 2% /opt
/dev/md12 158G 3,6G 146G 3% /var
/dev/md14 1,8T 266G 1,5T 16% /export/home
none 4,0K 0 4,0K 0% /sys/fs/cgroup
Tu remarqueras qu'il n'y a plus aucune référence de numéro d'ID de
disque.
Déjà si les disques conservait leur nommage, je pourrai ensuite
chercher comment dire à mdadm de prendre tel ou tel partition pour
constituer le raid.
Surtout pas. On n'est pas sous BSD, Solaris ou autre OS qui utilisent
des devices différents en fonction des contrôleurs. Linux utilise
/dev/sd* pour la majorité des disques (et /dev/eth* pour le réseau
ethernet, ce qui est un autre gag).
Il restera la question de l'ordre lors du boot,
c'est ennuyeux que les disques sata se montent en premier, puis le raid,
puis ensuite les disques scsi.
Ne compte pas dessus, d'un noyau à un autre, ça peut changer. J'avais
mis en oeuvre il y a longtemps un système consistant à compiler en dur
le support du rootfs dans le noyau (y compris avec le contrôleur de
disque) et en chargeant les modules après. Mais ça oblige à recompiler
le noyau à chaque mise à jour.
Pour info, ce serveur fonctionne plutôt bien à part ça, il sert à faire
de l'intégration continue + samba + versionning. Par contre si le raid
se casse, c'est risqué !
Juste une remarque : il vaut mieux utiliser un raid6 qu'un raid10 avec
quatre disques. Un raid6 protège la perte de deux disques. Un raid10,
d'un disque et, au second disque qui part en vrille, tu as 50% de chance
de tout perdre.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/539afd60.4090...@systella.fr
