GRUB : listes de blocs, erreur
Le
andre_debian
Bonjour,
# grub-install /dev/sda1
me donne ce long message :
"Le système 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 déconseillées.
Erreur, refus de continuer avec les listes de blocs"
Pourtant, en rebootant, Grub fonctionne,
sauf le menu de boot en caractères ultra petits.
Mon système est Debian Jessie, avec une partition Windows (sda1)
et d'autres partitions de sauvegarde GNU/Linux (sda3, sda4).
Cette erreur de grub est survenue après un "apt-get upgrade" de Jessie.
Merci,
André
# grub-install /dev/sda1
me donne ce long message :
"Le système 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 déconseillées.
Erreur, refus de continuer avec les listes de blocs"
Pourtant, en rebootant, Grub fonctionne,
sauf le menu de boot en caractères ultra petits.
Mon système est Debian Jessie, avec une partition Windows (sda1)
et d'autres partitions de sauvegarde GNU/Linux (sda3, sda4).
Cette erreur de grub est survenue après un "apt-get upgrade" de Jessie.
Merci,
André
"empaquetage", vraiment ? Ce n'est pas plutôt "embarquage" (embedding) ?
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.
Non, c'est faux.
Erreur de ma part, c'est bien "embarquage", désolé.
Le 11/04/2018 à 11:38, Klaus Becker a écrit :
Si, c'est bien /dev/sdx soit /dev/sda
André
C'est utile si tu as plusieurs installation sur la même machine par
exemple. La distribution principale installera grub sur /dev/sdx, elle.
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.
Oui.
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.
Oui. NTFS pour être précis.
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é.