Il se peut que le disque ait été partitionné avec Windows. Dans ce cas il peut aussi utiliser les valeurs C/H/S pour la table de partition. En fait les valeur C/H/S et LBA sont toutes les deux stockées.
Avec le noyau 2.6 il y a un bug (pas vraiment un bug mais faisons comme si) et il ne retourne pas les bonnes valeurs C/H/S (c-à-d différente avec ce qui est écrit sur le disque (et pas le bios du disque qui est retourné par hdparm)).
Bref, parfois ça fout le bordel et la situation est très compliquée à comprendre. D'ailleur pour m'y être intéressé j'ai même déjà un peu oublié :-)
Si tu n'as pas de données sur le disque, écrase la table de partition et le mbr de façon brutale :
$ dd if=/dev/zero of=/dev/hdf bs=1k count=32
Puis refais ta table de partition (mais pas sous Windows !).
Normalement ça doit rouler sans problème. Il n'y aura que les valeurs LBA de stockées et les valeurs C/H/S ne seront jamais utilisées. Pour les C/H/S de fdisk qui sont différents de hdparm, tu peux les ignorer (mais elle doivent correspondre à la taille du disque). Elles sont "virtuelles".
# Re:
Posté par 007 . En réponse au message Problème de C/H/S. Évalué à 3.
Avec le noyau 2.6 il y a un bug (pas vraiment un bug mais faisons comme si) et il ne retourne pas les bonnes valeurs C/H/S (c-à-d différente avec ce qui est écrit sur le disque (et pas le bios du disque qui est retourné par hdparm)).
Bref, parfois ça fout le bordel et la situation est très compliquée à comprendre. D'ailleur pour m'y être intéressé j'ai même déjà un peu oublié :-)
Si tu n'as pas de données sur le disque, écrase la table de partition et le mbr de façon brutale :
$ dd if=/dev/zero of=/dev/hdf bs=1k count=32
Puis refais ta table de partition (mais pas sous Windows !).
Normalement ça doit rouler sans problème. Il n'y aura que les valeurs LBA de stockées et les valeurs C/H/S ne seront jamais utilisées. Pour les C/H/S de fdisk qui sont différents de hdparm, tu peux les ignorer (mais elle doivent correspondre à la taille du disque). Elles sont "virtuelles".