Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 13/06/2012, à 00:18

jamesbad000

Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

Comme vous pourrez le constater par vous même, le doc http://doc.ubuntu-fr.org/tutoriel/grub_incassable est l'objet d'une véritable foire d'empoigne.

Dans la mesure ou les différentes tentatives de revenir à plus d'objectivité ont eues pour effet de provoquer un déluge de contre argument, dans un style rhétorique pour le moins inadapté à de la documentation. Je tente d'ouvrir le débat ici.


Voyons maintenant, ce qu'on peut dire de ce titre « Comment rendre GRUB incassable » qui me semble à l'origine des débordement.

1 - puisqu'il est admis que la zone amorce de GAG peut être écrasé par une installation windows, et qu'en conséquence le système sera d'en l'impossibilité de démarrer. On peut déjà affirmer la formulation de ce titre est un abusive.


2- Grub (1 ou 2 ) installé dans une zone amorce de partition n'est pas du tout à l'abri d'une panne contrairement à ce qui est affirmé de façon plus ou moins vigoureuse selon les sections du document. Pour mieux comprendre je vais détailler certains aspects d'installations de grub 1 & 2.


installation de Grub 1 :
quelque soit le mode d'installation, Grub1 insère directement dans la zone amorce l'adresse (n° de secteur du disque) d'un fichier image qu'il va devoir charger pour poursuivre le démarrage. Cette adresse n'est mise à jour qu'en faisant une nouvelle installation.
Il se trouve que certaines opérations peuvent provoquer le déplacement du fichier image (redimensionnement de la partition par ex). Auquel cas, le fichier ne se trouvera plus à l'emplacement ou grub le cherche, et grub sera dans  l'impossibilité de poursuivre le démarrage.


Grub 2  installé dans la zone amorce du disque :
Dans ce cas, le fichier image (core.img) est copié dans la zone libre de 62 secteurs qui suit la zone amorce, ou il est relativement à l'abri.

Ce fichier image embarque, entre autre, un gestionnaire de partition et de système de fichier. Il peut donc charger tous les modules dont il a besoin en interrogeant le système de fichier comme le fait n'importe quel OS . (Le système de fichier fournis l'adresse du fichier au derniers emplacement ou il a été enregistré).
Ce mécanisme le rend donc insensible aux mouvements de fichiers dans la partition boot qui mettaient Grub1 en panne.

grub 2 installé dans la zone amorce d'une partition
Dans ce cas grub2  ne dispose pas de la place nécessaire pour placer son fichier image derrière la zone amorce. Il procède alors comme Grub1 et est donc sujet au même problème.

Ce qui est confirmé sans équivoque par l'installateur de grub2. D'ailleurs, sans l'utilisation de l'option –force, il refuse carrément l'installation :

root@Miragek1204:~# grub-install /dev/sda12
/usr/sbin/grub-setup : attention : Attempting to install GRUB to a partitionless disk or to a partition.  This is a BAD idea..
/usr/sbin/grub-setup : attention : Installation impossible. GRUB peut seulement être installé sur cette configuration en utilisant les listes de blocs. Toutefois, les listes de blocs ne sont PAS fiables et leur emploi n'est pas conseillé..
/usr/sbin/grub-setup : erreur : les listes de blocs ne seront pas traitées.

Avec l'option –force, il obtempère. De mauvaise grâce :

root@Miragek1204:~# grub-install --force /dev/sda12
/usr/sbin/grub-setup : attention : Attempting to install GRUB to a partitionless disk or to a partition.  This is a BAD idea..
/usr/sbin/grub-setup : attention : Installation impossible. GRUB peut seulement être installé sur cette configuration en utilisant les listes de blocs. Toutefois, les listes de blocs ne sont PAS fiables et leur emploi n'est pas conseillé..
Installation finished. No error reported.

En conséquence, non seulement installer grub 1 ou 2 dans une zone amorce de partition ne le rend pas incassable. Et en ce qui concerne grub 2 ça lui fera perdre un de ses avantages en terme robustesse.


Références documentaires :
Une doc détaillée de bonne qualité sur le mode de fonctionnement de la commande grub-install et sur le déroulement du démarrage lui même : http://people.apache.org/~skitching/Min … Grub2.html

