Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Dernière modification par guyjapon (06-04-2015 22:46:16)
Hors ligne
voic ci-dessous
le risque est qu'il soit écrasé par un système de fichier et perte des partitions.
2 ème possibilité: la partionnement est <<hybride>> et il utilise alors toujours un mbr de type ms-dos....
dans ce cas fdisk -l doit indiquer les partitions sachant qu'il ne sait pas le faire sur un disque gpt...ce qui veut dire qu'une partition ne pourra dépasser les 2,2 To
et voir aussi: gdisk -l /dev/sdb ..
Dernière modification par nikau (03-04-2015 10:22:59)
Hors ligne
Hors ligne
Dernière modification par nikau (24-03-2015 14:58:58)
Hors ligne
Hors ligne
Hors ligne
Dernière modification par nikau (26-03-2015 12:20:09)
Hors ligne
Dernière modification par raleur (28-03-2015 22:48:22)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Est ce que si j'avais eu cette partition Bios boot, le fichier core.img s'y serait installé automatiquement?
Hors ligne
si parted est installé, ou
si gnu-fdisk est installé (le fdisk par défaut d'util-linux ne comprend pas GPT), le confirmera.
Dernière modification par raleur (31-03-2015 08:21:17)
Il vaut mieux montrer que raconter.
Hors ligne
Est ce que si j'avais eu cette partition Bios boot, le fichier core.img s'y serait installé automatiquement?
oui, la commande grub-install cherche la partition bios_grub pour y coller le contenu de core.img, est ce que lorsque tu as installé grub dans le mbr, toutes tes partitions étaient déjà présentes ? sinon tu aurais du avoir un message d'erreur,
si le shell grub se situe dans une partition utilisée par un système de fichier, tu en connais maintenant le risque..
fdisk ou parted (indications start en numéro de secteurs) pour effectivement le vérifier
et dd if=/dev/sda bs=512 count=1 skip=232770 | hexdump -C pour vérifier l'exactitude de bootinfoscript.
Dernière modification par nikau (31-03-2015 08:44:32)
Hors ligne
@nikau
J'ai d'abord créer les partitions GPT de 1 à 6 avec gdisk du live Finnix vu que l'installateur ne semble pas le faire, puis j'ai installé Debian et Grub toujours avec l'installateur Debian.
Ensuite j'ai crée 4 autres partitions pour LFS à partir de ce futur système hôte Debian.
Et ça n'a pas ralé:)
Dernière modification par guyjapon (31-03-2015 15:38:00)
Hors ligne
Dernière modification par nikau (31-03-2015 16:58:49)
Hors ligne
Hors ligne
Suivant core.img, cela peut représenter au minimum une cinquantaine de secteurs qui ne sont pas spécialement protégés et risquent d'être réécris.
Il ne faut pas non plus exagérer le risque. LILO a toujours fait ainsi, de même que bon nombre de GRUB lorsqu'il est installé dans l'amorce d'une partition, et que je sache ça s'est toujours plutôt bien passé, malgré l'avertissement de grub-install. Le risque de déplacement du fichier core.img dans d'autres blocs reste surtout théorique, les systèmes de fichiers ne s'amusant généralement pas à faire ce genre de chose sauf en cas de défragmentation.
Je crois même que créer une sda11, donc en dernière position, doit aller.
Oui, du moment que c'est en-deça de la limite de 2 Tio adressable par le BIOS.
Est ce que relancer Grub va effacer /boot/grub/core.img?
grub-install va regénérer le fichier core.img dans /boot/grub puis l'installer dans son emplacement définitif le cas échéant.
Il vaut mieux montrer que raconter.
Hors ligne
Il ne faut pas non plus exagérer le risque.
si j'avais écrit AUCUN RISQUE l'esprit de contradiction de monsieur aurait stipulé que la partition bios_grub n'a pas été inventée pour des prunes..
Hors ligne
Dernière modification par raleur (01-04-2015 16:57:30)
Il vaut mieux montrer que raconter.
Hors ligne
le risque relatif n'étant pas un déplacement mais création.
peux tu développer stp ? si tu redimensionnes une partition quelconque celle de la partition bios_grub ne sera plus adressable au boot ?
je ne peux pas tester ça sinon mon luks sur GPT serait "killé"
edit: j'ai testé finalement car gdisk permet de sauvegarder tout le partitionnement (dont le mbr protecteur) et après redimensionnements, j'arrive toujours bien à accéder au deuxième étage du grub... (partition bios boot)
après le test pour récupérer mon partitionnement initiale
sauvegarde de partition gpt
Dernière modification par nikau (02-04-2015 15:39:33)
Hors ligne
le risque relatif n'étant pas un déplacement mais création.
Je ne comprends pas ce que tu veux dire. Création de quoi ?
si tu redimensionnes une partition quelconque celle de la partition bios_grub ne sera plus adressable au boot ?
Non, ce n'est pas ce que j'ai écrit. Si on déplace la partition qui contient le second étage du chargeur d'amorçage (partition bios_grub ou autre) avec son contenu (il ne suffit pas de juste modifier sa position de départ dans la table de partition), alors la position référencée dans le premier étage du MBR ne sera plus valide et le 2e étage ne pourra pas être chargé.
En pratique le risque du redimensionnement n'est pas applicable à une partition brute de type bios_grub mais seulement quand le deuxième étage est dans un fichier.
Il vaut mieux montrer que raconter.
Hors ligne
cela va de soi qu'il faut réadapter <<le premier étage>> donc réinstalle du grub dans le mbr si la partition grub_bios change de place, forcément.
et si cette partition était déjà réglée sur 1 Mo, personne ne songerait à un redimensionnement de toute manière.
bye le génie, on va pas trop polluer le post de guyjapon non plus, je pense qu'il a toutes les réponses qu'il attendait.
bonne soirée.
Hors ligne
création de fichier..
Désolé d'insister, je ne comprends toujours pas ce que tu veux dire. En quoi la création de fichier (quel fichier ?) constitue-t-elle un risque pour core.img ?
cela va de soi qu'il faut réadapter <<le premier étage>> donc réinstalle du grub dans le mbr si la partition grub_bios change de place, forcément.
Cela ne va de soi que si on sait comment le premier étage de GRUB fonctionne. Par exemple le programme d'amorce standard du MBR hérité de MSDOS fonctionne différemment : il sait lire la table de partition donc peut retrouver la position d'une partition même si elle a été déplacée.
En tout cas ce qui va de soi si la partition bios_grub change de place va tout autant de soi pour le fichier core.img après toute opération susceptible d'avoir modifié sa position.
Il vaut mieux montrer que raconter.
Hors ligne
Ce pavé n'est toujours pas clair...quel rapport avec le collé de core.img en plein dans sda1 au lieu de bios_grub ?
d'ou ma remarque que le risque n'étant pas un déplacement mais création de fichier (une écriture quelconque par le système de fichier quoi) dans sda1, le risque n'étant bien sûr pas gravissime, pas compliqué de réinstaller grub si écrasé.
répondu ci dessus
Dans le cas d'un partitionnement MSDOS (non pas GPT) le contenu de core.img n'aura plus lieu d'être écrasé de toute façon, se trouvant en principe sur le secteur n+1 juste après l'emplacement du mbr (du secteur n0) ,
Si la partition ou se trouve le 3ème étage grub est déplacée (pour être plus clair l'emplacement de /boot deplacé) Le jmp du 2ème au 3ème ne se fera plus, <<error:no such partition. grub rescue>> bref, immobilisation au 2 ème étage du shell grub....mais tu peux t'en sortir avec la manip classique (set, ls, set prefix.., set root..,insmod normal..)
ou tout simplement réinstaller le grub depuis un chroot.
bonne journée
Dernière modification par nikau (03-04-2015 10:04:16)
Hors ligne
Hors ligne