Ubuntu-fr

YannUbuntu

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

Un bug que je suivais vient d'être signalé comme doublon d'un meta-bug bien en rapport avec cette discussion:
Non trival grub2 installs no longer fit in small embed areas

---

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

Nasman

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

Salut,
Salut Yann,

Je viens apporter un peu de lumière (je l'espère).
Il s'agit de grub 2 sur clef USB.
Cela marche avec Ubuntu 10.04/12.04, et aussi sur openSUSE 12.2 (par grub2-install /dev/sdc et le module Démarrage de Yast (Yet another setup tool!).
Cette clef USB  sert à démarrer LTS 12.04 et les autres systèmes installés, dont XP et openSUSE.
Infos utiles :

# parted -l

Model: JetFlash TS2GJFV30 (scsi)
Disk /dev/sdc: 2064MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
1      32,3kB  2064MB  2064MB  primary  fat32        boot, type=0b

Edit :
Les 32,3kB correspondent "très approximativement" à :

63 secteurs (de 0 à 62) + 1 (le secteur 63) = 64 secteurs.
1 secteur=512 octets= 0,5 ko=0,5kB(bytes).
Donc 64 secteurs==>64x0,5=32ko
Je ne sais pas pourquoi "32,3ko". Peut-être un alignement.

Une des structures classiques de partitions est :
secteurs 0 = mbr
secteurs 1-62 reste de la première piste (et première tête)

secteur 63, début de la première partition principale, correspondant au premier secteur de la deuxième tête du premier cylindre. La première partition se termine à la fin d'un cylindre (soit au secteur 62 de la dernière tête 254)

Deuxième partition primaire, commence au premier secteur de la première tête d'un nouveau cylindre.

En bref les 63 premiers secteurs du disques (0-62) ne doivent pas être utilisables par  une partition, soit 63x512=32256 octets, soit (en arrondissant) 32,3 ko ou 31,5 kio

Edit : Cette structure correspond au type d'alignement sur les cylindres - excepté pour la première partition principale (pour éviter de perdre trop de place). De plus en plus on constate un alignement au niveau du Mio du fait de l'abandon de l'ancienne notion de tête, secteur et cylindre (avec ses limitations de taille) liée à des médias de technologie et géométries différentes (ssd, mémoire flash). La performance devient la priorité et on recherche un alignement entre le média et la ram. En conséquence on arrive sur un alignement sur une puissance de 2, soit 1048576 octets (1 Mio) qui correspond à un multiple de 2048 secteurs de 512 octets. C'est pourquoi on voit de plus en plus la première partition principale commencer au secteur 2048 (et un espace non alloué vu par gparted de l'ordre du Mio avant cette première partition).

Dernière modification par Nasman (Le 02/10/2012, à 09:15)

---

PC fixe sous Bionic 64 bits et portable avec Focal 64 bits

cep

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

En regardant le code indiqué par cep, j'en conclue que grub-install retourne systématiquement un message d'erreur lorsqu'il n'a pas assez de place. (à vérifier cependant)

Rien de plus simple pour le vérifier :
http://cyrille-borne.com/forum/showthread.php?tid=1353

Encore une fois, c'est une caractéristique de Grub de vérifier s'il a la place nécessaire. Imaginez ce qu'il en résulterait s'il continuait son installation, et ce qui serait touché.

---

Mon Seen This

Arbiel

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

Bonjour

Concernant l'option --force. Si 'lon n'installe pas core.img dans les secteurs suivant le mbr mais dans le boot sector d'une partition on a considéré que ce n'était pas forcément une bonne idée

Veux-tu dire par là qu'il fait utiliser l'option --force pour indiquer que l'on veut vraiment installer grub sur une partition, bien que ce soit une mauvaise idée, ou du moins une idée pas très bonne ?
Si telle n'est pas l'utilité de --force, à quoi sert-elle donc ?
Et si elle ne sert qu'à installer un grub qui ne peut pas fonctionner, ne faut-il pas en demander la suppression ?

Arbiel

---

Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04, GNOME 3.36.8
24.04 en cours de tests
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

cep

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

Bonjour

Concernant l'option --force. Si 'lon n'installe pas core.img dans les secteurs suivant le mbr mais dans le boot sector d'une partition on a considéré que ce n'était pas forcément une bonne idée

Veux-tu dire par là qu'il fait utiliser l'option --force pour indiquer que l'on veut vraiment installer grub sur une partition, bien que ce soit une mauvaise idée, ou du moins une idée pas très bonne ?
Si telle n'est pas l'utilité de --force, à quoi sert-elle donc ?
Et si elle ne sert qu'à installer un grub qui ne peut pas fonctionner, ne faut-il pas en demander la suppression ?

Arbiel

Utiliser les blocklists  n'est pas l'usage conseillé ni la solution la plus solide. Il est conseillé d'installer classiquement Grub sur le device /dev/sda ou /dev/sdb ou autre. Mais Si l'on veut le faire ailleurs, et parfois c'est nécessaire, alors il faut utiliser l'option --force qui posera un grub tout à fait fonctionnel dans les secteurs prévus à cet effet. De nombreuses installations sont faites ainsi, par exemple si on a plusieurs distributions linux et que l'on veut les gérer chacune avec son Grub. On utilisera alors le chainload (ou mieux le configfile de grub2 à grub2) pour passer de l'une à l'autre.

---

Mon Seen This

YannUbuntu

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

Pour info j'ai fait un petit résumé du meta-bug ici: https://bugs.launchpad.net/ubuntu/+sour … ug/1059827 . En gros 3 situations:
1) le disque avec l'embed area <32ko  (= les exemples de ahler et cep)
2) embed area de 32ko , mais les modules RAID+LVM qui grossissent trop le core
3) embed area de 32ko , mais le module BTRFS qui grossit trop le core