la doc officielle Grub2 http://www.gnu.org/software/grub/manual … stallation

Dernière modification par jamesbad000 (Le 23/06/2012, à 00:24)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#2 Le 13/06/2012, à 00:27

jamesbad000

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

Voyons maintenant ce qu'on peut dire de GAG


Je dois reconnaître que l'installation et l'usage sont relativement simple et bien plus intuitif que GRUB. D’abord parce que toute la configuration se fait par l'interface graphique, et est modifiable directement au moment du démarrage. Ensuite parce que en raison de ses possibilités plus limitées que celle de GRUB, il y a moins de questions à se poser surtout si on a un seul disque.
Avec plusieurs disques, il faut tout de même comprendre la problématique d'échange des positions de disque dans le cas ou windows n'est pas sur le 1er disque. Alors que ce problème est géré automatiquement par GRUB2.

L'autre avantage que l'on peut reconnaître à GAG, c'est qu'il ne tombe effectivement pas en panne si on vire la partition Linux qui contient le répertoire de boot GRUB, ou celle de windows. (En même temps, si j'utilisais le même type d'argumentation qu'on trouve sur la page « GAG incassable »; je dirais qu'on ne peut pas supprimer la partition de boot et après pleurer parce que le PC ne démarre plus. Mais non, je m’abstiendrais...)


Problème rencontrés à l’installation, et au démarrage :

1 - Tout c'est bien passé jusqu'au moment ou, dans le menu de démarrage, j'ai voulu enregistrer ma configuration. Là j'ai reçu un message « erreur d'écriture ». Et même après reboot le problème a persisté.
Par contre je n'ai pas reproduit le problème à partir de l'install CD, ni en recommençant l'installation à partir d'une session linux.

Comme, on peut lancer un démarrage sans enregistrer la configuration. J'ai tout de même tenté de démarrer sur ma partition Kubuntu que j'avais pris soins de rendre bootable quelques jours auparavant.


2 - Là, je suis resté bloqué sur un écran noir avec curseur à gauche.
Après vérification visuelle (hexeditor) qu'il y avait bien une zone amorce GRUB dans la partition en cause. J'en ai donc conclu que le fichier core.img (voir explication plus haut) avait bougé. Probablement suite au téléchargement des mises à jours, dans lesquels je me souvient avoir vu passer grub. Et cela confirme la théorie que Grub installé dans la zone de partition n'est pas incassable !!

Après réinstallation du GRUB dans la zone amorce de partition, problème réglé.
Le démarrage de windows lui c'est fait directement sans problèmes.

A noter que les tentatives de démarrer sur une partitions non amorçable donnent lieu à un message « secteur d'amorce infecté ». Ce qui à défaut d'être rédhibitoire, peut tout de même générer quelques inquiétudes...


Tentative d'installation sur disque partitionné en  GPT

Après ça, j'ai voulu voir comment GAG réagissait lors d'une tentatives d'installation sur un disque partitionné en GPT.
Vu que GAG, comme GRUB2,  utilise les 62 secteurs laissés libre derrière un MBR je m'attendais à ce qu'il écrase bêtement la table de partition GPT qui est justement là.
Et bien il n'en est rien. Il a tenu compte de la présence de la partition déclarée dans le MBR « protecteur » créé par GPT.

root@Miragek1204:~# gag-install /dev/sdb
GAG installer, v4.9
Language: ENGLISH
Keyboard type: QWERTY
Will intall GAG on device /dev/sdb
There are no free space to install GAG.
Remake your partitions to ensure that they start after the sector 63



tentative d'installation de GAG sur une partition (à partir d'une session linux)

Ce test montre que l'installation de gag à partir d'une session linux est potentiellement destructrice. Car lors de cette opération, j'ai pu sans problème installer GAG dans une partition. Et là, qu'il s'agisse d'ext4 ou de NTFS, le système de fichier est détruit :


Avant GAG :

