Journal Dual boot WinXP/Linux 2.6

Posté par  .
Étiquettes :
0
26
mai
2004
C'est un mail qui indique comment corriger le problème de non boote de windows XP après l'installation d'une distribution avec Linux 2.6 :
http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00908.(...)

C'est de la mailing Fedora mais ce problème touche TOUTES les distributions avec Linux 2.6.
Les solutions proposées marchent avec les autres distributions (notamment Mandrake 10.0 et SuSE 9.1).

Notons que quelques très vieux disques dures ont besoin de "sfdisk --no-reread -H240 /dev/hd?"
  • # En seconde par défaut, svp

    Posté par  . Évalué à -7.

    Vous pourriez pas mettre les journaux en seconde page par défaut ?
    J'ai encore oublié c'est "putain" de case à décocher.
  • # c'est ennuyeux...

    Posté par  . Évalué à -4.

    Et quand on a pas de windows, on peut pas installer redhat alors ?
  • # Hein ?

    Posté par  . Évalué à -3.

    Ben moi j'ai jamais eu ce blem avec ma gentoo ...
    • [^] # Et alors ?

      Posté par  . Évalué à 3.

      Il y a plein de monde en dual boot Windows XP/Mandrake|SuSE[FC2 qui n'ont pas de problème.
      C'est pour les quelques BIOS qui ne permettent pas de forcer le mode LBA.
    • [^] # Re: Hein ?

      Posté par  . Évalué à 1.

      je l'ai pas non plus avec mes debians... :)
      • [^] # Re: Hein ?

        Posté par  . Évalué à 3.

        OUAIS !!!!!!!!!
        Je l'ai pas non plus avec Fedora !! (normal, j'ai pas windows).
        Youpi !

        Qui d'autre ?

        Faudrait peut-être comprendre le problème avant de poster des [beep] comme ça.

        Si tu as une Debian (ou n'importe quoi d'autre) avec Linux 2.6 + Parted + un dual boot avec win XP et/ou une partition NTFS + un bios pourri + une table de partition écrite en C/H/S alors tu as aussi le bug.

        Par contre il est (selon moi) important de communiquer sur ce bug même s'il est rare. En effet, quelques personnes ont refait une installation à partir de zéro en perdant toute leurs données car elles croyaient que "c'était foutu". Pire ! J'ai déjà vu des gens proposer "dd if=/dev/zero of=/dev/hda" pour résoudre ce problème (c'est vrai que ça marche mais c'est brutal).

        Enfin, c'est un bug qui est invisible pour ceux qui n'ont pas du Windows. Ce "bug" n'a aucun impacte sur Linux. D'où le fait qu'aucun développeur Linux ne l'ait eu et qu'il est passé un peu inaperçu.

        Ceux qui ont installé une Debian avec Linux 2.2 ou 2.4 durant l'installation devrait faire "profile bas" au lieu de rayer leur "petits" camarades. Si la prochaine Sarge avec Linux 2.6 marche sans soucis se sera aussi grace à Mandrake/SuSE/Fedora/... qui auront essuyé les plâtres.
        • [^] # Re: Hein ?

          Posté par  (site web personnel) . Évalué à 1.

          Heu... franchement, il est pas si rare que ça, suffit de voir les forums linux après la sortie de la mandrake 10.0 community, il y en a pas mal qui se sont arrachés les cheveux et ont perdu leurs données. J'ai vu un bon paquet de gens souffrir de ce problème...
          • [^] # Re: Hein ?

            Posté par  . Évalué à 1.

            Oui. J'ai pas fait un journal pour rien :-)

            Mais quel est le pourcentage ? 1 % ? Je ne sait pas. Par exemple les dev RH/Fedora n'ont pas accédé à la moindre machine avec ce problème. Idem pour des dev de parted. D'où une impression de "laxisme" (légitime) par rapport à ce problème.
            Par contre le problème est très grave pour celui qui ne sait pas s'en débarrasser. Un linuxien qui ne va jamais sur les forums, s'il a ce problèm, va le dire à tout le monde.

            Je réagissais par rapport au "chezmoiçamarche" sans intérêt car la grande majorité des gens n'ont pas de problème.
            • [^] # Re: Hein ?

              Posté par  . Évalué à 1.

              Tu voudrais pas proposer une astuce DLFP ?
              Je trouve le mail très bien fait, et j'ai peur que les personnes concernées ne voit pas ce journal, étant donné les durées de vie des journaux.
              Ca serait sympa de le mettre sur lea-linux aussi.
      • [^] # deux

        Posté par  . Évalué à 0.

        Tu vas avoir les boules :
        http://www.osnews.com/comment.php?news_id=7154&limit=no#241457(...)
        I have not yet installed Fedora 2, but had recently the same problem with Debian Sid (with 2.6.5). Like you, couldn't boot XP, couldn't reinstall XP, tried FIXMBR, used fdisk & cfdisk to format my HD and create partitions and still failed to reinstall XP. The next thing I did was a base Debian Sid install, execute the command dd if=/dev/zero of=/dev/hda bs=512 count=1 to wipe the mbr which finally cured the mess.

        Et oui toutes les distributions sont concernées.
  • # Vous devez entrer un sujet et un commentaire

    Posté par  (site web personnel) . Évalué à 0.

    je ne comprends pas ton post : c est le bootloader qui a charge de lire le MBR puis de l executer ... qu il sagisse du NTLDR de NT5.* ou du chargeur de noyeau ou d du noyeau lui meme ... comment un OS (XP) peut il interagire avec un noyeau ... alors qu aucun des deux n est concerne par l autre ?

    tu n aurait pas confondu "Linux 2.6" avec "un Lilo optimise pour Linux 2.6" ?

    perso ... j ai un grub pour tout le monde ... et ca multiboot NT5.0 , NT5.1 , Linux 2.4(5) Linux 2.5(2) , Linux 2.6(3) , Mach(2), et BSD(2) ... jamais eu de soucis avec ca.
    • [^] # Re: Vous devez entrer un sujet et un commentaire

      Posté par  . Évalué à 5.

      > 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.

      La situation est très complexe.
      • [^] # Re: Vous devez entrer un sujet et un commentaire

        Posté par  (site web personnel) . Évalué à 0.

        que Linux herite du CHS du BIOS ok ... mais exlusivement dans le cas ou tu as ecrit ton pepin dans le MBR ... des que hu utilise un bootloader (grub ou LILO ) c est le boot loader qui herite des parametres du bios ...

        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.

        perso je n utilise pas parted ... ni cfdisk qui est encore plus bogue (j ai ecris un raport de dub de 4 pages sur cfdisk )

        donc ma question persiste : a partir du momont ou 99,999% des users utilisent un boot loader, comment est il possible que lo noyeau herite d un mauvais CHS ? sachant que si le boot loader utilise un mauvais CHS, il devrait etre incapable de lire le noyeau ...
        • [^] # Re: Vous devez entrer un sujet et un commentaire

          Posté par  . Évalué à 0.

          > donc ma question persiste : a partir du momont ou 99,999% des users utilisent un boot loader, comment est il possible que lo noyeau herite d un mauvais CHS ? sachant que si le boot loader utilise un mauvais CHS, il devrait etre incapable de lire le noyeau ...

          T'as presque rien compris.
  • # Vous devez entrer un sujet et un commentaire

    Posté par  (site web personnel) . Évalué à -2.

    C'est de la mailing Fedora mais ce problème touche TOUTES les distributions avec Linux 2.6.

    meme Debian et RedHat ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.