Le démarrage d'un PC du POST jusqu'au menu GRUB (inclus)

Bonsoir
J’ai lus cette article :"De la mise sous tension à l’invite de commande de Bash"
http://guidespratiques.traduc.org/vf/From-PowerUp-To-Bash-Prompt-HOWTO.html
et je n’ai pas compris quelle chose, supposons que j’utilise grub. Lors que le BIOS verifie les préphiriques, il lit les 512 bits de disque-dur (dans mon cas), ça presente la première phase (stage 1). ensuite, pour passer au stage 2, est-ce que ce stage se trouve dans la partition sur laquelle /boot sera mounté aprés le chargement de noyau ?

Supposant que cette partition est /dev/sda1 et elle est formatée en ext3. Logiquement le code sur 512 bits de MBR doit pouvoir les inodes de l’ext3 . donc si je change le formatage des données sur le /dev/sda1 en ext2. et je conserve les même fichiers sur la partition, le système ne doit pas être capable de démarrer ?
autre question :
Est-ce que le stage 1.5 est toujours utilisé ?
Si je réinstalle windows, et je conserve juste le MBR, est-ce je serai capable de remettre en marche mon grub ?
(sachant que le stage 1.5 se trouve sur les 30Ko aprés le MBR et avant la première partition)
merci

EDIT: Pourrais-tu modifier légèrement le titre de ce fil en le remplaçant par :

Le démarrage d’un PC du POST jusqu’au menu GRUB (inclus).

Merci.

==========

En fait, il ne s’agit pas de bits mais de Bytes (un Byte = 8 bits => un octet).
B => byte
b => bits

==========
NOTE: Tout d’abord, je tiens à préciser que …
dans ce qui suit, “GRUB” = “GRUB version 2”.
les valeurs indiquées sous la forme XXh sont des valeurs en base hexadécimale.
le MBR cité dans ce post est du type mdsos non GPT (pour GPT, c’est tout une autre histoire…dépendant de l’UEFI)

==========
La lecture des 512 premier octets (qu’on appelle aussi MBR) du premier périphérique de mémoire de masse ne représente pas la première phase (stage 1) du chargeur de boot GRUB.

==========
Après l’exécution de la phase du POST, le BIOS (enfin le programme inscrit dans le BIOS) poursuit l’exécution de ses instructions par son programme de chargeur d’amorçage (bootstrap loader).

Au cours de la phase du POST, le programme du BIOS a déjà listé tous les périphériques de type “mémoire de masse” (disque, disquette, clef USB, carte SD, cdrom etc…) auxquels il pourrait avoir accès.
Il va maintenant essayer de “passer la main” (chain loading) aux programmes suceptibles d’être inscrits dans ces mémoires de masses.

Pour cela, le “bootstrap loader” du BIOS va d’abord lire le premier secteur du premier périphérique de type “mémoire de masse”, afin de savoir s’il s’agit d’un “secteur d’amorçage”.

Si ce premier secteur est marqué par le “nombre magique” (AA55h à l’offset 1FEh => 2 dernier octets du secteur) il va en déduire qu’il s’agit certainement d’un secteur d’amorçage, et il va copier les instruction contenues dans le “bootstrap code area” de ce MBR en mémoire (0000h:7C00h) afin de pour pouvoir lancer l’exécution des instructions (chain loader) de ce “bootstrap code”.

Ces instructions avaient été inscrites dans le MBR par le programme d’installation de GRUB “grub-setup” (voir aussi “man grub-install”), en utilisant le fichier “/boot/grub/boot/img”.

C’est seulement l’exécution de ces instructions (extraites du premier secteur) qui corresponds effectivement à la phase 1 de l’exécution du programme de chargeur de boot GRUB.

Pas si vite, si “Stage 1” peut effectivement lancer directement “Stage 2”, il doit d’abord “passer la main” (chain loader) à “stage 1.5”.

Les instructions à exécuter pour ce “stage 1.5” sont inscrites dans les 30kB qui suivent le MBR, et avant le début de la première partition.
L’exécution de “Stage 1.5” a pour finalité de charger en mémoire les pilotes qui vont permettre à GRUB d’accéder aux différents systèmes de fichiers du support.

Une fois que “Stage 1.5” a finit de charger les pilotes pour les systèmes de fichiers, il peut “passer la main” à “stage 2”.
“stage 2” ayant accès au fichier “/boot/grub/grub.cfg”, il peut maintenant afficher le menu de démarrage qui permettra à l’utilisateur de choisir le système d’exploitation à démarrer.

Si tu y arrive, tu nous expliquera comment tu as fait.

=========================================
Liens:

POST (Power-On_Self-Test)
Chain loading
GNU GRUB
MBR (Master Boot Record)
GPT (GUID Partition Table)
UEFI (Unified Extensible Firmware Interface)

Salut,

Alors, là, bravo !!

Mon nano-neurone est en extase. Tout compris.

Ce sujet arrivé à terme (si tenté … ) le wiki en sera ravi, également.

MicP :clap: :smiley:

@ BelZéButh Merci beaucoup. :slightly_smiling:

Qui plus est, les liens qui vont bien … :023 :clap:

:slightly_smiling:

J’ai aussi tout compris… presque… :stuck_out_tongue:

cependant, j’ai fait un beau copié/collé, pour les longues soirées d’hiver :slightly_smiling:

Merci et bravo pour ta pédagogie MicP :slightly_smiling:

Si tu y arrive, tu nous expliquera comment tu as fait.
[/quote]
D’abord merci beaucoup pour votre excellente explication :wink:
Je voulais dire, si je fais avant la réinstallation de windows :

et l’inverse aprés.
est-ce que le windows ne va pas écraser le stage 1.5 ?

C’est plus que probable, c’est pour cela que tous le monde recommande de tenter une install multiboot
seulement après avoir installé win.

Quelle serait la version de win que tu voudrais installer ?

C’est plus que probable, c’est pour cela que tous le monde recommande de tenter une install multiboot
seulement après avoir installé win.

Quelle serait la version de win que tu voudrais installer ?[/quote]
windows 7

Le problème qu’il risque de se passer, c’est que seven vienne installer son GPT à sa sauce.
(j’avais mis un lien sur GPT dans le deuxième post de ce fil).
Mais c’est sûr qu’il y en a de plus au courant que moi sur le problèmes posés par seven et le multiboot,
alors avant de dire des bêtises sur un système que j’utilise pas, je préfère laisser les autres en parler.

Mais combien de disques as-tu sur ta machine ?

[quote=“MicP”]
Mais combien de disques as-tu sur ta machine ?[/quote]
un seule disques

Dommage!..
j’avais pensé à l’utilisation d’un disque par système en priant pour que seven ne vienne pas polluer l’autre MBR.

Ceci dit, installe seven en essayant de lui demander (s’il veut bien) ne pas prendre toute la place sur le disque,
puis toutes les mises à jours et pilotes, enfin tout ce qu’il faut pour que seven se sente bien chez lui.
Ensuite, on verra ce qui se passe au niveau du multiboot: MBR, GPT ?
C’est pas impossible non plus, et au pire, une clef usb pourra héberger les stage1, stage 1.5 pour lancer Linux.

EDIT:
@ alpha Impeccable pour la modification du titre du fil.
Merci