root@Miragek1204:~# e2fsck -n /dev/sdb1
e2fsck 1.42 (29-Nov-2011)
/dev/sdb1 : propre, 11/65808 fichiers, 12659/263056 blocs
root@Miragek1204:~# gag-install /dev/sdb1
GAG installer, v4.9
Language: ENGLISH
Keyboard type: QWERTY
Will intall GAG on device /dev/sdb1
GAG sucesfully installed in /dev/sdb1

Après GAG :

root@Miragek1204:~# e2fsck -n /dev/sdb1
e2fsck 1.42 (29-Nov-2011)
e2fsck : Superbloc invalide, tentons d'utiliser les blocs de sauvetage...
(… des pages d'erreurs...)

e2fsck: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/sdb1

Le superbloc n'a pu être lu ou ne contient pas un système de fichiers
ext2 correct. …

A noter tout de même au crédit de GAG ; Après 2 passages de e2fsck j'ai réussi à retrouver un système de fichier propre, et  j'ai  récupéré tout de même plus de 3500 fichier, comme on peut le voir ci-dessous, alors qu'il n'y en avait que 11 au départ. 

root@Miragek1204:~# e2fsck -n /dev/sdb1
e2fsck 1.42 (29-Nov-2011)
/dev/sdb1 : propre, 3551/65808 fichiers, 12806/263056 blocs

Jésus christ a donc un concurrent sérieux sur le procédé de multiplication des petits pains. Et je suppose que c'est ce qui a pu amener certains à présenter ce produit comme une solution miracle.

Dans un prochain article, je vous expliquerais comment GAG peut soigner les corps au pieds, rendre la vue à un sourd-muet, et stopper le réchauffement climatique...

Dernière modification par jamesbad000 (Le 13/06/2012, à 01:12)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#3 Le 13/06/2012, à 06:36

cep

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

jamesbad000 a écrit :

Comme vous pourrez le constater par vous même, le doc http://doc.ubuntu-fr.org/tutoriel/grub_incassable est l'objet d'une véritable foire d'empoigne.
[couic] . . .
Grub 2  installé dans la zone amorce du disque :
Dans ce cas, le fichier image (core.img) est copié dans la zone libre de 62 secteurs qui suit la zone amorce, ou il est relativement à l'abri.

Ce fichier image embarque, entre autre, un gestionnaire de partition et de système de fichier. Il peut donc charger tous les modules dont il a besoin en interrogeant le système de fichier comme le fait n'importe quel OS . (Le système de fichier fournis l'adresse du fichier au derniers emplacement ou il a été enregistré).
Ce mécanisme le rend donc insensible aux mouvements de fichiers dans la partition boot qui mettaient Grub1 en panne.

