GRUB plante quand l'espace MBR->1e partition est trop petit

YannUbuntu · Le 21/09/2012, à 12:29

Bonjour
Ce topic a pour but de regrouper toutes les infos à propos d'un phénomène que j'ai observé sur un système:
GRUB plante quand l'espace MBR->1e partition est trop petit
Je cherche d'autres observations similaires, et si possible sur 12.04 ou 12.10, pour pouvoir créer un rapport de bug.

Remarque: je parle de l'espace que l'on peut observer via la commande 'sudo parted -l', par exemple:

sudo parted -l a écrit :

Number Start End Size Type File system Flags
1 1049kB 20,0GB 20,0GB primary ext4
2 20,0GB 40,0GB 20,0GB primary ext4
3 40,0GB 500,0GB 160,0GB primary ntfs

Tous commentaires, et surtout retours de tests bienvenus.

Dernière modification par YannUbuntu (Le 21/09/2012, à 12:53)

YannUbuntu · Le 21/09/2012, à 12:31

Je réserve ce post pour décrire le cas que j'ai observé:
cela concernait un utilisateur qui voulait installer Ubuntu 10.04
De mémoire (il faut que je retrouve le topic), son disque (usb) avait initialement un espace post-MBR de 16,4ko.
et ça a marché en refaisant le partitionnement via Gparted de façon à ce que l'espace devienne 32,3ko.

EDIT: topic retrouvé: http://forum.ubuntu-fr.org/viewtopic.ph … #p10746981

Dernière modification par YannUbuntu (Le 30/09/2012, à 23:45)

YannUbuntu · Le 21/09/2012, à 12:32

Je réserve ce 2e post pour parler de ce topic http://forum.ubuntu-fr.org/viewtopic.php?pid=10836271
une fois qu'il sera résolu, et dans le cas où ça a un lien avec la présente discussion.

Finalement, pas de rapport avec la présente discussion.

Dernière modification par YannUbuntu (Le 23/09/2012, à 15:14)

Nasman · Le 21/09/2012, à 13:01

Je pense que dans le temps grub legacy stage 1 ne devait utiliser que le premier secteur du disque et maintenant il y a une inflation avec grub-pc qui utile bien plus d'un secteur.

Je crois me souvenir que malbo avait examiné le contenu des premiers secteurs du disque - en écrivant une suite de caractères dans les 63 premiers secteurs puis en installant grub-pc pour examiner les secteurs concernés. Peut être que maintenant il y a plus de 63 secteurs concernés et donc que si la première partition commence au secteur 63 il peut y avoir des pb.

YannUbuntu · Le 21/09/2012, à 13:32

Pour info: Colin Watson, un dev de GRUB2/Ubiquity m'a indiqué le 7/12/2010 que:
- il est possible que GRUB2 écrive dans les 63 premiers secteurs du disque. (note: ça ne veut pas dire qu'il le fait systématiquement ni qu'il ne peut pas écrire +loin)
- la taille de GRUB2 dépend de core.img , dont la taille dépend du nbre de modules intégrés dedans
- GRUB2 vérifie la position de la 1e partition afin de ne pas écrire sur la 1e partition

Dernière modification par YannUbuntu (Le 21/09/2012, à 13:35)

Arbiel · Le 21/09/2012, à 14:13

selon les dires de Colin Watson, YannUbuntu a écrit :

- GRUB2 vérifie la position de la 1e partition afin de ne pas écrire sur la 1e partition

Il est en effet peu vraisemblable que l'installation de Grub altère le ou les premiers secteurs de la partition localisée au plus près du début du disque. En effet, autant que j'aie pu comprendre, GParted, pour retrouver le type d'une partition, s'appuie sur la signature du système de fichiers utilisé pour la formater. Par exemple, les 4 premiers caractères d'une partition formatée en NTFS contiendraient les 4 caractères "NTFS".

Mais il est extrêmement troublant de constater qu'est aléatoire l'amorçage d'un PC sur le disque duquel l'espace alloué à core.img est dit insuffisant. En fait, l'amorçage est aléatoire à nos yeux, parce que nous ne savons pas ce qui se passe. Si un processus quelconque altère core.img au point que le PC ne peut plus démarrer, comment ce même PC peut-il redémarrer à nouveau par la suite ?

compte supprimé · Le 21/09/2012, à 15:44

Je me souviens avoir lu (vers 2007) que certains softs windows (un jeu ou un anti-virus, je ne sais plus ?) utilisaient l'un ou l'autre des 63 premiers secteurs, ce qui perturbait grub...

