Pourquoi vouloir à tous prix mettre une partition /boot commune ( pour gagner de la place, quoi 150 … 200 Mo soyons fou 500Mo ), en bref fais comme tu le sent mais pour un poste de travail je vois pas vraiment l’utilité de séparé /boot.
[quote=“eggregor”]
En gros le PBR de la partition, lui aussi d’une taille de 512 octets n’a-t-il pas les mêmes caractéristiques que le MBR ?
D’ailleurs, c’est une connerie pour un multiboot, mais on peut installer GRUB sur une partition et donc sur son PBR, tu es bien d’accord.
Si tu as un explication sur ce premier secteur d’une partition, çà m’intéresse bien, parce que je ne trouve pas un exposé parfaitement clair à ce sujet.[/quote]
J’avoue ne pas avoir suivi toute la discussion et ne prendre que ce que je cite.
Alors très brièvement car il faudrait des pages et des pages pour aborder le sujet. Plutôt Partition Boot Sector que PBR. Il a plus ou moins les mêmes caractéristiques, mais pas toutes ni le même rôle. Le PBS va s’occuper de la partition qu’il gère et, suivant le système de fichiers installé sur la partition il y conservera des indications, par exemple avec ntfs, ou sera vide comme avec ext3/4 si tu n’y installes pas grub. Enfin, suivant l’os en cas de multiboot il jouera un rôle ou non. Il me semble que sur les derniers M.S. Windows il est sauté en ce qui concerne le mulitboot mais concerve des données du système de fichier (compléments sur le lien donné plus bas).
Si tu installes grub dans le PBS le bios va lire le MBR, exécuter les routines de démarrage et, si nécessaire, suivant ta commande sauter au PBR, c’est ce que l’on appelle le chainloading. En gros, ce que tu trouves dans ton /boot/grub/boot.img va se retrouver dans le PBS (ou le MBR) et les environ 24 Ko de /boot/grub/core.img vont se retrouver dans les secteurs suivant le PBS, mais de toute façon avant le 63 ém. Ces secteurs sont parfois touchés et modifiés, par exemple lors d’un fsck (pas systématiquement bien sûr), d’où le conseille de ne pas installer grub dans ces secteurs et le besoin d’utiliser l’option --force de grub-install.
Enfin, pour plus de détails sur le PBS avec NTFS voir :
bootmaster.filerecovery.biz/appnote3.html
ou plus général :
easeus.com/resource/partitio … sector.htm
Et, si tu veux lire simplement ces secteurs sans risque de les altérer tu peux utiliser :
sudo od -tx1z -Ax -N 512 /dev/sda pour le MBR
sudo od -tx1z -Ax -N 512 /dev/sda1 et suivants pour les PBS
@cepcasa
Merci de tes précisions.
Je ne trouve pas pour le moment, de différence autre que sémantique entre PBR et PBS à vrai dire.
Il me semble que sous Unix on parle plutôt de PBR, du moins dans les docs que je feuillette, pour les 512 premiers octets d’une partition.
Le processus de démarrage est bien:
Démarrage électrique > BIOS > MBR ou PBR > GRUB > Noyau Linux / initrd > init
Ce que je comprends en lisant avec mes lunettes ce matin, ce qui facilite la compréhension, c’est que le chargeur de démarrage GRUB limité à ses 512 octets d’espace, charge une “seconde phase”, basée sur un fichier de configuration (situé où ?) et ouvre l’interface qui permet le choix de noyau, donc de distribution dans un système multiboot, mais cela peut aussi bien concerner une seule distrib’ avec son noyau récent et ses noyaux anciens comme on sait.
Le choix étant fait, le lancement du fichier “init” correspondant s’opère.
Donc si GRUB est sur le MBR > choix de noyau sur l’interface graphique > initrd > init qui démarre tous les services, et les arrêtera d’ailleurs au shutdown.
Toutefois, puisque la commande fdisk ou l’analyse des partitions avec Gparted donne l’information d’une (et une seule) partition “amorçable” ou encore “bootable”, est-ce sur cette partition que se situe le secteur comportant le fichier pour la “seconde phase” du chargeur de démarrage ?
Cette partition “amorçable” étant sur la partition d’XP dans mon cas multiboot.
Mais cette indication a-t-elle une valeur, dans la mesure où elle apparait sur une partition “swap” sur une machine avec Ubuntu où j’avais laissé faire le partitionnement aurtomatique, et n’existe pas sur une machine multiboot avec 2 debian disposant d’une partition “boot” de 256 Mo.
J’ai l’impression d’être plus près de comprendre le démarrage machine mais pas encore vraiment au point.
[quote=“eggregor”]
Le processus de démarrage est bien:
Démarrage électrique > BIOS > MBR ou PBR > GRUB > Noyau Linux / initrd > init[/quote]
Non, le BIOS charge le MBR lequel charge un programme de boute qui peut être celui de Windows, grub, etc. La localisation de ce programme est définie à ce moment là.
Le chargeur est capable pour les plus récents de charger la configuration à partir d’un fichier (grub par exemple), sinon cette configuration est figée au moment de la construction du MBR (Lilo par exemple)
- soit de démarrer un système spécifique (Linux, BSD et quelques autres pour grub)
- soit d’enchainer sur une partition en lançant un PBR. (Chainload sous grub, lancement de la partition boutable sous Windows). Le drapeau boutable n’est utilisée que par le MBR mis par Windows.
- Le PBR peut être un MBR pour un «sous disque», il est en effet possible de partitionner une partition:
[code]Disk /dev/sda7: 4301 MB, 4301789184 bytes
255 heads, 63 sectors/track, 522 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xcc6d3704
Device Boot Start End Blocks Id System
/dev/sda7p1 1 200 1606468+ 83 Linux
/dev/sda7p2 201 522 2586465 5 Extended
/dev/sda7p5 201 250 401593+ 83 Linux
/dev/sda7p6 251 522 2184808+ 83 Linux
[/code]
dans un tel cas, ça s’enchaine.
Si un noyau linux est lancé, le noyau et chargé ainsi que l’intrd si il existe, celui ci est déplié en mémoire puis lancé, à ce moment là exactement, grub passe la main et les routines du BIOS ne peuvent plus être utilisées.
Exact. D’ailleurs sur une de mes machines en multiboot Windows/Linux la partition étendue est définie comme bootable, et l’amorce du chargeur lilo se trouve dans son EBR (extended boot record, son PBR à elle). Je voulais éviter que lilo soit dans le MBR (risque d’écrasement par Windows) et il n’y avait pas de partition principale Linux, j’ai donc trouvé que le mettre dans l’EBR était un compromis intéressant.
La structure d’un PBR est différente de celle d’un MBR. Un MBR contient une table de partition. Le seul type de PBR qui contient aussi une table de partition est l’EBR d’une partition étendue.
Comme l’a écrit cepcasa, la possibilité d’utiliser le premier secteur d’une partition comme secteur de boot dépend du type de partition. Il n’y a pas de règle générale. Le système de fichiers ext2/3 n’utilise pas le premier secteur, on peut donc s’en servir comme un secteur de boot et y stocker l’amorce du chargeur. Le secteur de boot d’un volume FAT et NTFS a un format spécifique avec des méta-données (sorte de superbloc) et de la place pour du code amorce, il faut que le chargeur soit spécifiquement prévu pour s’insérer dans cet espace afin de ne pas écraser les métadonnées. Certains systèmes de fichiers comme XFS d’après ce que j’ai lu utilisent le premier secteur qui n’est alors pas disponible comme secteur d’amorce. Concernant les partitions RAID logiciel : pour le RAID cela dépend encore du niveau de RAID (0, 1, 5…), du type de système de fichiers installé dessus et du type de superbloc (0.9, 1.0, 1.1 ou 1.2). Concernant les partitions LVM, je n’en ai aucune idée.
[quote=“eggregor”]Enfin, j’avoue que sur ma machine, bien que paramétrée multi-users, je suis le seul “user”, et que je ne me pose pas vraiment la question UID/GID.
Cependant, ayant installé SID quelques semaines après MINT, j’avais un dossier “eggregor” dans le /home, et lorsque j’ai enregistré des fichiers depuis SID, aucune précaution particulière n’a été nécessaire.[/quote]
MINT est dérivée d’Ubuntu qui est dérivée de Debian, donc on peut supposer que Mint affecte des UID/GID aux utilisateurs normaux à partir de 1000 comme Debian. Le premier utilisateur créé dans chaque distribution aura l’UID et le GID 1000. S’ils ont le même nom, alors tout ira bien.
Là où ça peut se compliquer au niveau des droits d’accès, c’est quand le même nom d’utilisateur existe dans chaque distribution mais a des UID/GID différents, ou quand des utilisateurs différents de distributions différentes ont les mêmes UID/GID.
Exemple 1 :
Utilisateur X dans distrib A créé avec l’UID 1000
Utilisateur X dans distrib B créé avec l’UID 1001
Si /home/X est créé depuis A donc avec l’UID 1000 avec les permissions standard rwxr-xr-x, alors X n’y a pas accès en écriture depuis B car l’UID est différent.
Exemple 2 :
Utilisateur X dans distrib A créé avec l’UID 1000
Utilisateur Y dans distrib B créé avec l’UID 1000
Y a accès total à /home/X depuis B et X a accès total à /home/Y depuis A car l’UID est le même.
Oui : si le paquet grub (à ne pas confondre avec le chargeur grub que les programmes du paquet tels que grub-install et grub-update ont pour rôle d’installer et de configurer) n’est pas installé sur la seconde distribution, alors la configuration de grub ne sera pas mise à jour automatiquement en cas d’ajout ou suppression de noyau. Il faudra le faire à la main. D’autre part, l’update-grub de la première distribution risque de ne pas savoir faire la distinction entre les noyaux des deux distributions, ce qui est important pour indiquer la bonne option root= à chacun.
Oui, pas de souci de ce côté. A note qu’il en serait de même avec un /boot séparé mais non partagé.
Oui et non. Comme je l’ai écrit plus haut, si le paquet grub n’est pas installé sur la deuxième distribution, il n’y aura pas ce souci mais il faudra tenir à jour la configuration de grub manuellement en ce qui concerne les noyaux de cette distribution. En revanche si le paquet grub est installé (mais pas le chargeur), alors effectivement on peut craindre des soucis notamment si les deux versions de grub sont proches (donc pas de souci entre grub 1 et grub 2 qui utilisent des fichiers de configuration différents) mais différentes avec des options incompatibles.
Ok, ç’est le genre de truc que je “pressentais” sans savoir et qui me faisait déconseiller cette bidouille en multiboot.
Sympa, refaire les ln -s de chaque kernel et recréer les initramfs et les fichiers de chaque système à la main et à chaque changement de kernel 
J’ajouterais qu’avec des dossiers/fichiers partagés dans le /boot, ça peut virer en joyeux boxon
[hs]
[quote=“fran.b”] Device Boot Start End Blocks Id System
/dev/sda7p1 1 200 1606468+ 83 Linux
/dev/sda7p2 201 522 2586465 5 Extended
/dev/sda7p5 201 250 401593+ 83 Linux
/dev/sda7p6 251 522 2184808+ 83 Linux[/quote]
Tu as une partition étendue dans une partition étendue ? 
[/hs]
ben je l’ai fait pour l’occasion, c’est juste un exemple, je ne vois pas l’intérêt d’une telle usine à gaz…
Ce sont les scripts du paquet noyau qui gèrent la création de l’initramfs et des liens symboliques dans la racine. De toute façon grub n’utilise pas les liens symboliques dans la racine mais directement les fichiers images et initrd présents dans /boot.
Le seul travail restant consiste à mettre à jour /boot/grub/menu.lst ou son équivalent pour grub2. Bien sûr rien n’empêche d’écrire un script qui fera ça automatiquement, mais c’est du boulot en plus.
[quote=“eggregor”]@cepcasa
Le processus de démarrage est bien:
Démarrage électrique > BIOS > MBR ou PBR > GRUB > Noyau Linux / initrd > init
Ce que je comprends en lisant avec mes lunettes ce matin, ce qui facilite la compréhension, c’est que le chargeur de démarrage GRUB limité à ses 512 octets d’espace, charge une “seconde phase”, basée sur un fichier de configuration (situé où ?) et ouvre l’interface qui permet le choix de noyau, donc de distribution dans un système multiboot, mais cela peut aussi bien concerner une seule distrib’ avec son noyau récent et ses noyaux anciens comme on sait.
Le choix étant fait, le lancement du fichier “init” correspondant s’opère.
Donc si GRUB est sur le MBR > choix de noyau sur l’interface graphique > initrd > init qui démarre tous les services, et les arrêtera d’ailleurs au shutdown.
Toutefois, puisque la commande fdisk ou l’analyse des partitions avec Gparted donne l’information d’une (et une seule) partition “amorçable” ou encore “bootable”, est-ce sur cette partition que se situe le secteur comportant le fichier pour la “seconde phase” du chargeur de démarrage ?
Cette partition “amorçable” étant sur la partition d’XP dans mon cas multiboot.
Mais cette indication a-t-elle une valeur, dans la mesure où elle apparait sur une partition “swap” sur une machine avec Ubuntu où j’avais laissé faire le partitionnement aurtomatique, et n’existe pas sur une machine multiboot avec 2 debian disposant d’une partition “boot” de 256 Mo.
J’ai l’impression d’être plus près de comprendre le démarrage machine mais pas encore vraiment au point.[/quote]
Plus exactement, mais en résumé, le bios lit le MBR puis trouve le “nombre magic”, 55 aa à la fin des premiers 512 octets, qui lui est indispensable sur une table ms.dos pour être déclarée valable. Alors il charge le bootloader.
Comme déjà dit, Grub pourra être installé dans le MBR, alors le core.img que l’on peut représenter par stage2 est installé dans les secteurs suivant le mbr. Ce core.img contient ce qui est indispensable à grub pour fonctuionner, y compris les modules nécessaires pour lire le système de fichier contenant la configuration de grub, le grub.cfg. Il y aura aussi, suivant le cas, les modules pour lvm et ou raid, etc. etc.
Aussi, dans ces secteurs jouxtant le mbr, sera codé l’emplacement de ce fichier de configuration. Si tu affiches ces secteurs tu pourras y trouver l’emplacement de la partition (fs) par exemple ainsi :
0000410: cf54 0000 0100 0000 ffff ffff 282c 6d73 .T…(,ms
0000420: 646f 7332 292f 626f 6f74 2f67 7275 6200 dos2)/boot/grub.
C’est le nouveau mode de désignation qui avant était (hd0,2).
Et, si tu installes grub dans le boot sector d’une partition, tu auras donc le stage1 dans ces 512 octets et le reste dans les octets suivants. Le bios n’ayant pas trouvé de boot loader dans le mbr va continuer sa recherche de nombres magiques, et suivant le cas de partition amorçable ainsi que d’un boot loader.
À noter tout de même que grub n’a pas besoin qu’une partition soit amorçable puisqu’il a ses propres routines et sait où trouver le complément et son fichier de configuration.
Donc, libre à toi de mettre le drapeau de boot sur une partition, mais avec grub c’est inutile.
Je ne connais pas le boot loader Microsoft, et ne sais pas s’il a toujours besoin de trouver une partition amorçable.
Dans le cas du noyau du système gérant le grub, avec les noyau “natifs” d’accord. Mais ceux en plus, ceux des “systèmes parasites”, il ne sont pas ignorés? 
[quote=“PascalHambourg”]De toute façon grub n’utilise pas les liens symboliques dans la racine mais directement les fichiers images et initrd présents dans /boot.[/quote]
C’est ce que je me demandais. Si grub peut mettre à jour le système disons “natif”, la mises à jour d’un autre système ex: vmlinuz => vmlinuz.old doit être faite à la main dans ce cas.
C’est juste que je ne savais pas que c’était faisable sous linux C’est l’utilitaire disklabel en gérant les offset aussi ?
[quote=“PascalHambourg”]
Oui et non. Comme je l’ai écrit plus haut, si le paquet grub n’est pas installé sur la deuxième distribution, il n’y aura pas ce souci mais il faudra tenir à jour la configuration de grub manuellement en ce qui concerne les noyaux de cette distribution. En revanche si le paquet grub est installé (mais pas le chargeur), alors effectivement on peut craindre des soucis notamment si les deux versions de grub sont proches (donc pas de souci entre grub 1 et grub 2 qui utilisent des fichiers de configuration différents) mais différentes avec des options incompatibles.[/quote]
en effet.
Il est alors préférable de n’installer grub-pc que dans une seule distribution, de créer des scripts /etc/grub.d/11_linux qui seront chargés de faire un fichier de lancement des autres distributions en prenant les liens /initrd.img et /vmlinuz plutôt que les dédiés dans /boot.
Ne pas oublier aussi de modifier les différents fichiers dans /etc/kernel/
Bref, un boot commun peut se comprendre à la rigueur sur un petit serveur si l’on veut avoir une petite distribution en complément en cas de dépannage, mais pour quelqu’un qui veut tester plusieurs ditribs c’est se compliquer la vie inutilement.
Dans le cas du noyau du système gérant le grub, avec les noyau “natifs” d’accord. Mais ceux en plus, ceux des “systèmes parasites”, il ne sont pas ignorés?[/quote]
Comment ça, ignorés ?
Il y a deux opérations bien distinctes qui sont effectuées lors de l’installation/suppression du noyau :
- la création/suppression de l’initramfs (initrd) dans /boot en exécutant update-initramfs et la mise à jour des liens symboliques /vmlinuz* et /initrd*, indépendamment du chargeur ;
- la mise à jour de la configuration du chargeur s’il existe, en exécutant un programme lié au chargeur comme update-grub pour grub.
La première opération est systématique, la seconde n’a lieu que si un chargeur est installé dans la distribution. Donc il faut mettre à jour le chargeur de la distribution principale manuellement ou installer son propre script.
Là où ça se corse, c’est ce qui va se passer lorsque la configuration du chargeur est mise à jour depuis la distribution principale : comment vont être traités les noyaux des systèmes secondaires ? Si update-grub scanne bêtement les fichiers vmlinuz* et initrd* dans /boot, il ne va pas faire de distinction avec les noyaux principaux et va proposer les noyaux secondaires pour démarrer la distribution principale, ce qui ne marchera pas très bien puisque les modules de ces noyaux ne se trouvent pas sur la partition racine du système principal.
Autre chose, autant désactiver aussi os-prober qui risque de compliquer lui aussi les choses.
Pour les autres initrd et compagnie on peut modifier le comportement de grub et le limiter à un certain nombre de noyau ou lui demander de les traiter différemment. C’est tout l’interêt de grub-pc et de ses scripts.
Édit : en complément, un ami m’apporte les précisions suivantes. Je le cite :
"le drapeau d’amorce d’une partition,
il n’y a pas que pour Microsoft qu’il est indispensable,
mais également parfois pour le BIOS lui-même.
C’est le cas sur une de mes configurations avec un BIOS
Insyde Software. Je n’ai aucune partition windows, néanmoins
le BIOS refusera de démarrer sur le disque dur si celui-ci
n’indique pas un drapeau d’amorce sur l’une des partitions
principales.
Le message est alors Hard disk boot sector invalid
Press ‘H’ to retry Hard Disk, any other key for floppy
Idem si pour cette même configuration je démarre sur une
clé usb à laquelle j’ai ôté le drapeau."