Les dernières questions que je me pose:
- quelles autres situations font que core.img ne tient plus dans les 32ko habituels?  (par exemple, est-ce que LVM seul, ou bien RAID seul fait dépasser cette limite?)
- est-que l'installateur Ubuntu prévient lorsque l'installation de GRUB plante?

Dernière modification par YannUbuntu (Le 02/10/2012, à 14:39)

---

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

cep

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

Tu te et tu poses beaucoup de questions mais les réponses ont été apportées depuis longtemps. Il suffit de lire la documentation, y compris la mailling list de Grub dev, les rapports de bugs sur Debian, sur Fedora, sur d'autres distributions, sur les pages de SuperGrubDisk.

D'ailleurs et ceci entre parenthèse, si la doc était lue avant certains reports bugs ils seraient peut-être moins nombreux, avec moins de doublons, et donc plus facielement gérables. Fin de la parenthèse

Alors, le core.img. Oui il arrive que le core.img fasse plus de 32 ko dans certains cas. Pour le constater il suffit de jouer avec grub-mkimage --module=xx etc.

La solution ? sauf à réduire les modules de Grub, (ce qui ne va pas dans le sens de l'histoire et de ce que demandent en général les users qui veulent plus de possibilités, la gestion de certains besoins de "secure", etc. ) la solution donc est de modifier la première partition en sachant tout de même que maintenant, et par le jeu de l'alignement par exemple (voir le poste de Nasman) les 62 secteurs sont obsolètes. De même l'usage de plus en plus fréquent de gpt va rendre cette histoire de 62 secteurs inutile

Savoir si l'installeur de Ubuntu prévient ? lire les logs de l'installation et voir s'il y a un warm pour grub-setup.

---

Mon Seen This

jamesbad000

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

Ajout du module lvm seul :

root@Miragek1204:~# grub-install --modules=lvm /dev/sdb                                                                       
Installation finished. No error reported.                                                                                     
root@Miragek1204:~# ls -l /boot/grub/core.img                                                                                 
-rw-r--r-- 1 root root 29912 oct.   2 15:35 /boot/grub/core.img                                                               

ca passe

edit :
raid seul (il y en a plusieurs, j'ai pris le plus gros)

root@Miragek1204:~# grub-install --modules=raid6rec /dev/sdb
Installation finished. No error reported.
root@Miragek1204:~# ls -l /boot/grub/core.img 
-rw-r--r-- 1 root root 30756 oct.   2 15:40 /boot/grub/core.img

Ca passe.

edit2 :
Pour le BTRFS, ou les combinaison complexe, la solution (en dehors de faire l'alignement des partitions sur 1Mo) est de faire une partition boot séparé de type ext hors LVM... Du coup core.img embarquera le module EXT2 au lieu de BTRFS et autres..

Dernière modification par jamesbad000 (Le 02/10/2012, à 16:10)

---

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

cep

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

Construction de différents core.img pour en vérifier la taille sans avoir à les installer sur le système :

Voir :
http://cyrille-borne.com/forum/showthre … 3#pid19953

On trouve une liste des modules mis d'office et disponibles dans le fichier
/lib/grub/i386-pc/moddep.lst

Remplacer /i386-pc/ pour les autres architectures.

---

Mon Seen This

YannUbuntu

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

Merci à vous 2.
Concernant les modules, je viens de remarquer qu'ils se trouvent dans /usr/lib/grub/i386-pc , du coup on peut connaître directement leur taille.
Savez-vous s'il existe quelquepart un descriptif de ces modules? (rien vu dans la doc grub)

Concernant l'installateur, je ne parle pas des logs mais d'un vrai warning visible à coup sûr par l'utilisateur, type zenity ou autre, histoire que l'utilisateur sache que Ubuntu ne démarrera pas après install.

---

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

cep

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

Concernant les modules, je viens de remarquer qu'ils se trouvent dans /usr/lib/grub/i386-pc , du coup on peut connaître directement leur taille.

mais tu ne peux pas additionner leur taille pour connaître le poids final de core.img

---

Mon Seen This

jamesbad000

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

Concernant les modules, je viens de remarquer qu'ils se trouvent dans /usr/lib/grub/i386-pc , du coup on peut connaître directement leur taille.

pas tout à fait :

root@Miragek1204:~# grub-install /dev/sdb
Installation finished. No error reported.

root@Miragek1204:~# ls -l /boot/grub/core.img 
-rw-r--r-- 1 root root 27049 oct.   2 17:34 /boot/grub/core.img

root@Miragek1204:~# grub-install --modules=lvm /dev/sdb
Installation finished. No error reported.

root@Miragek1204:~# ls -l /boot/grub/core.img 
-rw-r--r-- 1 root root 29912 oct.   2 17:34 /boot/grub/core.img

root@Miragek1204:~# ls -l /boot/grub/lvm.mod 
-rw-r--r-- 1 root root 7216 oct.   2 17:34 /boot/grub/lvm.mod

on voit bien que le core.img a grossis moins que la taille du module. Soit parce que celui-ci a été déshabillé de données nécessaire uniquement au "linkage", soit parce que le contenu du core.img est comprimé (voir les 2).

Dernière modification par jamesbad000 (Le 02/10/2012, à 17:51)

---

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

Compte supprimé

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

Pour info j'ai fait un petit résumé du meta-bug ici: https://bugs.launchpad.net/ubuntu/+sour … ug/1059827 . En gros 3 situations:
1) le disque avec l'embed area <32ko  (= les exemples de ahler et cep)
2) embed area de 32ko , mais les modules RAID+LVM qui grossissent trop le core
3) embed area de 32ko , mais le module BTRFS qui grossit trop le core