YannUbuntu · Le 21/09/2012, à 16:53

Arbiel a écrit :

autant que j'aie pu comprendre, GParted, pour retrouver le type d'une partition, s'appuie sur la signature du système de fichiers utilisé pour la formater.

Gparted se base sur parted, qui est puissant mais parfois tres/trop pointilleux: lorsqu'une partition a certains soucis (même parfois petit car fdisk ne bronche pas), il n'affiche rien d'autre qu'un message d'erreur, et rien sur les partitions valides ce qui peut provoquer des soucis aux programmes qui se basent sur parted. Peut-etre que ça peut provoquer des soucis à GRUB2 aussi...

Arbiel a écrit :

Mais il est extrêmement troublant de constater qu'est aléatoire l'amorçage d'un PC sur le disque duquel l'espace alloué à core.img est dit insuffisant.

Non non, on n'a jamais constaté cela. Tu fais référence à la discussion du post#3 pour laquelle le boot est effectivement aléatoire, mais on ne sait pas encore si c'est dû à la "petitesse" de l'espace MBR. Attendons le retour de l'utilisateur avant de nous avancer sur cet exemple.

Par contre, le cas que je décris dans le post#2 n'était pas aléatoire. Le boot plantait systématiquement.

@faustus: oui, il s'agit notamment du DRM FlexNet, qui casse GRUB2 lorsqu'il est activé lors de l'utilisation de Windows. Ce problème existe toujours ((il y a une option dans Boot-Repair pour effacer ce DRM), mais je ne pense pas qu'il soit lié à la présente discussion car lorsque grub-install le détecte il affiche un message d'erreur, or dans le cas du post#2 il n'y avait pas ce message.

Dernière modification par YannUbuntu (Le 21/09/2012, à 16:54)

Arbiel · Le 21/09/2012, à 17:05

YannUbuntu a écrit :

mais on ne sait pas encore si c'est dû à la "petitesse" de l'espace MBR

Tu as raison, j'ai tendance à brûler les étapes.

malbo · Le 21/09/2012, à 18:46

Nasman a écrit :

Je crois me souvenir que malbo avait examiné le contenu des premiers secteurs du disque - en écrivant une suite de caractères dans les 63 premiers secteurs puis en installant grub-pc pour examiner les secteurs concernés. Peut être que maintenant il y a plus de 63 secteurs concernés et donc que si la première partition commence au secteur 63 il peut y avoir des pb.

Tu te souviens bien.
Actuellement, la taille du fichier core.img est de 26052 octets dans Ubuntu 12.04. A raison de 512 octets par secteur, ça fait quasiment 51 secteurs et si on ajoute le MBR, on peut dire que le Grub de Ubuntu 12.04 tartine sur environ 52 secteurs.

YannUbuntu · Le 21/09/2012, à 23:29

Bien vu Malbo! j'avais oublié qu'il y a une copie du core.img dans /boot/grub , chez moi aussi il fait 26052 octets.
Je ne sais pas si grub-install met une partie de ce fichier dans le MBR (440~446 octets avant la table de partition)...
- si oui il faut au minimum 512+26052-446 = 26118octets avant la 1e partition
- sinon, il le met en entier dans l'espace entre le MBR et la 1e partition, et il faut au minimum 512+26052 = 26564octets avant la 1e partition

Conclusion: si la 1e partition commence à moins de 26ko du début du disque, alors on devrait pouvoir reproduire le bug systématiquement.

Arbiel · Le 22/09/2012, à 11:24

Bonjour

YannUbuntu a écrit :

Conclusion: si la 1e partition commence à moins de 26ko du début du disque, alors on devrait pouvoir reproduire le bug systématiquement.

Je ne suis pas d'accord avec l'adverbe "systématiquement' de ta conclusion. Core.img est constitué de divers modules. Le manque éventuel d'espace pour l'enregistrer correctement se traduit par le fait que certains de ces modules seront défectueux ou absents.

L'utilité de ces modules peut dépendre de conditions variables d'un amorçage à l'autre, comme par exemple la présence d'une clé ou d'un disque USB, du niveau d'énergie de la batterie, ou que sais-je encore.

Et alors, étant donné que core.img est présent dans /boot/grub, pourquoi ne pas aller le chercher la-bas, d'autant que la fonction "insmod" de grub sert justement à charger les modules en allant les chercher dans /boot/grub (ou plus exactement dans ($prefix])/boot/grub, $prefix ayant été préalablement initialisé par l'adresse "grub", de la forme hdx,msdosy, de la partition contenant le fichier grub.cfg)