Quelques approximations dans tes deux postes. Par manque de temps je ne reprendrais que ce qui est cité plus haut (j'y reviendrais peut-être ultérieurement).

Non, grub2 pas plus que grub legacy n'est à l'abri d'un déplacement du système de fichiers. S'il ne trouve pas par exemple le fichier .cfg il ne pourra booter le système, sauf à entrer dans le "bash" grub. etc. etc.

Dernière modification par cep (Le 13/06/2012, à 06:37)

Hors ligne

#4 Le 13/06/2012, à 12:51

YannUbuntu

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

Bonjour
bonne idée ce sujet car la page wiki est devenue un beau n'importe-quoi smile
Pour commencer je pense qu'il faudrait renommer la page "GAG" tout simplement, et présenter l'installation et l'utilisation de ce bootloader.
Ensuite éventuellement faire un tutoriel (sur une autre page) du genre "Comment chaîner deux amorceurs".


à consulter/améliorer: Guide du Débutant, Logiciels, Ecole, Travail, Maison

Hors ligne

#5 Le 13/06/2012, à 19:07

cep

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

jamesbad000 a écrit :

grub 2 installé dans la zone amorce d'une partition
Dans ce cas grub2  ne dispose pas de la place nécessaire pour placer son fichier image derrière la zone amorce. Il procède alors comme Grub1 et est donc sujet au même problème.

Ce qui est confirmé sans équivoque par l'installateur de grub2. D'ailleurs, sans l'utilisation de l'option –force, il refuse carrément l'installation :

Un core.img de taille normale peut très bien se placer dans le bpr, il y a la place nécessaire. L'option --force est nécessaire car il est déconseillé de faire son installation dans ce secteur qui peut être endommagé lors de l'utilisation du fs, par exemple lors d'un fsck et non pour un manque de place.

Mais on a vu aussi des programmes sous Ms. Windows occuper les secteurs après le mbr pour y inscrire certaines données.

Bref, il n'y a pas de grub incassable. Aussi les pages du wiki, écrites par parametre à l'origine datent de 2006. Depuis les choses ont bien changé. Je ne sais même pas si le développement de Gag se poursuit toujours.

Par contre il est toujours préférable de faire une sauvegarde du mbr et des 63 secteurs avant toute installation de grub. Voir aussi les modifications futures de la table de partitions avec sfdisk par exemple.

Enfin il manque dans l'installation de grub une routine de sauvegarde du mbr avant modification, chose que fait par exemple extlinux.

# Saving old MBR
echo -n "P: Saving old MBR..."
dd if="${_DEVICE}" of=/boot/mbr-$(basename "${_DEVICE}").old bs=440 count=1 2> /dev/null
echo " done: /boot/mbr-$(basename "${_DEVICE}").old"

# Writing syslinux MBR
echo -n "P: Writing new MBR..."
dd if=/usr/lib/extlinux/mbr.bin of="${_DEVICE}" bs=440 count=1 2> /dev/null
echo " done: ${_DEVICE}"

À cela on pourrait utiliser sfdisk ou autre pour avoir trace des partitions primaires et logiques sur table msdos, avant et après modifs.

Dernière modification par cep (Le 13/06/2012, à 19:08)

Hors ligne

#6 Le 14/06/2012, à 00:14

jamesbad000

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

Tout d'abord je précise, puisque ça ne semble pas clair :
L'objectif de mon post initial est d'éviter que des utilisateurs d'Ubuntu ne se laissent bercer par le doux rêve que GAG va leur éviter tous les maux ,comme on semble vouloir le dire sur la page mise en cause.

Ma conclusion étant (En gras tout de même) que GAG rend, au contraire, grub 2 plus fragile. Et non que Grub 2 serait lui, le bootloader miraculeux capable de résister à tous les outrages résultant de manip erronées, ou de bug dans des composant logiciels  !


Maintenant pour répondre à cep, je veux bien qu'il y ait des approximations, et les corriger si quelqu'un met le doigt dessus. Mais là je crois que c'est plutôt moi qui vais te corriger :


cep a écrit :

Non, grub2 pas plus que grub legacy n'est à l'abri d'un déplacement du système de fichiers.

Tu m'explique. Est-ce que tu conteste la présence dans core.img d'un module capable de monter un système de fichier valide ?
Ou est-ce que quand tu parles de déplacement de système de fichier, tu pense à des manip qui corrompent le système de fichiers. Ou un lancé de PC par la fenêtre peut-être ? Bref des choses sans le moindre rapport avec la robustesse du mécanisme de boot en lui même.

En tout cas avant d'en parler j'ai fait différents redimensionnements de système de fichier, déplacement de partitions avec effacement de l'emplacement d'origine pour m'assurer qu'il ne pourrait pas y retrouver les fichiers... Jamais grub 2 n'a eu la moindre gêne.

La seule chose qui provoque un problème dans ce genre d'opération, c'est lorsque la partition de boot change de n° d'ordre (sdaX devient sdaY) ...


cep a écrit :

Un core.img de taille normale peut très bien se placer dans le bpr, il y a la place nécessaire.

Voyons ça :

ls -l /boot/grub/core.img 
-rw-r--r-- 1 root root 26035 juin  11 01:56 /boot/grub/core.img

Ci-dessus, un core.img des plus standard avec une 12.04 : un peu moins de 26k. Ca s'annonce mal...


root@Miragek1204:~# mount /dev/sdc1 /mnt
root@Miragek1204:~# ls -l /mnt/grub/core.img 
-rw-r--r-- 1 root root 24660 avril 23 00:47 /mnt/grub/core.img

sur 10.04 : un peu moins de 24k

Voyons maintenant ce qu'on nous dit sur le wiki dédié au ext4 https://ext4.wiki.kernel.org/index.php/ … uper_Block

For the special case of block group 0, the first 1024 bytes are unused, to allow for the installation of x86 boot sectors and other oddities.

Il y a la place pour 1K. Je m'attarde pas à faire une copie de mon core.img au début de la partition pour savoir que ça va détruire le système de fichier. Comme ça a été  le cas lors du test d'installation de gag sur une partition (voir mon 2ème post)
D'autant que par le passé j'ai déjà pu constater visuellement que la création d'un système de fichier ext allait écrire à partir du 3ème secteur de la partition.


cep a écrit :

L'option --force est nécessaire car il est déconseillé de faire son installation dans ce secteur qui peut être endommagé lors de l'utilisation du fs, par exemple lors d'un fsck et non pour un manque de place.

On est dans un monde imaginaire là. Ou plutôt l'enfer. Comme si le fsck ne tenait pas compte de la règle que j'ai indiqué avant. Évidemment si tu pense à un fsck buggé qui pourrait tout aussi bien aller bousiller n'importe quoi d'autre. La encore c'est sans rapport avec la robustesse du bootloader.


cep a écrit :

Mais on a vu aussi des programmes sous Ms. Windows occuper les secteurs après le mbr pour y inscrire certaines données.

Effectivement, c'est pourquoi j'ai pris soin d'ajouter la mention "relativement" dans la section reprise ci-dessous

jamesbad000 a écrit :

Dans ce cas, le fichier image (core.img) est copié dans la zone libre de 62 secteurs qui suit la zone amorce, ou il est relativement à l'abri.

Ce point est d'ailleurs précisé dans la doc officielle grub2 que j'ai indiqué dans mon premier post. j'ajoute que j'ai rencontré ce cas en pratique http://forum.ubuntu-fr.org/viewtopic.ph … 9#p3777489
Et que grub2 à su le détecter et fragmenter son core.img pour éviter d'utiliser le secteur "infecté"


cep a écrit :

Bref, il n'y a pas de grub incassable.

On est d'accord sur ce point.

Dernière modification par jamesbad000 (Le 14/06/2012, à 11:58)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#7 Le 14/06/2012, à 00:25

jamesbad000

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

YannUbuntu a écrit :

Bonjour
bonne idée ce sujet car la page wiki est devenue un beau n'importe-quoi smile
Pour commencer je pense qu'il faudrait renommer la page "GAG" tout simplement, et présenter l'installation et l'utilisation de ce bootloader.
Ensuite éventuellement faire un tutoriel (sur une autre page) du genre "Comment chaîner deux amorceurs".

Bonsoir,

Enchanté que ça plaise à un spécialiste !

C'est à peu prêt ce à quoi je pensais.
Encore que ce titre va perdurer dans le lien qu'on trouve sur la doc d'installation de base d'Ubuntu. Donc je me demande s'il ne faudrait pas carrément refaire une autre page pour s'en débarrasser.

De toute façon avant de toucher à quoi que ce soit, je vais laisser passer quelques semaines. Histoire d'éviter que le débat reprenne directement sur la doc. (Les derniers commentaires, ajoutés à la suite des phrases de la section "inconvénient", datent du début d'année)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#8 Le 14/06/2012, à 06:33