Les dernières questions que je me pose:
- quelles autres situations font que core.img ne tient plus dans les 32ko habituels?  (par exemple, est-ce que LVM seul, ou bien RAID seul fait dépasser cette limite?)
- est-que l'installateur Ubuntu prévient lorsque l'installation de GRUB plante?

Bonjour,
je pense que je me suis retrouvé dans le point 2) à l'époque du passage à la 12.04 en RAID10 logiciel quand RAID+LVM a sauté même après réinstallation.
J'ai changé d'ordinateur pour un RAID1 logiciel, que j'ai prêté et qui m'a forcé récemment à réinstaller mon "super-ordinateur", sauf que cette fois je l'ai installé à partir du disque alternate 12.04.1 en RAID5 logiciel sur 4 disques.

ludovic@ubuntu-LDVC:~$ cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10] 
md0 : active raid5 sdd1[3] sdb1[1] sdc1[2] sda1[0]
      1465148928 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      
unused devices: <none>

ludovic@ubuntu-LDVC:~$ sudo parted -l
Modèle: ATA WDC WD5000AADS-0 (scsi)
Disque /dev/sda : 500GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos

Numéro  Début   Fin    Taille  Type     Système de fichiers  Fanions
 1      1049kB  500GB  500GB   primary                       démarrage, raid


Modèle: ATA WDC WD5000AADS-0 (scsi)
Disque /dev/sdb : 500GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos

Numéro  Début   Fin    Taille  Type     Système de fichiers  Fanions
 1      1049kB  500GB  500GB   primary                       raid


Modèle: ATA WDC WD5000AADS-0 (scsi)
Disque /dev/sdc : 500GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos

Numéro  Début   Fin    Taille  Type     Système de fichiers  Fanions
 1      1049kB  500GB  500GB   primary                       raid


Modèle: ATA WDC WD5000AADS-0 (scsi)
Disque /dev/sdd : 500GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos

