GRUB : listes de blocs, erreur

Le
andre_debian
Bonjour,

# grub-install /dev/sda1
me donne ce long message :

"Le systme de fichiers NTFS ne prend ps en charge l'empaquetage.
Grub ne doit pas tre install sur cette configuration qu'en utilisant =
la
liste de blocs, qui ne sont pas FIABLES donc dconseilles.
Erreur, refus de continuer avec les listes de blocs"

Pourtant, en rebootant, Grub fonctionne,
sauf le menu de boot en caractres ultra petits.

Mon systme est Debian Jessie, avec une partition Windows (sda1)
et d'autres partitions de sauvegarde GNU/Linux (sda3, sda4).

Cette erreur de grub est survenue aprs un "apt-get upgrade" de Jessie.

Merci,

Andr
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #26472042
Le 11/04/2018 à 11:38, Klaus Becker a écrit :
Le mercredi 11 avril 2018, 11:31:27 CEST a écrit :
# grub-install /dev/sda1
me donne ce long message :
"Le système de fichiers NTFS ne prend ps en charge l'empaquetage.



"empaquetage", vraiment ? Ce n'est pas plutôt "embarquage" (embedding) ?
Grub ne doit pas être installé sur cette configuration qu'en utilisant la
liste de blocs, qui ne sont pas FIABLES donc déconseillées.
Erreur, refus de continuer avec les listes de blocs"

Il fallait taper :
# grub-install /dev/sda
Je ne me souviens plus si avant je tapais /dev/sda1,
peut-être une modification du dernier paquet grub ?


Non, GRUB a toujours réagi ainsi avec un type de système de fichier ne
permettant pas l'embarquage (en gros : tous sauf btrfs). De toute façon,
je ne suis même pas sûr qu'on puisse installer GRUB dans une partition NTFS.
Pour installer grub, il faut toujours /dev/sdx

Non, c'est faux.
andre_debian
Le #26472133
On Thursday 12 April 2018 00:05:29 Pascal Hambourg wrote:
"Le système de fichiers NTFS ne prend pas en charge l'empaquetage :



"empaquetage", vraiment ? Ce n'est pas plutôt "embarquage" (embeddin g) ? :

Erreur de ma part, c'est bien "embarquage", désolé.
Le 11/04/2018 à 11:38, Klaus Becker a écrit :
Pour installer grub, il faut toujours /dev/sdx :

Non, c'est faux :

Si, c'est bien /dev/sdx soit /dev/sda
André
Michel
Le #26472135
Le 13/04/2018 à 11:30, Klaus Becker a écrit :
Le vendredi 13 avril 2018, 11:11:31 CEST a écrit :
On Thursday 12 April 2018 00:05:29 Pascal Hambourg wrote:
"Le système de fichiers NTFS ne prend pas en charge l'empaquetage :



"empaquetage", vraiment ? Ce n'est pas plutôt "embarquage" (embedding) ? :

Erreur de ma part, c'est bien "embarquage", désolé.
Le 11/04/2018 à 11:38, Klaus Becker a écrit :
Pour installer grub, il faut toujours /dev/sdx :

Non, c'est faux :

Si, c'est bien /dev/sdx soit /dev/sda
André

On peut installer grub sur une autre partoche,par ex sda1, mais je ne sais pas
trop à quoi ça sert, on ne le verra pas au démarrage sur sda1.
Klaus

C'est utile si tu as plusieurs installation sur la même machine par
exemple. La distribution principale installera grub sur /dev/sdx, elle.
Pascal Hambourg
Le #26472139
Le 13/04/2018 à 11:11, a écrit :
On Thursday 12 April 2018 00:05:29 Pascal Hambourg wrote:
Le 11/04/2018 à 11:38, Klaus Becker a écrit :
Pour installer grub, il faut toujours /dev/sdx :


Non, c'est faux :

Si, c'est bien /dev/sdx soit /dev/sda

