Voici le probleme.
J'ai installe une etch 4.0r1 (2.6.18) sur un pc SuperMicro PDSME+ (chipset Intel 3010 / ICH7R) equipee d'une carte 3ware sata pour le RAID 1:
03:01.0 RAID bus controller: 3ware Inc 7xxx/8xxx-series PATA/SATA-RAID (rev 01)
La carte equipe de deux disque SATA configures en array RAID 1 et est correctement detectee:
scsi0 : 3ware Storage Controller
3w-xxxx: scsi0: Found a 3ware Storage Controller at 0x4000, IRQ: 58.
Vendor: 3ware Model: Logical Disk 0 Rev: 1.2
Type: Direct-Access ANSI SCSI revision: 00
(cut)
SCSI device sda: 156299440 512-byte hdwr sectors (80025 MB)
sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: Attached scsi disk sda
Notez par ailleurs la detection du lecteur dvd/graveur cdrw branche en PATA sur l'ICH7 (important pour la suite):
ICH7: IDE controller at PCI slot 0000:00:1f.1
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 74
ICH7: chipset revision 1
ICH7: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x30a0-0x30a7, BIOS settings: hda:pio, hdb:DMA
ide1: BM-DMA at 0x30a8-0x30af, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hdb: Slimtype COMBO SSC-2485K, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdb: ATAPI 24X DVD-ROM CD-R/RW drive, 1536kB Cache, UDMA(33)
Aucun soucis (enfin si mais c'est pas l'objet) jusqu'a ce que je rajoute un disque sata sur l'ICH7: l'array RAID de la 3ware est devenue /dev/sdb et le disque SATA sur l'ICH7 /dev/sda.
O_O
Passee l'incredulite du concept et la sensation d'etre revenu a MSDOS (qui decalait les lettres quand on rajoutait un disque), j'ai fais plusieurs tests et je me suis rendu compte que l'affectation etait totalement aleatoire:
Choix 1 (good):
/dev/sda = RAID 1 3ware
/dev/sdb = SATA sur ICH7
Quand j'ai du bol, ca donne ca:
ata_piix 0000:00:1f.2: version 2.00
ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ]
ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x30B0 irq 14
scsi1 : ata_piix
e1000: 0000:04:04.0: e1000_probe: (PCI-X:133MHz:64-bit) 00:0e:0c:db:26:50
ata1.00: ATA-7, max UDMA/133, 156301488 sectors: LBA48 NCQ (depth 0/32)
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/133
Vendor: ATA Model: ST380811AS Rev: 3.AA
Type: Direct-Access ANSI SCSI revision: 05
sdb: sdb1 < sdb5 >
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x30B8 irq 15
scsi2 : ata_piix
ata2.01: ATAPI, max UDMA/33
ata2.01: configured for UDMA/33
Vendor: Slimtype Model: COMBO SSC-2485K Rev: 5K06
Type: CD-ROM ANSI SCSI revision: 05
On notera aussi le gag du cdrom qui passe de hdc a scd0, mais on va attribuer ca a un fonctionnement etrange de l'ICH7
Choix 2 (bad):
/dev/sdb = RAID 1 3ware
/dev/sda = SATA sur ICH7
Une chance sur deux de demarrer la machine. Mais mais... WTF???
Et c'est vrai que depuis mes debuts sous linux, l'affectation des unites etait liee a la position du driver dans le noyau (ou dans les modules) mais j'ai jamais eu le cas de l'affectation aleatoire... D'ou un certain enervement concernant cette gestion etrange de la gestion des unites.
Me voila parti a la recherche d'une solution. Pour pas mal de drivers, on peut passer des parametres au noyau pour forcer les choses, donc j'ai cherche s'il etait possible d'avoir quelque chose comme (dans grub):
kernel /boot/vmlinuz-2.6.18-3-486 root=/dev/sda1 ro 3w-xxxx=sda
Evidement ca ne fonctionne pas et en regardant de plus pres, je me suis souvenu que ca ne marchait qu'avec le noyau et pas les modules... avec l'incertitude d'une quelconque possibilite de fonctionnement puisque je n'ai pas trouve l'option dans la doc du noyau (kernel-parameters.txt dans Documentations du noyau linux)
Pour ce genre de probleme (y a longtemps), je passais par une recompilation du noyau avec le driver que je veux en numero 1 en natif dans le noyau et le reste en module. Seulement, a l'heure actuelle, je trouve ca desagrable car on perd completement l'interet du noyau "standard distribution", a savoir l'integralite des modules dispo et une flexibilite a toute epreuve. Et je ne parle meme pas de la facilite de mise a jour. Bref c'est une solution desagreable donc c'est rejete.
en fouillageant le web, j'ai trouve ca:
http://www.nslu2-linux.org/wiki/HowTo/MountDisksByLabel
Si ca peut etre rigolo pour des cles usb, voir la machine fonctionner un coup sur sda et un coup sur sdb, je trouve ca particulierement crado meme si, a priori, c'est aussi une solution valable (l'auteur emets des doute sur le fonctionnement du label avec grub, ceci dit)
Et la je n'ai pas de solution ellegante.
D'ou ma question: est il possible de forcer sda sur l'unite de la carte RAID 3ware tout en gardant le noyau binaire de la distribution?
Merci d'avance.
# au hasard...
Posté par NeoX . Évalué à 1.
dans l'autre c'est un reboot "à chaud" et ca donne l'autre resultat ?
sinon l'option du "mount disk by label" est celle proposée desormais par beaucoup de distrib pour permettre justement une certaine flexibilité...
[^] # Re: au hasard...
Posté par Guillaume Estival . Évalué à 1.
Pour le disk label, c'est moche (car les devices seront aleatoires) mais si tu me dis que ca marche jure crache avec grub, pourquoi pas.
[^] # Re: au hasard...
Posté par NeoX . Évalué à 1.
ensuite le grub il va chercher cet ID plutot que le /dev/sdX qui lui n'arrete pas de changer.
je ne peux pas jurer, car au contraire je l'ai viré de mon fstab et de mon grub,
mais si certaines distrib ont adopté ce systeme de disklabel, c'est que ca doit le faire non ?
[^] # Re: au hasard...
Posté par totof2000 . Évalué à 2.
# udev ?
Posté par djibb (site web personnel) . Évalué à 2.
(ça tombe bien il me semble que c'était le 2.6.18 ;) )
si tu peux le mettre à jour (2.6.20 etc.) ça peut faire ton affaire.
[^] # Re: udev ?
Posté par NeoX . Évalué à 1.
il me semble que si on lit bien son message, c'est justement l'inverse qui se passe.
que rien n'est fixé, que ca change de maniere aleatoire.
ou au contraire, et je m'excuse si j'ai mal compris,
tu lui recommandais de jouer avec Udev pour fixer les rules et ne plus avoir ces problemes aleatoires ?
[^] # Re: udev ?
Posté par djibb (site web personnel) . Évalué à 2.
[^] # Re: udev ?
Posté par Guillaume Estival . Évalué à 1.
Du coup, ca marche bien pour forcer eth0=realtek et eth1=intel mais ca servira a rien pour les controlleurs disque.
Enfin, j'ai dis que je voulais le noyau standard (binaire) de la distrib, c'est pas pour mettre un vanilla que je compilerais moi meme...
LW
[^] # Re: udev ?
Posté par djibb (site web personnel) . Évalué à 2.
-> http://backports.org/debian/pool/main/l/linux-2.6/linux-imag(...)
[^] # Re: udev ?
Posté par Guillaume Estival . Évalué à 1.
Je note et je testerais, merci bien :)
# pas de souci
Posté par solsTiCe (site web personnel) . Évalué à 2.
LABEL=swap swap swap defaults 0 0
LABEL=arch / ext3 defaults 0 1
LABEL=home /home reiserfs defaults 0 2
ici le label c'est le label sur le fs.
ou alors c'est un bug avec le grub de debian ;-)
y'a que pour les partoch ntfs que j'utilise /dev/disk/by-label/Systeme parce que ntfs-3g supporte pas le label tout court.
donc ca donne:
/dev/disk/by-label/Systeme /mnt/windows ntfs-3g auto,locale=fr_FR.utf8,fmask=133,dmask=022 0 0
c'est pas plus crade qu'autre chose comme solution.
c'est juste nouveau et différent.
et ça le changement personne n'aime ;-)
[^] # Re: pas de souci
Posté par solsTiCe (site web personnel) . Évalué à 1.
avec le dernier ntfs-3g 1.913(et peut-être djà avant ?), on peut utiliser le label du volume ntfs, en tout cas ca marche maintenant chez moi:
dans le fstab, j'ai mis:
LABEL=Systeme /mnt/windows ntfs-3g auto,locale=fr_FR.utf8,fmask=133,dmask=022 0 0
[^] # Re: pas de souci
Posté par Guillaume Estival . Évalué à 1.
Le soucis, c'est que l'une des raisons qui m'a fait choisir linux, c'etait justement que le systeme attribuait toujours la meme device a un disque donnee, ie primary master=hda, au contraire de DOS ou Windows 9X qui decalait les lettres lors de l'ajout d'un disque.
Et le comportement actuel de linux, avec cette affectation aleatoire, je trouve ca pire que DOS ou Win de l'epoque.
Merci pour les tips anyway.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.