cep

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

jamesbad000 a écrit :

sur 10.04 : un peu moins de 24k

Voyons maintenant ce qu'on nous dit sur le wiki dédié au ext4 https://ext4.wiki.kernel.org/index.php/ … uper_Block

For the special case of block group 0, the first 1024 bytes are unused, to allow for the installation of x86 boot sectors and other oddities.

Il y a la place pour 1K. Je m'attarde pas à faire une copie de mon core.img au début de la partition pour savoir que ça va détruire le système de fichier.
[couic] . . . [/couic]
On est dans un monde imaginaire là. Ou plutôt l'enfer. Comme si le fsck ne tenait pas compte de la règle que j'ai indiqué avant. Évidemment si tu pense à un fsck buggé qui pourrait tout aussi bien aller bousiller n'importe quoi d'autre. La encore c'est sans rapport avec la robustesse du bootloader.

À la lecture des deux passages cités et en oubliant le reste de tes approximations je me rends compte que tu ne connais absolument rien au sujet, rien à l'agencement et à l'organisation des partitons logiques de tables msdos, rien à grub, et que tu racontes n'importe quoi. Ben oui, je ne vais pas prendre des gants pour te le dire devant ton comportement plus que suffisant et arrogant.

Donc j'arrête là la discussion qui de toute manière, vu ta réaction, ne peut en être une et te laisse devant tes certitudes.