Dans ton cas peut-être, mais pas forcément dans le cas général.
Primo, le "disque" ne s'appelle pas toujours /dev/sd*. Seuls les disques
SCSI ou dont les pilotes utilisent une couche d'émulation SCSI (PATA et
SATA avec libata, USB...) sont nommés ainsi. Les disques IDE avec les
anciens pilotes IDE sont nommés /dev/hd*, les cartes flash SD ou MMC
dans un lecteur natif (pas un lecteur USB qui émule un support de
stockage USB) et les SSD eMMC sont nommés /dev/mmcblk*, les nouveaux SSD
NVMe sont nommés /dev/nvme*...
Secundo, on peut installer GRUB dans le secteur d'amorce d'une partition
et pas forcément dans le MBR du disque. Certes il ne sera pas lancé
directement par le BIOS. L'intérêt est de ne pas écraser le programme
d'amorce actuel du MBR. Les raisons possibles sont multiples :
- L'amorce de GRUB dans le MBR n'est pas compatible avec le BIOS
(tatouage ou autre). On marque la partition contenant l'amorce de GRUB
comme active/amorçable et on laisse au programme d'amorce du MBR le soin
de lancer l'amorce de la partition active.
- On veut conserver le programme d'amorce actuel du MBR comme chargeur
principal et chaîner le chargeur secondaire situé dans le secteur
d'amorce d'une partition. C'est particulièrement souhaitable si la plus
récente installation est provisoire, car le programme d'amorce de GRUB
n'est pas autonome : il a besoin du contenu de /boot/grub. Si on efface
la partition qui contient /boot/grub, ce qui reste de GRUB dans le MBR
ne sera plus capable d'afficher le menu de démarrage ni de lancer aucun
système d'exploitation.
- Même si on n'a pas besoin d'installer GRUB sur le système secondaire
puisque le GRUB du système principal peut parfaitement démarrer le
système secondaire, il peut être souhaitable que le système secondaire
ait un fichier de configuration grub.cfg sur lequel le GRUB principal va
s'appuyer pour créer les entrées de menu du système secondaire. Un moyen
simple que ce fichier grub.cfg existe soit mis à jour est d'installer
GRUB, même si ce n'est pas indispensable.
Pascal Hambourg
Le #26472175
Le 13/04/2018 à 23:19, a écrit :
Pour un pc portable, un seul disque dur SATA (non SSD), Windows en sda1,
Linux en sda2, la commande "grub-install /dev/sda" est fonctionnelle,
(et non "grub-install /dev/sda1") qui m'affiche un msg d'erreur.
Elle permet d'amorcer grub depuis le MBR je pense.

Oui.
Pour les autres solutions que tu décris, telle :
"...MBR comme chargeur principal et chaîner le chargeur secondaire",
quelle est la syntaxe de "grub-install" ?

Au lieu du disque, il faut spécifier la partition dans laquelle on veut
installer l'amorce de GRUB. Par exemple /dev/sda2. Si le type de contenu
de la partition ne permet pas l'embarquage, ce qui provoque le message
d'erreur à l'origine de cette discussion, il faut forcer l'installation
avec l'option --force pour utiliser les listes de blocs à la place,
moins fiables. L'installateur Debian utilise systématiquement cette option.
Pascal Hambourg
Le #26472178
Le 14/04/2018 à 09:21, Eric Degenetais a écrit :
Le 14 avr. 2018 8:54 AM, "Pascal Hambourg" écrit :
Au lieu du disque, il faut spécifier la partition dans laquelle on veut
installer l'amorce de GRUB. Par exemple /dev/sda2. Si le type de contenu de
la partition ne permet pas l'embarquage, ce qui provoque le message
d'erreur à l'origine de cette discussion, il faut forcer l'installation
avec l'option --force pour utiliser les listes de blocs à la place, moins
fiables. L'installateur Debian utilise systématiquement cette option.

Bonjour, en l'occurrence si j'ai bien compris la partition /dev/sda1
contient une installation Windows.

Oui. NTFS pour être précis.
Le message n'a t'il pas eu pour effet de
protéger cette installation ? Si on installe grub sur une partition
Windows, est-il capable d'amorcer Windows ?

Oui et non. En tout cas ce n'est pas son objectif. La mise en garde
contre l'utilisation des listes de blocs vise à protéger GRUB lui-même.
Si on force l'installation, la boot image de GRUB remplace le programme
standard du secteur d'amorce de la partition NTFS, qui charge
normalement NTLDR ou BOOTMGR. Donc GRUB ne peut plus amorcer Windows en
chaînant le secteur d'amorce de la partition puisque ce secteur contient
l'amorce de GRUB lui-même. Néanmoins il peut charger directement l'étage
suivant du démarrage de Windows, le fichier NTLDR (jusqu'à Windows XP)
ou BOOTMGR (à partir de Windows Vista) avec la commande "ntldr".
Reste à voir avec quelle méthode update-grub va intégrer automatiquement
Windows au menu de démarrage dans ce cas particulier, par chaînage du
secteur d'amorce de la partition NTFS ou par chargement du fichier
NTLDR/BOOTMGR. Il me semble que le chaînage est utilisé par défaut.
Je n'ai jamais testé.
Publicité
Poster une réponse
Anonyme