Lettre des dique change(df affiche sda alors que cfdisk sdb)

Support Debian
#1

Bonjour à tous,

j’ai un problème vraiment étrange.

Je suis en train de me monter un serveur perso sur debian.

j’ai 1 disque de 160gb pour le système et 3 disques de 1.5TB pour faire du raid5 logiciel avec mdadm.

Je me suis pris la tête a bien ordonner mes disques sur mes nappes SATA afin que mon disque système soit sda, puis les autres sdb, sdc, et sdd.

Jusque là ok.

je commence donc par faire un coup de cfdisk pour préparer mes disques pour mon raid, je tape donc cfdisk /dev/sdb, et je me rends compte que c’est en fait mon disque système!! (présence de ma partoch système puis ma SWAP)

donc je test un cfdisk /dev/sda, et là je vois que c’est un de mes disques de 1.5TB…(pareil avec fdisk)

pourtant un df -h m’indique bien que mon / est monté sur /dev/sda1…

c’est à rendre fou (j’ai déjà éclater mon système une fois…)

avez vous déjà eu ce genre de problème?
quelle piste pour une solution?

perso je pense à un pb d’un des disque ou à un pb de BIOS…

par avance merci beaucoup.

#2

fdisk ne déraille pas

root est défini à travers /etc/fstab

$ grep sda /etc/fstab

root est aussi défini à travers l’argument fourni au noyau par l’intermédiaire de grub

$ grep -e “root=” /boot/grub/menu.lst

#3

grep sda /etc/fstab

/dev/sda1 / ext3 errors=remount-ro 0 1
/dev/sda2 none swap sw 0 0

grep -e “root=” /boot/grub/grub.cfg (pas de menu.lst)

grep -Re “root=” /boot/*
/boot/grub/grub.cfg:set root=(hd0,1)
/boot/grub/grub.cfg: set root=(hd0,1)
/boot/grub/grub.cfg: linux /boot/vmlinuz-2.6.26-2-amd64 root=UUID=34648f23-9c88-4ce3-a4f5-28f625af458a ro
/boot/grub/grub.cfg: set root=(hd0,1)
/boot/grub/grub.cfg: linux /boot/vmlinuz-2.6.26-2-amd64 root=UUID=34648f23-9c88-4ce3-a4f5-28f625af458a ro single

#4

Affaire classée

Au démarrage la bonne racine est trouvée grâce à l’UUID

root=UUID=34648f23-9c88-4ce3-a4f5-28f625af458a

et lorsque tu appelles $ df
la racine est celle définie en /etc/fstab
autrement dit

/dev/sda1 / ext3 errors=remount-ro 0 1

edit : affaire élucidée mais pas vraiment bouclée …
Pour faire concorder grub et /etc/fstab édite ce dernier en définissant la racine selon l’UUID

/dev/sda1 / ext3 errors=remount-ro 0 1

à changer en

UUID=34648f23-9c88-4ce3-a4f5-28f625af458a / ext3 errors=remount-ro 0 1

#5

Salut,

Explication :

J’en ai déduit qu’il commence sa dénomination (a, b, c, d) en fonction de leur position MAIS avant tout de leur technologie.

Ainsi, j’ai un vieux Zip en ide et c’est lui qui se nomme sda :slightly_smiling: alors qu’il est slave sur la même nappe que le graveur de dvd :slightly_smiling:

#6

@etxeberrizahar : merci ta solution marche bien now df et fdisk concordent.

@ggoodluck47 : oui mais dans mon cas ils sont tous SATA. Et les 3 1.5TB sont même modèle/techno/série alors pourquoi un seul disque aurait pris la lettre “a” et les autres n’ont pas bougé…

#7

Re,

Regardes de près les numéros des ports sata sur lesquels ils sont respectivement branchés. Cela pourrait peut-être nous apporter un début d’explication qui nous permettrait de définir la règle.
Car en informatique le plus dur à reproduire c’est le vrai hasard :slightly_smiling:

#8

La dénomination /dev/sd[abcdef] respecte un ordre lié à l’électronique.
L’ordre “réel” peut toutefois être chamboulé durablement ou temporairement par le BIOS ou des chargeurs d’amorces
évolués et nul n’est à l’abri de l’erreur humaine.

Si /dev/sdb est second comment se fait-il qu’il l’emporte sur /dev/sda qui est censé ne pas être démarrable ?
Parce que /dev/sdb est prévu en seconde position dans l’ordre des préférences du boot dans le BIOS ?

Hypothèse : grub est installé sur /dev/sda (celui du simple stockage).
Test rapide : débrancher /dev/sda

Test sans rien débrancher
copie du secteur d’amorçage

dd of=/dev/sda of=mbr-sda bs=512 count=1

dd of=/dev/sdb of=mbr-sdb bs=512 count=1

Caractérisation

file mbr-sda

file mbr-sdb

( grub apparait sous la forme “GRand Unified Bootloader”)