Bonjour,
J’ai un problème sur une Debian GNU/Linux 6.0 qui tourne sur un HyperV Microsoft,
J’ai ajouté un VHD de 500go mais Debian le reconnait en 136go,
Avez-vous une solution à me proposer?
Merci d’avance,
Pingu
Tu peut nous donner le resultat de la commande fdisk -l
Je ne sais pas si ça a un lien mais 137 Go (soit 128 Gio) est la capacité maximum adressable avec la première version de LBA (Logical Block Adressing, successeur de l’adressage CHS), sur 28 bits. Pour aller au-delà il faut passer en adressage LBA sur 48 bits. Bien entendu le noyau Linux de Debian gère l’adressage LBA sur 48 bits depuis longtemps.
La sortie de la commande “hdparm -I /dev/sdX” (ou /dev/sdX est le nom de périphérique du disque) pourrait aussi apporter des informations utiles.
Bonjour,
Le résultat de la commande fdisk -l est en PJ de ce poste,
Pour la commande hdparm, elle n’est pas reconnue, manque de package?
Re-Bonjour,
J’ai réussi à ajouter le “hdparm”, voice le résultat,
Merci pour votre aide
[quote=“Pingu59”]Bonjour,
Le résultat de la commande fdisk -l est en PJ de ce poste,
Pour la commande hdparm, elle n’est pas reconnue, manque de package?[/quote]
Tu es sûr de ne pas confondre disque et partition, la première partition est exactement de la taille que tu cites 
Oui c’est bien le disque (VHD : disque virtuel) qui est reconnue en 136go au lieu de 500go
À mon avis, Il te faudrait utiliser l’Assistant Modification de disque dans le Gestionnaire Hyper-V pour convertir le disque dur virtuel dynamique de cette machine virtuelle en un disque dur virtuel taille fixe.
Depuis windows bien sûr.
Re,
[quote=“MicP”]À mon avis, Il te faudrait convertir le disque dur virtuel dynamique de cette machine virtuelle
en un disque dur virtuel taille fixe.
Depuis windows bien sûr.[/quote]
Cela resterait quand même la partition réelle sda1 
Oui, mais il pourrait alors redimensionner la partition sda1 à 494 Go, alors que c’est apparemment pas possible tant que c’est un disque dynamique Hyper-V.
Il n’a pour l’instant qu’un disque (sda) de 139,6Go dispo, et en passant à 500 Go, il lui resterait (depuis un CD live avec gparted par exemple) à:
1/ supprimer le swap (éventuellement récupérer l’UUID pour #5)
2/ supprimer la partition étendue
3/ agrandir sda1 à 494 Gb
4/ recréer le swap (dans une étendue si il veut)
5/ mettre à jour l’UUID de la swap dans le “/etc/fstab” de sda1 (ou alors changer l’UUID de la swap par l’original récupéré en #1)
EDIT:
Une fois la conversion dynamique -> taille fixe efectuée,
je serais curieux de voir ce que retourne la commande
et plus particulièrement la partie qui avait donné (dans le post #5 - 1.png), en disque dynamique, les résultats incohérents suivant:
Configuration:
Logical max current
cylinders 16383 65535
heads 16 16
sectors/track 63 255
C’est marqué dans le fdisk:
Disk /dev/sda: 136,9 GBAu fait, tu devrais essayer de lui donner plus, comme 1.5To.
Qui sais, peut-être qu’en demandant 1.5To, m$ va te donner tes 500G ?
[quote=“MicP”]je serais curieux de voir ce que retourne la commande
hdparm -l /dev/sda[/quote]
Pas d’option -l pour hdparm dans Squeeze.
Ce n’est pas incohérent, c’est juste la géométrie CHS qui est incapable de représenter la capacité des disques actuels. On s’en fiche puisque maintenant on utilise l’adressage LBA.
Désolé, j’avais confondu le caractère “I” avec le caractère “l” en recopiant la commande proposée au post #2.
À l’avenir, je serais plus attentif à la police de caractère qui affiche cette information, ou je ferais des copié/collé (mais c’est pas très pratique à faire avec un touchpad).
J’avais souvenir (il y a 20 ans), alors que j’utilisais encore la fonction 08h de l’INT 13h, que l’adressage en CHS ne pouvait adresser qu’un espace disque de 8Go.
Or, dans ce fil, il est question d’un disque de 139 Go.
Aussi, je m’étonne que hdparm (qui a toujours tenu compte des modes d’adressage CHS, ECHS et LBA) ce soit laissé avoir, et je soupçonne plutôt le système d’exploitation qui a créé ce disque “extensible” de se moquer un petit peu des standards du “Technical Committee T13”.
C’est un peu plus compliqué, cette limite de 8 Go provient de la combinaison des limites de la fonction disque du BIOS et de l’adressage CHS. Pris séparément, leurs limites d’adressage respectives sont beaucoup plus élevées. Bref, inutile de s’étendre sur des mécanismes obsolètes de toute façon.
Je remarque que hdparm -I n’affiche pas de ligne “LBA48 user addressable sectors”, contrairement à ce que je vois chez moi pour un disque physique de plus de 137 Go. Se pourrait-il que le disque virtuel émulé par HyperV ne supporte pas l’adressage LBA sur 48 bits, et donc sa capacité utile ne peut dépasser 137 Go ?
[quote=“PascalHambourg”]… inutile de s’étendre sur des mécanismes obsolètes de toute façon. …[/quote]Entièrement d’accord, et c’est d’ailleurs pour ça que je m’étonnai qu’on puisse expliquer cette incohérence par l’incapacité de l’adressage CHS.
[quote=“PascalHambourg”]… Se pourrait-il que le disque virtuel émulé par HyperV ne supporte pas l’adressage LBA sur 48 bits …[/quote]Ou alors, c’est Hyper-V qui utilise LBA-64 et hdparm qui ne prends pas encore en compte LBA-64, mais l’adressage en mode LBA-64 datant d’environ 15 ans, je doute que “hdparm” n’ai pas été mis à jour en conséquence.
Ou alors la façon dont le système hôte réponds aux commandes SCSI, ou encore, une histoire de ce genre, mais je n’ai jamais utilisé Hyper-V ( on a pas eu le temps de m’y forcer… ), alors je ne sais pas trop.
hello,
cessez de vous prendre la tête 
c’est une histoire de noyau… l’an passé j’ai rencontré le problème sur cette daube d’hyperV… j’avais installé le noyau backport 3.2 pour squeeze et là mon disque de 500 G.o était reconnu. Oui mais voilà encore faut-il avoir une connexion réseau… Alors ce que j’avais fait, c’était une image iso assez consequente : j’avais foutu dans l’iso le miroir des backports pour squeeze et c’est comme ça que j’avais pu faire mon installation. Autrement, on peut toujours ramer ! 
passe à Xen 
clic clic !!! lol
Le plus simple c’est d’installer directement une wheezy qui a tout ce qu’il faut sous le capot… Pourquoi prendre une oldstable ?
MicP : Jamais entendu parler de LBA 64 pour les disques ATA, je ne connais que LBA 28 et 48.
guiguitarux : Je veux bien croire que c’est le noyau, mais le noyau 2.6.32 de Debian 6.0 “Squeeze” supporte LBA 48, donc il doit y avoir autre chose.
[quote=“PascalHambourg”]… Jamais entendu parler de LBA 64 pour les disques ATA …[/quote]Moi non plus d’ailleurs, et c’est d’ailleurs pour palier aux limitations de l’ATA que le SATA a été créé (environ 2003), et [strike]dans le cas de ce disque ("/dev/sda"), il s’agit bien de SATA, si c’était un ATA le descripteur de fichier utilisé dans le dossier “/dev” aurait été “hda”[/strike].
Mais ce pourrait être ça (ATA SATA) la cause du problème:
Linux le voit comme un SATA et Win lui sert un “pseudo presque SATA extensible à la mode Win” qui réponds aux commandes SCSI comme s’il s’agissait d’un disque ATA => 137Go max dispo.
Il faudrait savoir comment les disques “extensibles” HyperV Microsoft répondent aux commandes SCSI leur demandant la taille du disque.
Le SATA ne fait que définir une nouveau transport série pour l’interface ATA, à côté du traditionnel transport parallèle (anciennement “IDE”) rebaptisé depuis PATA (Parallel ATA). Les commandes ATA, et donc le format de l’adressage LBA, restent les mêmes.
Non, pas forcément. Les pilotes PATA et SATA actuels basés sur libata nomment tous les disques sd*, y compris les PATA ex-IDE. Ce sont les anciens pilotes IDE/ATA qui nommaient les disques hd*.
Cela ne concerne que les fonctions d’accès disque du BIOS (dont le noyau Linux se contrefiche), pas l’interface ATA elle-même.
Les citations de mon dernier post indiquaient surtout: "… 64-bit logical block addressing (LBA) …"
C’était juste une information au sujet du LBA-64.
Autant pour moi, j’avais faux au sujet de IDE => /dev/hda, (j’ai barré la ligne dans mon post).
Le “s” de “/dev/sda” indique donc SCSI et pas SATA.