Dernière modification par cep (Le 14/06/2012, à 06:35)

Hors ligne

#9 Le 14/06/2012, à 10:42

jamesbad000

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

cep a écrit :

Ben oui, je ne vais pas prendre des gants pour te le dire devant ton comportement plus que suffisant et arrogant.

Donc j'arrête là la discussion qui de toute manière, vu ta réaction, ne peut en être une et te laisse devant tes certitudes.

C'est curieux chez les marins, ce besoin de faire des phrases...


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#10 Le 14/06/2012, à 10:51

cep

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

jamesbad000 a écrit :

C'est curieux chez les marins, ce besoin de faire des phrases...

La bonne règle veut que l'on entoure de guillemets les phrases que l'on cite et dont on n'est pas le "créateur" . . .  N'est pas Audiard qui veut.

Hors ligne

#11 Le 04/07/2012, à 09:01

YannUbuntu

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

Bonjour
j'ai créé la page http://doc.ubuntu-fr.org/gag et redirigé http://doc.ubuntu-fr.org/tutoriel/grub_incassable vers celle-ci.

Ce qui serait constructif c'est de tester si GAG fonctionne avec LVM, RAID, MacOS etc...

Dernière modification par YannUbuntu (Le 04/07/2012, à 09:03)


à consulter/améliorer: Guide du Débutant, Logiciels, Ecole, Travail, Maison

Hors ligne

#12 Le 04/07/2012, à 22:03

jamesbad000

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

Ah, bien joué.

Quant à tester tout ces cas de figure, à part éventuellement le LVM, je n'ai pas le matériel requis.

Ceci dit, sachant que GAG ne sait rien faire d'autre qu'un chainload sur une amorce de partition de type ms-dos à partir d'un MBR, ça exclut MacOs
à cause du partitionnement GPT (Refus logique de GAG à s'installer sur GPT pour cause d'indisponibilitée des secteurs  à la suite du MBR protecteur)

Exclut aussi tout ce qui est boot en mode UEFI, puisque n'utilise pas le MBR.


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#13 Le 04/07/2012, à 22:56

YannUbuntu

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

ok merci, on peut déjà préciser cela sur la page.


à consulter/améliorer: Guide du Débutant, Logiciels, Ecole, Travail, Maison

Hors ligne

#14 Le 05/07/2012, à 12:26

cep

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

YannUbuntu a écrit :

Bonjour
j'ai créé la page http://doc.ubuntu-fr.org/gag et redirigé http://doc.ubuntu-fr.org/tutoriel/grub_incassable vers celle-ci.

Salut Yann,

Déjà en 2006 la méthode conseillant gag était périmée.
parametre avait créé cette autre page :
http://forum.ubuntu-fr.org/viewtopic.php?id=28431&p=1
Pour autant je ne sais pas si c'est toujours d'actualité avec les nouvelles versions de Windows. N'en ayant pas je ne peux vérifier.

Pour en revenir à Gag, il peut être avantageusement remplacé par Extlinux qui permet aussi de faire du chainload, qui fonctionne sur les tables gpt.
Il semblerait aussi qu'il gère le mac efi avec isohybrid contenu dans le paquet syslinux au vu du changelog :

http://www.syslinux.org/wiki/index.php/ … _Changelog

Pour autant dans le man de la version 4.05+dfsg-6 je ne vois pas cette option -m. N'ayant pas de bios efi je ne peux tester et me méfie des résultats trouvés avec virtualbox.

Bonne continuation.
cep

Hors ligne

#15 Le 05/07/2012, à 16:30

YannUbuntu

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

