> comment un OS (XP) peut il interagire avec un noyeau ... alors qu aucun des deux n est concerne par l autre ?
Je suis d'une patience... Je m'impressionne.
Sur la table de partition il y a la géometrie du disque dure (C/H/S) (pour des raisons historiques). Windows peut utiliser LBA. Windows (son loader) utilisera ce qui est proposé par le BIOS et la geometrie C/H/S retournée par le BIOS si le BIOS n'est pas configuré pour utiliser LBA. Si le BIOS retourne le mode LBA, Windows marche sans problème et ignore les valeurs C/H/S.
L'un des problèmes est la façon dont le BIOS fixe les valeurs C/H/S qu'il va renvoyer à Windows lorsqu'il va lui demander. Normalement on peut penser que le BIOS n'interprète jamais ce qu'il y a sur le disque dure et qu'il doit se limite à l'exécution des 512 premiers octets.
Ben non. S'il voit que les valeurs C/H/S retournées par le disque lui-même et par la table de partition sont différentes il prend les valeurs C/H/S qu'il a trouvé sur la table de partitions. Pourquoi ? Peut-être se dit-il que si les valeurs sont différentes sur la table de partition c'est qu'il y a une bonne raison (il faut savoir que ces valeurs pour les disques moderne sont "virtuelles" donc il n'y a pas de raison de refuser d'autres valeurs du moment que le nombre de secteur total est respecté).
De plus, et c'est là que ça devient "grave", certains BIOS sont "buggés" et si le mode "LBA" est demandé explicitement dans le setting par l'utilisateur, le BIOS continue d'utiliser le mode C/H/S s'il n'y a pas concordance entre les valeurs C/H/S du disque et de la table de partition. Dans ce cas Windows utilisera tout le temps C/H/S alors que LBA ne pose pas de problème. Sans réécrire la table de partition (par exemple avec sfdisk) on ne peut se sortir de ce "merdier".
Pourquoi ça ne plante que sous Windows ? Bon là je suis moins sûre. Ce qui se passe c'est que le loader vérifie les valeurs C/H/S sur la table de partition avec des valeurs stockées sur le FS (NTFS) et le BIOS. S'il n'y a pas concordance alors ça plante.
Pourquoi GNU/Linux stocke des "conneries" ?
Avant, avec Linux 2.4, Linux demandait au BIOS les valeurs C/H/S. Avec Linux 2.6 le noyau ne demande rien au BIOS et "devine" les valeurs C/H/S (il y a CONFIG_EDD depuis peu de temps dans le 2.6 pour "attaquer" directement le BIOS). Sur le papier ce n'est pas un problème puisque ce sont des valeurs "virtuelles". Malheureusement elles peuvent ne pas coller avec les valeurs que le BIOS a précédamment retournées à Windows lors du formatage de NTFS par exemple.
Lorsque parted écrit la table de partition il écrit les valeurs C/H/S que linux 2.6 lui a retourné qui parfois sont fausses. Cette erreur est retournée à windows par la table des partitions et parfois par le BIOS aussi.
Bon, maintenant il reste un problème. Pourquoi parted écrit toujours les valeurs C/H/S sur la table de partition si elles sont déjà là ? C'est un bug.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par 007 . En réponse au journal Dual boot WinXP/Linux 2.6. Évalué à 5.
Je suis d'une patience... Je m'impressionne.
Sur la table de partition il y a la géometrie du disque dure (C/H/S) (pour des raisons historiques). Windows peut utiliser LBA. Windows (son loader) utilisera ce qui est proposé par le BIOS et la geometrie C/H/S retournée par le BIOS si le BIOS n'est pas configuré pour utiliser LBA. Si le BIOS retourne le mode LBA, Windows marche sans problème et ignore les valeurs C/H/S.
L'un des problèmes est la façon dont le BIOS fixe les valeurs C/H/S qu'il va renvoyer à Windows lorsqu'il va lui demander. Normalement on peut penser que le BIOS n'interprète jamais ce qu'il y a sur le disque dure et qu'il doit se limite à l'exécution des 512 premiers octets.
Ben non. S'il voit que les valeurs C/H/S retournées par le disque lui-même et par la table de partition sont différentes il prend les valeurs C/H/S qu'il a trouvé sur la table de partitions. Pourquoi ? Peut-être se dit-il que si les valeurs sont différentes sur la table de partition c'est qu'il y a une bonne raison (il faut savoir que ces valeurs pour les disques moderne sont "virtuelles" donc il n'y a pas de raison de refuser d'autres valeurs du moment que le nombre de secteur total est respecté).
De plus, et c'est là que ça devient "grave", certains BIOS sont "buggés" et si le mode "LBA" est demandé explicitement dans le setting par l'utilisateur, le BIOS continue d'utiliser le mode C/H/S s'il n'y a pas concordance entre les valeurs C/H/S du disque et de la table de partition. Dans ce cas Windows utilisera tout le temps C/H/S alors que LBA ne pose pas de problème. Sans réécrire la table de partition (par exemple avec sfdisk) on ne peut se sortir de ce "merdier".
Pourquoi ça ne plante que sous Windows ? Bon là je suis moins sûre. Ce qui se passe c'est que le loader vérifie les valeurs C/H/S sur la table de partition avec des valeurs stockées sur le FS (NTFS) et le BIOS. S'il n'y a pas concordance alors ça plante.
Pourquoi GNU/Linux stocke des "conneries" ?
Avant, avec Linux 2.4, Linux demandait au BIOS les valeurs C/H/S. Avec Linux 2.6 le noyau ne demande rien au BIOS et "devine" les valeurs C/H/S (il y a CONFIG_EDD depuis peu de temps dans le 2.6 pour "attaquer" directement le BIOS). Sur le papier ce n'est pas un problème puisque ce sont des valeurs "virtuelles". Malheureusement elles peuvent ne pas coller avec les valeurs que le BIOS a précédamment retournées à Windows lors du formatage de NTFS par exemple.
Lorsque parted écrit la table de partition il écrit les valeurs C/H/S que linux 2.6 lui a retourné qui parfois sont fausses. Cette erreur est retournée à windows par la table des partitions et parfois par le BIOS aussi.
Bon, maintenant il reste un problème. Pourquoi parted écrit toujours les valeurs C/H/S sur la table de partition si elles sont déjà là ? C'est un bug.
La situation est très complexe.