# grub-install /dev/sda1
me donne ce long message :
"Le syst=E8me de fichiers NTFS ne prend ps en charge l'empaquetage.
Grub ne doit pas =EAtre install=E9 sur cette configuration qu'en utilisant =
la=20
liste de blocs, qui ne sont pas FIABLES donc d=E9conseill=E9es.
Erreur, refus de continuer avec les listes de blocs"
Pourtant, en rebootant, Grub fonctionne,
sauf le menu de boot en caract=E8res ultra petits.
Mon syst=E8me 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=E8s un "apt-get upgrade" de Jessie.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
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.
Le 11/04/2018 à 11:38, Klaus Becker a écrit :
Le mercredi 11 avril 2018, 11:31:27 CEST andre_debian@numericable.fr 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.
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
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é
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 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 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.
Le 13/04/2018 à 11:11, andre_debian@numericable.fr 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.
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 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.
Le 13/04/2018 à 23:19, andre_debian@numericable.fr 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.
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 14/04/2018 à 09:21, Eric Degenetais a écrit :
Le 14 avr. 2018 8:54 AM, "Pascal Hambourg" a é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é.
Le 14/04/2018 à 09:21, Eric Degenetais a écrit :
Le 14 avr. 2018 8:54 AM, "Pascal Hambourg" <pascal@plouf.fr.eu.org> a
é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.
Le 14 avr. 2018 8:54 AM, "Pascal Hambourg" a é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é.