Numéro  Début   Fin    Taille  Type     Système de fichiers  Fanions
 1      1049kB  500GB  500GB   primary                       démarrage, raid


Modèle: Mappeur de périphériques Linux (linear) (dm)
Disque /dev/mapper/Ubuntu-Datas : 1445GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : loop

Numéro  Début  Fin     Taille  Système de fichiers  Fanions
 1      0,00B  1445GB  1445GB  ext4


Modèle: Mappeur de périphériques Linux (linear) (dm)
Disque /dev/mapper/Ubuntu-home : 20,0GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : loop

Numéro  Début  Fin     Taille  Système de fichiers  Fanions
 1      0,00B  20,0GB  20,0GB  ext4


Modèle: Mappeur de périphériques Linux (linear) (dm)
Disque /dev/mapper/Ubuntu-rac : 30,0GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : loop

Numéro  Début  Fin     Taille  Système de fichiers  Fanions
 1      0,00B  30,0GB  30,0GB  ext3


Modèle: Mappeur de périphériques Linux (linear) (dm)
Disque /dev/mapper/Ubuntu-swap : 5000MB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : loop

Numéro  Début  Fin     Taille  Système de fichiers  Fanions
 1      0,00B  5000MB  5000MB  linux-swap(v1)


Erreur: Impossible d'ouvrir /dev/md0 - étiquette de disque non reconnue. 

ludovic@ubuntu-LDVC:~$ sudo lvs
[sudo] password for ludovic: 
  LV    VG     Attr   LSize  Origin Snap%  Move Log Copy%  Convert
  Datas Ubuntu -wi-ao  1,31t                                      
  home  Ubuntu -wi-ao 18,62g                                      
  rac   Ubuntu -wi-ao 27,94g                                      
  swap  Ubuntu -wi-ao  4,66g  

Le début s'est mis d'office à 1049 ko (je n'avais pas regardé avant en version Ubuntu 12.04).

Pour l'instant ça fonctionne mais je stresse un peu comme... pas envie de perdre quelques fichiers et de devoir tout réinstaller. Mais je pense que ça tient mieux car la mise à jour du noyau n'a pas fait tout planter cette fois.

PS : je ne retrouve pas le post en question, le pire est que c'est moi qui l'ai écrit...
En résumé : Grub sautait lors de la mise à jour du noyau, surement pour les causes indiquées par YannUbuntu (pas assez de place pour les modules RAID et LVM...

Il me semble en effet qu' Ubuntu prévient quand Grub ne veut pas bien s'installer. Mon soucis à l'époque est que Grub ne semblait s'installer que sur un seul disque dur du RAID10, par exemple sda, et en simulation de panne (avec le simple débranchement de sda) le RAID10 ne démarrait plus, ne bootait plus à partir d'un des disques restants...

Je n'ai pas fait de test de simulation de panne avec le RAID5, je sauvegarde régulièrement et je ne pas même pas si Ubuntu démarrerait si je croisait l'ordre des disques durs mais cette fois j'ai fait attention de bien installer Grub dans /dev/sda /dev/sdb /dev/sdc /dev/sdd lors de l'installeur d'Ubuntu 12.04.1 alternate.

édit :

ludovic@ubuntu-LDVC:~$ ls -l /boot/grub/core.img 
-rw-r--r-- 1 root root 32531 sept. 30 05:54 /boot/grub/core.img

Dernière modification par Compte supprimé (Le 09/10/2012, à 07:25)

cep

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

Salut,
Pas de stress, comme tu peux le voir dans la sortie parted il y a largement la place pour installer le core.img puisque, comme c'est maintenant le cas lors des partitionnements, l'alignement des partitions se fait sur de nouvelles bases.
En ce qui te concerne ta partition débute à 1049kB comparé aux 33 K de ton core.img.
Il est certain que sur un ancien mode de partitionnement sur 63 secteurs le core.img était à problème.

---

Mon Seen This

Compte supprimé

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

Merci Cep,
en effet super-ordinateur (nom rigolo à mon sens) a été mis en test M.A.O. à partir d'Ubuntu 10.04 LTS.
Je suis rassuré pour ta confirmation, mais cela ne m'empêche pas de faire mes sauvegardes

cep

Re : GRUB plante quand l'espace MBR->1e partition est trop petit

en effet super-ordinateur (nom rigolo à mon sens) a été mis en test M.A.O. à partir d'Ubuntu 10.04 LTS.

Belle bête
Pour les sauvegardes, bah c'est toujours préférable.
Bonne continuation.

---

Mon Seen This