Merci cep.
Il faudrait crééer une page http://doc.ubuntu-fr.org/syslinux ... wink


à consulter/améliorer: Guide du Débutant, Logiciels, Ecole, Travail, Maison

Hors ligne

#16 Le 22/09/2012, à 18:48

jeanmaire

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

Bonjour .

Je me permet de me raccrocher à ce fil bien qu'il soit assez ancien , car je pense y trouver mon sauveur .

Voilà :
Partant d'une config a un seul disque dur avec 2 partitions une Windows W7 et l'autre UBUNTU (Koala Karmic) , j'ai progressivement fait évoluer celle-ci .
1  -  installation du chargeur d'amorçage GAG   - OK
2  -  installation d'un 2ème disque dur et chargement sur ce disque d'une 2ème mouture de W7 .
3  - insertion de ce cette version dans la configuration de GAG  -  OK
4  - installation d'un 3ème disque dur et chargement sur ce 3ème disque dur de UBUNTU Lucid Lynx
5  - insertion de cette version dans la configuration de GAG  - OK
Je me trouve alors à la tête de 3 disques bootables : le premier qui porte GAG , le 2ème porte W7 et le troisième UBUNTU Lucid Lynx . Je suis protégé contre toute destruction de disque ( mes données sont évidemment régulièrement sauvegardées sur un disque externe ) . En cas de pépin sur le disque qui porte GAG , je peux en effet amorcer les disques 2 et 3 à partir du BIOS .
Et je fonctionne comme cela depuis 3 ans sans la moindre anichroche .
Récemment , j'ai fait l'acquisition d'un SSD . Le package contenant Norton Ghost , j'ai cloné mon disque dur N° 3 (W7) sur le SSD . Tout d'abord je n'ai pas pu booter sur ce disque . mais je me suis aperçu que le SSD contenait tous les fichiers d'un disque système et qu'en bootant  depuis le BIOS sur le disque N° 2 (W7) , j'obtenais un écran me proposant 4 versions " récupérées " de W7 .  Le premier choix étant manifestement celui se trouvant sur le SSD ( rapidité de la séquence de boot , et installation d'un nouveau programme ) et le 2ème choix correspondant au boot du disque N° 2 . Le dernier choix : W7 professionnel , plante car j'ai la version Premium de W7 .
Comme , par ailleurs , il m'est possible de booter avec UBUNTU Lucid Lynx à partir du BIOS  , je peux disposer de mes deux OS de travail .
Mais il y a un problème avec GAG .
Si je boote avec le disque N° 1 , GAG me propose les 2 OS qui se trouvent sur ce disque (la première moûture de W7 et UBUNTU  Koala KARMIC) ,mais pas moyen d'atteindre , ni le disque N° 3 (Lucid Lynx ) , ni le SSD , Par contre le dernier bouton que j'avais appelé : "UBUNTU LYNX"   me dirige vers le BOOT  du disque N° 2 "W7 "   . J'ai essayé toutes les configurations proposées par GAG (B,C,D,E,F,G ) ., je n'ai pas trouvé la config pour démarrer sur Lucid Lynx  Par contre je peux toujours atteindre les 2 OS du disque N° 1 .
Résultat :  je peux booter mes  OS de travail principaux à partir du BIOS et  mes OS de " backup " par GAG !  ce n'était pas le but de la manoeuvre .

Ma question : Comment faire pour atteindre les Boot Lucid Lynx et W7 avec GAG , sans passer par le BIOS ?
Merci d'avance à ceux qui pourront m'aider
Georges

Hors ligne

#17 Le 23/09/2012, à 00:14

YannUbuntu

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

@jeanmaire: merci de créer une nouvelle discussion, et donner juste le lien ici.

(Règle du forum: 1 discussion par problème)


à consulter/améliorer: Guide du Débutant, Logiciels, Ecole, Travail, Maison

Hors ligne

#18 Le 24/09/2012, à 13:27

jeanmaire

Re : Guerre d'édition sur la page de doc « Comment rendre GRUB incassable »

OK Yann Mille excuses , voilà le lien .

http://forum.ubuntu-fr.org/viewtopic.php?id=1048111

Bonne journée

Hors ligne