Pour parer à des intuitions hâtives, Ami lecteur, Amie lectrice, je te mets en garde : Je suis au courant que les premiers chipset gérant nativement le sATA posent des problèmes divers avec les chipsat Via (notamment le mien : le KT880 avec southbridge VT 8237 ) ; je sais également que les disque durs SATA-II ont souvent des problèmes avec les contrôleurs SATA anciens (c'est aussi mon cas).
Mais en l'occurence :
1°) j'essaie d'installer la 10.3 qui embarque un noyau 2.6.22.5 suffisament récent pour ne pas poser de problème du driver sata_via et qui est réputé efficient (hum hum). Je fais bien la différence entre le sata_via pour les "vieux" chipset et pas ahci qui s'adressent à des "jeunes" générations de puces : http://linux-ata.org/driver-status.html#via
2°) j'ai fait la manipulation requise au niveau des cavaliers à l'arrière de mon DD ( Seagate 7200.10 de 320 Go) pour qu'il communique à un taux compatible avec un contrôleur 1ère génération donc il ne devrait pas y avoir de problème. Il ne devrait pas...
Bref, ce postage fait suite à ce précédent coup d'agacement :
https://linuxfr.org/~yojik77/25329.html
J'avais pris mon mal en patience, attendant le 10.3 "pour voir" et cela n'a servi à rien...
Mes problèmres _hèlas_ sont un peu plus curieux...
Pour le dire en 2 mots : je peux partitionner, formater et monter des partitions sur mon disque SATA depuis mon "antique" sarge et un noyau 2.4 (très exactement : 2.4.27-3-k7).
La preuve en image sous sarge :
Root-en-Rut:/home/yoj77# fdisk -l /dev/sda
Disk /dev/sda: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 499 4008186 83 Linux
/dev/sda2 500 873 3004155 82 Linux swap / Solaris
/dev/sda3 874 2243 11004525 83 Linux
/dev/sda4 2244 38913 294551775 5 Extended
/dev/sda5 2244 3738 12008556 83 Linux
/dev/sda6 3739 4984 10008463+ 83 Linux
/dev/sda7 4985 5732 6008278+ 83 Linux
/dev/sda8 5733 38913 266526351 83 Linux
Mais par contre rien à faire avec des distributions embarquant des 2.6 récents...
Ainsi, et c'est un gros mais, impossible pour le partitionneur d'OpenSuse 10.3 de détecter ce disque : il met beaucoup *beaucoup* de temps pour charger le module sata_via et le disque SATA (j'en ai deux autres) ne m'est pas proposé quand je souhaite procéder à un partitionnement expert (le fait de l'avoir partitionné et formaté depuis sarge n'y a rien changé...).
Pas de jaloux : Ubuntu 7.10 et Etch r1 calent également sur cette histoire de détection SATA...
Ubuntu me lâche quelquechose comme ça avant de renoncer :
ata1.00 : failed to set xfermode (err_mask=0x40) [je cite de mémoire]
Du coup, Sarge joue les modestes mais se marre très fort intérieurement....
La vérité me semble simple : mon disque SATA est bien détecté (je n'ai pas fait de test de performance) sous sarge 2.4 qui semble le considérer comme un disque SCSI (/dev/sda ci dessus) ou alors le nomme en sdx tout en le traitant comme un PATA. Bref aussi incroyable que cela puisse sembler, cela fonctionne aux petits oignons !!
Actuellement sous sarge 2.4, ces modules là sont chargés :
Root-en-Rut:/home/yoj77# lsmod | grep ata
sata_via 2488 0 (unused)
libata 26084 0 [sata_via]
scsi_mod 94564 3 [usb-storage microtek hpusbscsi sata_via libata ide-scsi sr_mod sbp2]
J'ai souvent dit des choses abominables, en pensée et en action, sur la série de noyal 2.6.x , il y a donc deux façon de voir ma situation actuelle 1°) justice kerneline immanente 2°) confirmation de mes récriminations, cette branche est un bateau ivre...
Pour en venir aux solutions, hormis le changement de toute ma configuration opu le recours à une carte SATA bootable (cher, chiant et laquelle d'abord ?), j'aimerais savoir s'il est possible de forcer la détection de ce disque comme un PATA ou comme un SCSI par l'installateur 10.3 ?
Si quelqu'un saurait comment faire cela (brokenmodules=sata_via ?).
Merci à vous & bonne nuit tous toutes,
Yojik
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.