Arbiel

Dernière modification par Arbiel (Le 22/09/2012, à 18:36)

YannUbuntu · Le 23/09/2012, à 00:59

salut

Arbiel a écrit :

Le manque éventuel d'espace pour l'enregistrer correctement se traduit par le fait que certains de ces modules seront défectueux ou absents.

es-tu sûr de cela?
à priori ce n'est pas toujours le cas car GRUB2 refuse parfois de s'installer (et retourne un message d'erreur) lorsqu'il manque de place.

Arbiel a écrit :

étant donné que core.img est présent dans /boot/grub, pourquoi ne pas aller le chercher la-bas

il faudrait demander ça aux devs

compte supprimé · Le 23/09/2012, à 01:04

YannUbuntu a écrit :

Arbiel a écrit :
étant donné que core.img est présent dans /boot/grub, pourquoi ne pas aller le chercher la-bas
il faudrait demander ça aux devs

Peut-être qu'il faudrait d'abord monter la partition qui contient /boot/grub/core.img et que la routine de montage se trouve justement dans core.img...

Arbiel · Le 23/09/2012, à 14:34

Bonjour

Je crois que mon intervention du point 12 nous amène sur une discussion stérile, et je vous prie de m'en excuser.

L'architecture de Grub, et d'une manière générale de la procédure d'amorçage d'un PC, est ce qu'elle est, et notre forum n'est pas le lieu adéquat pour en discuter.

Que l'insuffisance de l'espace entre le premier secteur et la première partition (au sens partition d'adresse la plus basse) entraîne systématiquement ou aléatoirement l'échec de l'amorçage du PC n'est pas non plus une question fondamentale.

Je viens de lire que Seba-04 a encore des problèmes et que le recul de la première partition pour laisser suffisamment de place à core.img n'a pas résolu ses difficultés. J'imagine donc que nous n'avons pas assez de matière pour rédiger un rapport d'anomalie sur launchpad.

De mon côté, j'ai essayé de faire quelques essais, qui n'ont pas abouti. J'ai voulu créer une machine virtuelle avec VirtualBox en installant Ubutu 12.04 sur un disque dans lequel je voulais pouvoir jouer sur l'espace précédent la première partition. GParted n'a pas réussi à formater les diverses partitions que je lui avais demander de créer. Cette difficulté a pu résulter de ce que la partition dans laquelle j'ai enregistré le disque virtuel (Ubuntu.vdi) était pleine, mais je n'en ai pas encore la certitude.

Je me pose donc la question de savoir si je dois ou non continuer dans cette voie.

Je vous remercie de me dire ce que vous en pensez.

Arbiel

YannUbuntu · Le 23/09/2012, à 15:21

Arbiel a écrit :

Je viens de lire que Seba-04 a encore des problèmes et que le recul de la première partition pour laisser suffisamment de place à core.img n'a pas résolu ses difficultés.

Oui. Son cas n'a donc rien à voir avec celui que je décris au post#2. Et donc avec la présente discussion.

Arbiel a écrit :

Cette difficulté a pu résulter de ce que la partition dans laquelle j'ai enregistré le disque virtuel (Ubuntu.vdi) était pleine, mais je n'en ai pas encore la certitude.

Possible. Dans le doute, tu peux créer un disque virtuel de taille fixe, c'est plus simple.

cep · Le 23/09/2012, à 16:56

faustus a écrit :

Je me souviens avoir lu (vers 2007) que certains softs windows (un jeu ou un anti-virus, je ne sais plus ?) utilisaient l'un ou l'autre des 63 premiers secteurs, ce qui perturbait grub...

Oui.
Pour le reste, sur une installation classique et une table msdos il y a largement de la place pour y mettre le core.img.
Pour le vérifier il suffit de faire un stat /boot/grub/core.img |grep Tai ou un simple ls puis comparer à la sortie de
sfdisk -l -uS /dev/sdx ( ou parted adapté)

Dans des cas très particuliers il est possible de diminuer le core.img en supprimant des modules. Voit les notes dans les sources. Utile par exemple pour installation dans certaines disquettes ou autres cas.

Dernière modification par cep (Le 23/09/2012, à 16:57)

YannUbuntu · Le 30/09/2012, à 23:45

Je viens de retrouver la discussion du post#2: http://forum.ubuntu-fr.org/viewtopic.ph … #p10746981

L'installation de GRUB plantait car l'espace était de 16,4kB, et fonctionnait avec 32,3kB.
Ca colle avec le post#11 (plantage quand moins de 26ko.

jamesbad000 · Le 01/10/2012, à 01:08

Hello,

Si je peux éclairer votre lanterne :

1 - Le core img est constitués de modules en fonction du contexte d'installation.

=> C'est à dire si la partition boot est de type ext2,3,4 il embarque un module de système de fichier ext2 en lecture seul (mode lecture compatible avec les 3 version ext). Si la partition boot est de type ntfs il embarque un module de système de fichier ntfs.

=> Si le type de partitionnement du disque contenant la partition boot est ms-dos, un module pour ce type de partition, s'il est de type gpt un module pour gpt, et ainsi de suite...

Ce qui lui permet de disposer d'un os primitif, fournissant les services permettant d'accéder au répertoire boot et ensuite utiliser insmod (inclu aussi dans core.img) pour charger à la demande les autres modules permettant l'affichage du menu grub et le lancement des os.

En plus, Il se trouve que depuis la 12.04 il ont (enfin) ajouté en automatique l'insertion du module search.fs_uuid qui en conjonction avec le fichier load.cfg (inclus aussi) permet de localiser la partition boot par son uuid et non plus par un N° de partition codé en dur. Rendant théoriquement grub2 encore un poil plus robuste. Mais le core.img plus gros

par ailleurs, on peut forcer manuellement l'ajout de module dans le core.img...

Donc la taille du core.img est par essence variable.

2 - le MBR quant à lui est construit dans boot.img et donc non inclu dans core.img. Il contient juste le code pour charger la copie du core.img qui est placé à la suite du MBR.

3 - pour terminer, par convention un partitionnement de type ms-dos est supposé laisser libre au moins les 63 premiers secteur et grub2 compte bien la dessus !
Alors évidemment si on tombe sur un disque avec des secteurs de moins de 512octet, même si le partitionnement respecte la norme, il y aura moins que les 32k auxquels il s'attend.

tout cela est expliqué précisément dans l’excellent document qui se trouve ici http://people.apache.org/~skitching/Min … Grub2.html
que je n'ai jamais pris en défaut dans mes multiples expérimentations.

En fait vous y trouverez tout le process de construction du boot ainsi que le process de démarrage depuis le bios

arbiel a écrit :

Et alors, étant donné que core.img est présent dans /boot/grub, pourquoi ne pas aller le chercher la-bas, d'autant que la fonction "insmod" de grub sert justement à charger les modules

Seulement la fonction insmod ne tient pas dans le MBR et encore moins les modules permettant de trouver la partition et de lire dans le système de fichier...
Ce que tu suggère nous ramènerais à grub1 qui codait en dure l'adresse du stage1.5 (équivalent de core.img) dans le MBR. Ce qui mettait grub en panne dès que le fichier stage1.5 bouge (le fichier lui même, ou la partition suite à un redimentionnement ou un déplacement)

Dernière modification par jamesbad000 (Le 01/10/2012, à 23:26)

jamesbad000 · Le 01/10/2012, à 01:18

faustus a écrit :

Je me souviens avoir lu (vers 2007) que certains softs windows (un jeu ou un anti-virus, je ne sais plus ?) utilisaient l'un ou l'autre des 63 premiers secteurs, ce qui perturbait grub...

exacte, ça existe, j'ai rencontré ce cas ici http://forum.ubuntu-fr.org/viewtopic.ph … 9#p3777489
mais visiblement grub a su s'en arranger. Mais je n'ai pas vérifié s'il avait fragmenté sont core.img pour éviter de se faire bousiller ultérieurement par le logiciel flexnet en question, ou s'il l'avait écrasé sans autre forme de procès.
De toute façon le gars voulait se débarrasser de son windows...

Arbiel · Le 01/10/2012, à 02:24

jamesbad000 a écrit :

arbiel a écrit :
Et alors, étant donné que core.img est présent dans /boot/grub, pourquoi ne pas aller le chercher la-bas, d'autant que la fonction "insmod" de grub sert justement à charger les modules
Seulement la fonction insmod ne tient pas dans le MBR et encore moins les modules permettant de trouver la partition et de lire dans le système de fichier...

Je m'étais bien aperçu qu'il faudrait conserver une mini-core.img entre ce que j'ai compris être boot.img (dans le MBR) et l'actuel core.img, ce qui n'avance pas à grand chose, si ce n'est peut-être, en réduisant la taille, à diminuer la probabilité de manquer d'espace. Au total, on complique la situation sans gain vraiment significatif.

Par contre, ce qui me paraît plus troublant, c'est la présence de l'option --force de install-grub qui aboutit à un core.img incomplet lorsque la place manque. A quoi cette option sert-elle donc d'autre pour en expliquer l'existence ?

Arbiel

cep · Le 01/10/2012, à 08:49

Arbiel a écrit :

jamesbad000 a écrit :
arbiel a écrit :
Et alors, étant donné que core.img est présent dans /boot/grub, pourquoi ne pas aller le chercher la-bas, d'autant que la fonction "insmod" de grub sert justement à charger les modules
Seulement la fonction insmod ne tient pas dans le MBR et encore moins les modules permettant de trouver la partition et de lire dans le système de fichier...
Je m'étais bien aperçu qu'il faudrait conserver une mini-core.img entre ce que j'ai compris être boot.img (dans le MBR) et l'actuel core.img, ce qui n'avance pas à grand chose, si ce n'est peut-être, en réduisant la taille, à diminuer la probabilité de manquer d'espace. Au total, on complique la situation sans gain vraiment significatif.
Par contre, ce qui me paraît plus troublant, c'est la présence de l'option --force de install-grub qui aboutit à un core.img incomplet lorsque la place manque. A quoi cette option sert-elle donc d'autre pour en expliquer l'existence ?
Arbiel

Salut,
Quel que soit le système, et pour schématiser, dans le mbr il y a seulement une routine disant d'aller chercher le reste du processus de boot ailleurs.
Dans un système Ms.Windows il aura pour tâche d'aller chercher une partition amorçable et le bootloader.
Dans Grub le mbr indique de sauter aux secteurs suivants. Là il y aura le core.img construit à la volée par grub-setup.
Dans ce core.img, généralement placé dans les premiers 512 octets qui suivent le mbr, (faisant lui-aussi 512 octets), donc au début de ce core.img on va trouver en dur les adresses où trouver disques, partitions, de même que les autres fichiers nécessaires. De même dans ce core.img on va trouver à la suite divers outils (modules et autres) pour par exemple monter les systèmes de fichiers, un affichage, etc. etc.
Concernant la taille de ce core.img, elle doit en principe se positionner dans les 62 secteurs qui suivent le mbr et qui précèdent le système de fichiers proprement dit . D'ailleurs il y a une procédure dans grub-setup qui vérifie cette taille. On peut la voir entre autre si on a les sources de grub et que l'on regarde par exemple dans util/i386/pc/grub-setup.c :

if (core_sectors > 62)
        grub_util_warn (_("Your core.img is unusually large.  It won't fit in the embedding area."));
      else /* embed_region.end - embed_region.start < 62 */
        grub_util_warn (_("Your embedding area is unusually small.  core.img won't fit in it."));
      goto unable_to_embed;

Concernant l'option --force. Si 'lon n'installe pas core.img dans les secteurs suivant le mbr mais dans le boot sector d'une partition on a considéré que ce n'était pas forcément une bonne idée car ces secteurs étaient susceptibles d'être modifiés par la vie même du fs, par un déplacement de fs, une défrag un peu violente, etc. etc. On va donc utiliser aussi les blocklists :
https://www.gnu.org/software/grub/manua … ist-syntax
De même comme grub-setup n'a pu mettre dans le mbr son adresse pour la suite il faudra y pallier dans le boot sector, par un pseudo mbr. Et la situation se complique encore si le "boot sector" est celui d'une partition logique dans le cadre d'une table de partitions Ms.Dos puisqu'il y aura encore d'autres informations dans ces secteurs propres aux logiques, comme l'emplacement de l'autre logique qui suit. Le core.img sera écrit différement au niveau des adresses mais aura les mêmes éléments et le même rôle. Il ne sera pas fractionné.

Voilà, pardon pour le côté très schématique et simplifié, mais il existe sur le web des docs très complèts sur le sujet, en particulier sur les pages de Grub ou par exemple sur le wiki Archlinux entre autre :
https://wiki.archlinux.org/index.php/GRUB2

cep

Dernière modification par cep (Le 01/10/2012, à 08:53)

ahlner · Le 01/10/2012, à 19:46

Salut,
Salut Yann,

Je viens apporter un peu de lumière (je l'espère).
Il s'agit de grub 2 sur clef USB.
Cela marche avec Ubuntu 10.04/12.04, et aussi sur openSUSE 12.2 (par grub2-install /dev/sdc et le module Démarrage de Yast (Yet another setup tool!).
Cette clef USB sert à démarrer LTS 12.04 et les autres systèmes installés, dont XP et openSUSE.
Infos utiles :

# parted -l

Model: JetFlash TS2GJFV30 (scsi)
Disk /dev/sdc: 2064MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 32,3kB 2064MB 2064MB primary fat32 boot, type=0b

Edit :
Les 32,3kB correspondent "très approximativement" à :

63 secteurs (de 0 à 62) + 1 (le secteur 63) = 64 secteurs.
1 secteur=512 octets= 0,5 ko=0,5kB(bytes).
Donc 64 secteurs==>64x0,5=32ko
Je ne sais pas pourquoi "32,3ko". Peut-être un alignement.

Dernière modification par ahlner (Le 01/10/2012, à 22:18)

YannUbuntu · Le 01/10/2012, à 22:33

Merci à tous pour vos commentaires très instructifs.

En regardant le code indiqué par cep, j'en conclue que grub-install retourne systématiquement un message d'erreur lorsqu'il n'a pas assez de place. (à vérifier cependant)

Dans le cas de Ahiner (http://forum.ubuntu-fr.org/viewtopic.ph … #p10746981), il me semble que l'installateur Ubuntu (Ubiquity) aurait dû détecter ce message d'erreur et prendre des mesures appropriées (par exemple indiquer clairement à l'utilisateur que l'installation de GRUB a échoué, et éventuellement proposer d'installer GRUB dans un autre disque).

ahlner · Le 01/10/2012, à 22:58

YannUbuntu a écrit :

Merci à tous pour vos commentaires très instructifs.
En regardant le code indiqué par cep, j'en conclue que grub-install retourne systématiquement un message d'erreur lorsqu'il n'a pas assez de place. (à vérifier cependant)
Dans le cas de Ahiner (http://forum.ubuntu-fr.org/viewtopic.ph … #p10746981), il me semble que l'installateur Ubuntu (Ubiquity) aurait dû détecter ce message d'erreur et prendre des mesures appropriées (par exemple indiquer clairement à l'utilisateur que l'installation de GRUB a échoué, et éventuellement proposer d'installer GRUB dans un autre disque).

Et pourtant, je n'ai jamais eu de soucis ni avec LTS 10.04, ni maintenant avec LTS 12.04
Avec Yast, soit pas de message pour les 63 premiers secteurs libres, soit "taille exceptionnellement petite" dans le cas où la partition démarrait au secteur 32. A peu près pareil pour :

grub2-install /dev/sdc

Pour la 10.04, j'avaids essayé avec un lecteur de disquettes USB. Je ne me souviens plus du tout du retour.
grub-legacy procède en trois étapes : stage1, les stages1_5 liés aux systèmes de fichiers, et finalement stage2.
grub 2 (=grub-pc) devrait procéder en deux étapes seulement, stage1 et stage2, puisque les fichiers ".mod" sont chargés en fonction de la configuration.
Logiquement, le "stage1" de grub 2 sevrait se loger dans le MBR, et le restant à l'intérieur de la première piste, secteurs 0 à 62.
Telle est ma compréhension du sujet.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 21/09/2012, à 12:29

GRUB plante quand l'espace MBR->1e partition est trop petit

#2 Le 21/09/2012, à 12:31

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#3 Le 21/09/2012, à 12:32

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#4 Le 21/09/2012, à 13:01

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#5 Le 21/09/2012, à 13:32

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#6 Le 21/09/2012, à 14:13

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#7 Le 21/09/2012, à 15:44

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#8 Le 21/09/2012, à 16:53

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#9 Le 21/09/2012, à 17:05

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#10 Le 21/09/2012, à 18:46

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#11 Le 21/09/2012, à 23:29

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#12 Le 22/09/2012, à 11:24

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#13 Le 23/09/2012, à 00:59

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#14 Le 23/09/2012, à 01:04

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#15 Le 23/09/2012, à 14:34

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#16 Le 23/09/2012, à 15:21

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#17 Le 23/09/2012, à 16:56

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#18 Le 30/09/2012, à 23:45

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#19 Le 01/10/2012, à 01:08

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#20 Le 01/10/2012, à 01:18

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#21 Le 01/10/2012, à 02:24

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#22 Le 01/10/2012, à 08:49

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#23 Le 01/10/2012, à 19:46

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#24 Le 01/10/2012, à 22:33

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

#25 Le 01/10/2012, à 22:58

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

Pied de page des forums