Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Partition GPT, Grub... et RAID soft

22 réponses
Avatar
Francois Lafont
Bonjour à tous,

J'avais déjà initié un fil précédent à propos de GPT and co. et
je pensais que c'en était fini pour moi des questions là dessus
mais en fait j'ai besoin de mettre en place un RAID soft (RAID 1
en l'occurrence) au dessus de tout ça et là tout ce que j'ai essayé
a échoué. À la fin de l'installation (Ubuntu 14.04 ou Jessie) j'ai
un truc qui ne boote pas.

Sans RAID soft, j'en suis resté à ceci qui fonctionne très bien :

A. En Bios-UEFI, partition GPT du disque système avec :
1. une partition de 250 MB de type "Bios-UEFI".
2. une partition de N GB de type EXT4 (par exemple) montée sur /.
3. une partition swap etc.

B. En Bios-legacy, partition GPT du disque système avec :
1. une partition de 250 MB de type "non-utilisée" au cas où un jour
je décide de basculer le Bios en UEFI.
2. une partition de 1 MB de type "Bios-boot-area".
3. une partition de N GB de type EXT4 (par exemple) montée sur /.
4. une partition swap etc.

Q1) Ma question est : lorsqu'on souhaite mettre en place du RAID 1
soft sur 2 disques avec une partition GPT, comment faut-il faire
avec un Bios-UEFI et avec un Bios-legacy ?

Par exemple avec un Bios-legacy j'ai repris le découpage B)
ci-dessus sauf que j'ai mis le type RAID pour la partition B.3. et
la B.4. et j'ai simplement demandé à l'installateur d'installer Grub
sur /dev/sda *et* /dev/sdb mais à la fin de l'installation, ça ne
boote pas. J'ai aussi tenté de mettre en type RAID la partition B.2.
et ensuite de définir le volume RAID1 correspondant à ces 2 partitions
(ie la partition B.2. sur sda et B.2 sur sdb) en type "Bios-boot-area"
mais l'installateur ne me propose pas ce type pour un volume RAID.

En Bios-UEFI, je n'ai pas eu encore le temps de faire des essais mais
j'aimerais bien savoir comment on s'y prend également. D'après ce que
je lis ici où là sur le Web, il faut créer une partition de type "UEFI"
sur sda et sdb (et donc pas de type RAID) et demander à l'installateur
d'installer Grub sur sda *et* sdb, est-ce correct ?

J'espère pouvoir faire le test lundi, chez moi je n'ai pas de UEFI
sous la main.

Il y a bien Virtualbox sur mon Desktop perso avec une option à cocher
qui s'intitule "Activer EFI (OS spéciaux seulement)" mais ensuite
lorsque je boote la VM j'ai un austère shell EFI interactif dans lequel
je suis un peu perdu. Du coup, avec Virtualbox, je peux faire des tests
d'installation en Bios-legacy (et ça c'est pratique) mais impossible de
faire des tests d'installation en Bios-UEFI.

Q2) Si vous connaissez un logiciel (pas trop compliqué) de Virtualisation
qui puisse émuler à la fois du Bios-legacy et UEFI, ça m'intéresse. Parce
qu'actuellement, je suis obligé de faire des tests sur des serveurs physiques
dont le temps de démarrage est ultra long.

Merci d'avance pour votre aide.

--
François Lafont

10 réponses

1 2 3
Avatar
Pascal Hambourg
Francois Lafont a écrit :

Q1) Ma question est : lorsqu'on souhaite mettre en place du RAID 1
soft sur 2 disques avec une partition GPT, comment faut-il faire
avec un Bios-UEFI et avec un Bios-legacy ?



Pour le RAID en UEFI avec Debian, j'avais commis ceci :
<https://www.debian-fr.org/raid-logiciel-linux-et-amorcage-en-uefi-t50873.html&gt;

Par exemple avec un Bios-legacy j'ai repris le découpage B)
ci-dessus sauf que j'ai mis le type RAID pour la partition B.3. et
la B.4. et j'ai simplement demandé à l'installateur d'installer Grub
sur /dev/sda *et* /dev/sdb mais à la fin de l'installation, ça ne
boote pas.



Ça devrait. Que se passe-t-il exactement ?

J'ai aussi tenté de mettre en type RAID la partition B.2.
et ensuite de définir le volume RAID1 correspondant à ces 2 partitions
(ie la partition B.2. sur sda et B.2 sur sdb) en type "Bios-boot-area"



Mauvaise idée. Pour le BIOS et la boot image, il n'y a pas de RAID.

mais l'installateur ne me propose pas ce type pour un volume RAID.



Normal, c'est un identifiant de type de partition. Ce n'est pas
applicable à un ensemble RAID.

En Bios-UEFI, je n'ai pas eu encore le temps de faire des essais mais
j'aimerais bien savoir comment on s'y prend également. D'après ce que
je lis ici où là sur le Web, il faut créer une partition de type "UEFI"
sur sda et sdb (et donc pas de type RAID) et demander à l'installateur
d'installer Grub sur sda *et* sdb, est-ce correct ?



C'est un poil plus compliqué, voir le lien ci-dessus. En UEFI on
n'indique pas à grub-install sur sur quel périphérique installer le
chargeur. Il l'installe par défaut dans la partition système EFI qui
doit être montée au préalable sur /boot/efi. Les versions assez récentes
de GRUB 2 ont une option pour sélectionner un autre emplacement, mais je
ne l'ai pas testée, ayant fait mes expérimentations avec une version
plus ancienne.
Avatar
Francois Lafont
Bonjour et désolé pour ma réponse un peu tardive.

On 17/10/2015 23:08, Pascal Hambourg wrote:

Pour le RAID en UEFI avec Debian, j'avais commis ceci :
<https://www.debian-fr.org/raid-logiciel-linux-et-amorcage-en-uefi-t50873.html&gt;



Ah merci, j'ai tout lu, ça m'a l'air très clair. Je le garde sous le
coude précisieusement et je ferai le test dès que possible.

Pour l'instant, je suis focalisé sur l'installation en Bios-legacy +
GPT sur le disque système + RAID1 software et j'ai du mal. :)

Par exemple avec un Bios-legacy j'ai repris le découpage B)
ci-dessus sauf que j'ai mis le type RAID pour la partition B.3. et
la B.4. et j'ai simplement demandé à l'installateur d'installer Grub
sur /dev/sda *et* /dev/sdb mais à la fin de l'installation, ça ne
boote pas.



Ça devrait. Que se passe-t-il exactement ?



Alors, j'essaye d'installer une Debian Jessie via une netinstall
PXE, sachant que j'utilise un fichier preseed pour automatiser une
partie de l'installation mais pas tout. Par exemple la partie Grub
est manuelle car à ma connaissance on ne peut pas installer Grub
2 fois sur 2 disques différent via un preseed (si je me trompe sur
ce point, faut pas hésiter à me le dire ;)). De plus, j'évite à
tout prix cette grosse daube de partman (oui c'est une daude) et
j'effectue le partitionnement en ligne de commandes via le preseed
(je m'explique ci-dessous).

Donc j'ai un serveur avec un bios-legacy et je lance l'install de
Jessie via PXE (on peut considérer que c'est ni plus ni moins une
install en mode expert sauf que des réponses sont prédéfinies parfois).

Mon preseed fait en sorte que l'utilitaire "parted" est chargé
au moment du partitionnement des disques. De plus, j'ai une
instruction preseed qui se lance une fois tous les composants
chargés, les disques et les partitionnements pré-existants
identifiés/scannés, mais juste avant que le menu de partitionnement
ne s'affiche (l'instruction preseed s'appelle « d-i partman/early_command »).

Avec cette instruction, c'est donc en ligne de commandes que
je procède au partitionnement (ce qui me fait gagner du temps
dans mes nombreuses tentatives d'installation (sans succès
jusque là). Le script revient à faire ce partitionnement :

/dev/sda et /dev/sdb (2 disques à plateau de 2TB identiques), utilisation d'un partitionnement GPT :
sd[ab]1 => une partition de 250 MB de type "non-utilisée" au cas où un jour je décide de basculer le Bios en UEFI
sd[ab]2 => une partition de 1 MB de type "Bios-boot-area"
sd[ab]3 => une partition de 30 GB de type RAID (ce sera les partitions du système en RAID1)
sd[ab]4 => une partition de 64 GB de type RAID (ce sera les partitions de la swap en RAID1)

Ensuite, j'ai 2 disques SSD identiques dont je donne le partitionnement
aussi dans un souci d'exhaustivité même si le problème n'est pas ici
vu que ces SSD n'interviennent pas au boot :

/dev/sdc et /dev/sdd (2 disques SSD de 200 GB identiques), utilisation d'un partitionnement GPT :
sd[cd]1 => une partition prenant tout le disque (ou presque) de type RAID

Ensuite, je me crée les volumes RAID1 suivants:
/dev/md0 => constitué de sda3 et sdb3 en RAID1 (accueillera /)
/dev/md1 => constitué de sda4 et sdb4 en RAID1 (accueillera la swap)
/dev/md2 => constitué de sdc1 et sdd1 en RAID1 (dans lequel je mettrai du LVM)

Pour info, voici le script qui crée le partitionnement décrit ci-dessus :

---------------------------------------------------------
#!/bin/sh

exec >/tmp/part.log 2>&1
set -x

parted='parted --script --align=opt'

raid1system='md0'
raid1swap='md1'
raid1ssd='md2'


### Remove the RAID volumes /dev/$raid1system and /dev/$raid1swap if already created. ###
[ -e /dev/$raid1system ] && mdadm --stop /dev/$raid1system
[ -e /dev/$raid1swap ] && mdadm --stop /dev/$raid1swap
[ -e /dev/$raid1ssd ] && mdadm --stop /dev/$raid1ssd
mdadm --zero-superblock /dev/sda3
mdadm --zero-superblock /dev/sdb3
mdadm --zero-superblock /dev/sda4
mdadm --zero-superblock /dev/sdb4
mdadm --zero-superblock /dev/sdc1
mdadm --zero-superblock /dev/sdd1


### Create GPT partition on each disk. ###
for i in a b c d
do
$parted /dev/sd${i} mktable gpt
done


### Partitioning on the non-SSD drives. ###
n=0
for i in a b
do
# a => n = 1, b => n = 2.
n=$((n + 1))

part_num=1

# The used UEFI partitions if one day we decide
# to enable the Bios-UEFI.
a=1
b%0 # Size == 250MiB
$parted /dev/sd${i} unit MiB mkpart uefi${n}unused $a $b
part_num=$((part_num + 1))

# The biosgrub partitions.
a=$b
b=$((1 + $b)) # Size == 1MiB
$parted /dev/sd${i} unit MiB mkpart biosgrub${n} $a $b
$parted /dev/sd${i} set $part_num bios_grub on
part_num=$((part_num + 1))

# The root partitions (will be a RAID1 volume).
a=$b
b=$((30 * 1024 + a)) # Size == 30GiB
$parted /dev/sd${i} unit MiB mkpart system${n} $a $b
$parted /dev/sd${i} set $part_num raid on
part_num=$((part_num + 1))

# The swap (will be a RAID1 volume).
a=$b
b=$((64 * 1024 + a)) # Size == 64GiB
$parted /dev/sd${i} unit MiB mkpart swap${n} linux-swap $a $b
$parted /dev/sd${i} set $part_num raid on
part_num=$((part_num + 1))

done


### Partitioning on the SSD drives. ###
n=0
for i in c d
do
# c => n = 1, d => n = 2.
n=$((n + 1))

# The swap (will be a RAID1 volume).
a=1
b='-1cyl' # The last cylinder
$parted /dev/sd${i} -- unit MiB mkpart ssd${n} $a $b
$parted /dev/sd${i} set 1 raid on
done


### Creation of the RAID volumes. ###

# For the system (/) partition.
mdadm --create /dev/$raid1system --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3 --force --run

# For the swap partition.
mdadm --create /dev/$raid1swap --level=1 --raid-devices=2 /dev/sda4 /dev/sdb4 --force --run

# The SSD RAID1 volume.
mdadm --create /dev/$raid1ssd --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1 --force --run


### Creation of the volume group LVM on the SSD RAID1 volume. ###

pvcreate -ff --yes /dev/$raid1ssd
vgcreate --force --yes vg1 /dev/$raid1ssd
---------------------------------------------------------

Une fois que ces commandes sont exécutées, je me retrouve devant le
menu de partitionnement de l'installateur Debian avec donc toutes
les partitions et tous les volumes RAID déjà définis.

Je ne sais pas si cela a une importante, mais lors de la création
des volumes RAID (via `mdadm --create ...`) j'ai ces messages :

-----------------------------------------------------
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3 --force --run

mdadm: Note: this array has metadata at the start and may not be
suitable as a boot device If you plan to store /boot on
this device please ensure that your boot-leoder understands
md.v1.x metadata, or use metadata=0.90
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started
-----------------------------------------------------

Je ne sais pas si c'est important pour la suite, dans le doute,
je le signale...

J'ai donc tout qui est partitionné comme je le souhaite mais par
contre aucun point de montage n'est défini ni aucun file system
au niveau de l'installateur. Je le fais donc manuellement.

Q : Au passage, si vous connaissez un moyen de définir les points
de montages, les options de montages, ainsi que les filesystems à
formater sur les différentes partitions en ligne de commandes
dans le prolongement du script ci-dessus, je suis très intéressé.

Dans l'installeur, manuellement, je définis donc les points
de montages, les options de montages etc. Là, il y a un petit
truc qui me chagrine. Lorsque je visualise le partitionnement
dans le menu de l'installateur, je vois la lettre "K" en face
des 2 partitions "biosgrub" ce qui voudrait dire que les partitions
sont laissées intactes par l'installateur. Or mes nombreuses
tentatives (sans succès) me laissent penser qu'il faut absolument
que l'installateur formate ces 2 partitions. Du coup, je suis
obligé de faire une manip très bête : pour chacune de ces partitions
biosgrub, je rentre dans son menu de paramétrage et là :

- je change le type de partition pour mettre n'importe quoi (par
exemple swap)
- puis je change à nouveau le type de la partition pour remettre
à nouveau "bios boot area" comme c'était avant
- puis je valide via "Done setting up the partition"

Et voilà, j'ai maintenant la lettre "f" en face des 2 partitions
"biosgrub" ce qui veut dire qu'elles seront bien formatées par
l'installateur.

Q : Est-il possible de remplacer cette étape manuelle par
des commandes dans le prolongement de mon script ci-dessus.

Ensuite, je définis le point de montage et le fs sur /dev/md0
et /dev/md1 et ensuite, plus aucune question ne m'est posée
jusqu'à Grub. Là, j'indique explicitement que je veux que
Grub soit installé au niveau de /dev/sda (je précise manuellement
le nom du device). Ensuite, l'installation va à son terme et me
propose le reboot. Là, je retourne en arrière au niveau de la partie
Grub à nouveau pour demander à l'installateur d'installer Grub à
nouveau mais cette fois-ci au niveau de /dev/sdb (pour avoir Grub
installé sur les 2 devices). Et là je termine définitivement
l'installation par le reboot.

Là, dans le menu PXE qui s'affiche au boot, je choisis l'entrée
dans le menu qui correspond au boot « sur le disque local ».
Concrètement, si je tape sur la touche « Tab » pour voir le
contenu de cette entrée de boot Grub, je vois « .localboot 0 ».
Si je boote là-dessus, j'obtiens ce message d'erreur :

-----------------------------------------------------
Booting from local disk...
PXE-M0F: Exiting Intel Boot Agent

error: disk `mduuid/d_be60cc06.....738` not found.
Entering rescue mode...
grub rescue>
-----------------------------------------------------

J'ai un prompt "Grub rescue" et bien sûr la machine ne boote
pas. Si je tente le boot sur l'un des 2 disques à plateaux
explicitement via le menu de boot que le Bios me propose, j'obtiens
la même chose que ci-dessus pour l'un des disques et et pour l'autre
disque le serveur part sur un boot PXE. J'ignore pourquoi cette
différence.

Voilà, très exactement où j'en suis et je n'ai pas trop d'idée.
Le pire, c'est qu'une fois, je ne sais pas comment, j'ai réussi
à avoir un truc qui boote et j'ai jamais été foutu de le reproduire.

J'ai aussi tenté de mettre en type RAID la partition B.2.
et ensuite de définir le volume RAID1 correspondant à ces 2 partitions
(ie la partition B.2. sur sda et B.2 sur sdb) en type "Bios-boot-area"



Mauvaise idée. Pour le BIOS et la boot image, il n'y a pas de RAID.



Ok, c'est noté.

mais l'installateur ne me propose pas ce type pour un volume RAID.



Normal, c'est un identifiant de type de partition. Ce n'est pas
applicable à un ensemble RAID.



Ok.

En Bios-UEFI, je n'ai pas eu encore le temps de faire des essais mais
j'aimerais bien savoir comment on s'y prend également. D'après ce que
je lis ici où là sur le Web, il faut créer une partition de type "UEFI"
sur sda et sdb (et donc pas de type RAID) et demander à l'installateur
d'installer Grub sur sda *et* sdb, est-ce correct ?



C'est un poil plus compliqué, voir le lien ci-dessus. En UEFI on
n'indique pas à grub-install sur sur quel périphérique installer le
chargeur. Il l'installe par défaut dans la partition système EFI qui
doit être montée au préalable sur /boot/efi. Les versions assez récentes
de GRUB 2 ont une option pour sélectionner un autre emplacement, mais je
ne l'ai pas testée, ayant fait mes expérimentations avec une version
plus ancienne.



Ah, ta méthode 3 m'a l'air pas trop compliquée et sinon effectivement
si on peut carrément indiquer en option l'emplacement alors c'est encore
mieux. Je testerai ça dans un second temps... quand j'aurai réussi
à booter ce satané serveur avec son bios-legacy (et de manière reproductible) ;)

--
François Lafont
Avatar
Francois Lafont
On 21/10/2015 14:36, Francois Lafont wrote:

et ensuite, plus aucune question ne m'est posée
jusqu'à Grub. Là, j'indique explicitement que je veux que
Grub soit installé au niveau de /dev/sda (je précise manuellement
le nom du device). Ensuite, l'installation va à son terme et me
propose le reboot. Là, je retourne en arrière au niveau de la partie
Grub à nouveau pour demander à l'installateur d'installer Grub à
nouveau mais cette fois-ci au niveau de /dev/sdb (pour avoir Grub
installé sur les 2 devices).



Ah, je crois que j'ai trouvé. C'est là où je me suis mélangé les
crayons. À la question "voulez-vous installer Grub sur le MBR",
je répondais "non" et ensuite je choisissais /dev/sda et je
recommençais à l'identique avec /dev/sdb. Mais en fait, il faut
que je réponde "oui" à la question et ensuite je choisis
/dev/sda puis je recommence à nouveau en choisissant /dev/sdb.

À partir de là, tout semble bien fonctionner. Par contre, le
pourquoi de tout ça, c'est vraiment pas très clair pour moi.

En revanche, il faudrait que je teste avec un disque en moins
pour être sûr que ça boote bien malgré tout.

Du coup, je vais pouvoir tester ta procédure Pascal avec UEFI.
Mais par ailleurs, je me permets de revenir à la charge sur
cette histoire Grub et de RAID.

J'ai aussi tenté de mettre en type RAID la partition B.2.
et ensuite de définir le volume RAID1 correspondant à ces 2 partitions
(ie la partition B.2. sur sda et B.2 sur sdb) en type "Bios-boot-area"



Mauvaise idée. Pour le BIOS et la boot image, il n'y a pas de RAID.



Ok, c'est noté.



En fait, ça m'interpelle un peu tout ça. Pas de RAID au niveau du
Grub qui est installé 2 fois : sur sda et sur sdb, ok. Mais que se
passe-t-il en cas de mise à jour du noyau ou bien si je décide
d'ajouter une option de boot (via /etc/default/grub et update-grub) ?
Est-ce que ce sont les 2 installations de Grub (sur sda _et_ sdb)
qui seront mises à jour (et auquel cas tout va bien) ou alors c'est
seulement l'une des deux (et auquel cas on peut avoir des mauvaises
surprises par exemple si un des disques est HS et le Bios fait appel
à l'autre Grub qui n'a pas subit les mises jour).

J'ai sous les yeux un serveur dont la partition /boot est est en RAID1
(c'est une Wheezy et le serveur a très probablement un bios non UEFI,
donc legacy). Donc avoir le Grub sur une partition RAID1 directement
ça doit être possible sous certaines conditions, non ?

--
François Lafont
Avatar
Pascal Hambourg
Francois Lafont a écrit :

Par exemple avec un Bios-legacy j'ai repris le découpage B)
ci-dessus sauf que j'ai mis le type RAID pour la partition B.3. et
la B.4. et j'ai simplement demandé à l'installateur d'installer Grub
sur /dev/sda *et* /dev/sdb mais à la fin de l'installation, ça ne
boote pas.


Ça devrait. Que se passe-t-il exactement ?



Alors, j'essaye d'installer une Debian Jessie via une netinstall
PXE, [...]



Je n'en demandais pas tant, juste ce qui se passe au démarrage.

/dev/sda et /dev/sdb (2 disques à plateau de 2TB identiques), utilisation d'un partitionnement GPT :
sd[ab]1 => une partition de 250 MB de type "non-utilisée" au cas où un jour je décide de basculer le Bios en UEFI
sd[ab]2 => une partition de 1 MB de type "Bios-boot-area"
sd[ab]3 => une partition de 30 GB de type RAID (ce sera les partitions du système en RAID1)
sd[ab]4 => une partition de 64 GB de type RAID (ce sera les partitions de la swap en RAID1)



Ça fait beaucoup de swap. C'est la première fois que je vois un swap
plus gros que l'espace alloué au système.
Aussi, pourquoi utiliser des disques aussi gros pour en occuper moins de
100 Go. Il n'y a pas plus petit ?

Ensuite, je me crée les volumes RAID1 suivants:
/dev/md0 => constitué de sda3 et sdb3 en RAID1 (accueillera /)
/dev/md1 => constitué de sda4 et sdb4 en RAID1 (accueillera la swap)

Je ne sais pas si cela a une importante, mais lors de la création
des volumes RAID (via `mdadm --create ...`) j'ai ces messages :

-----------------------------------------------------
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3 --force --run

mdadm: Note: this array has metadata at the start and may not be
suitable as a boot device If you plan to store /boot on
this device please ensure that your boot-leoder understands
md.v1.x metadata, or use metadata=0.90
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started
-----------------------------------------------------



Aucune importance.

Q : Au passage, si vous connaissez un moyen de définir les points
de montages, les options de montages, ainsi que les filesystems à
formater sur les différentes partitions en ligne de commandes
dans le prolongement du script ci-dessus, je suis très intéressé.



Pour créer un système de fichiers : mkfs.<fstype>.
Pour créer un swap : mkswap.

La racine du système à installer doit être montée sur /target et les
autres systèmes de fichiers montés sur leurs points de montage
respectifs de cette future racine sous /target, mais je ne sais pas
comment l'installateur va réagir si on ne passe pas par partman pour
définir la racine et compagnie.

Dans l'installeur, manuellement, je définis donc les points
de montages, les options de montages etc. Là, il y a un petit
truc qui me chagrine. Lorsque je visualise le partitionnement
dans le menu de l'installateur, je vois la lettre "K" en face
des 2 partitions "biosgrub" ce qui voudrait dire que les partitions
sont laissées intactes par l'installateur.



Oui.

Or mes nombreuses
tentatives (sans succès) me laissent penser qu'il faut absolument
que l'installateur formate ces 2 partitions.



Non, cette partition n'a absolument pas besoin d'être formatée. Tout
formatage sera détruit lorsque grub-install y mettra la core image du
chargeur.

Ensuite, je définis le point de montage et le fs sur /dev/md0
et /dev/md1 et ensuite, plus aucune question ne m'est posée
jusqu'à Grub. Là, j'indique explicitement que je veux que
Grub soit installé au niveau de /dev/sda (je précise manuellement
le nom du device). Ensuite, l'installation va à son terme et me
propose le reboot. Là, je retourne en arrière au niveau de la partie
Grub à nouveau pour demander à l'installateur d'installer Grub à
nouveau mais cette fois-ci au niveau de /dev/sdb (pour avoir Grub
installé sur les 2 devices). Et là je termine définitivement
l'installation par le reboot.



En mode expert, il me semble qu'il est possible de spécifier plusieurs
emplacements en même temps. Ou alors c'est seulement quand on exécute
dpkg-reconfigure grub-pc ?

error: disk `mduuid/d_be60cc06.....738` not found.
Entering rescue mode...
grub rescue>



Bon, ça exécute au moins la core image de GRUB. Mais je suppose qu'elle
ne voit pas le volume contenant /boot/grub.

Qu'affichent "ls" (pour afficher les disques, partitions, volumes RAID
et LVM connus) et set (pour afficher les variables d'environnement dont
root et prefix) ?

Un UUID de volume RAID qui contient un "_", ça me semble bizarre.
Avatar
Pascal Hambourg
Francois Lafont a écrit :

Ah, je crois que j'ai trouvé. C'est là où je me suis mélangé les
crayons. À la question "voulez-vous installer Grub sur le MBR",
je répondais "non" et ensuite je choisissais /dev/sda et je
recommençais à l'identique avec /dev/sdb. Mais en fait, il faut
que je réponde "oui" à la question et ensuite je choisis
/dev/sda puis je recommence à nouveau en choisissant /dev/sdb.



Normalement ça devrait revenir au même.

En revanche, il faudrait que je teste avec un disque en moins
pour être sûr que ça boote bien malgré tout.



Depuis Jessie tu auras une mauvaise surprise : les ensembles RAID
comportant moins de membres qu'attendu (autrement dit un membre manquant
mais pas marqué comme tel dans les autres membres) ne sont pas assemblés
automatiquement et on tombe dans le shell de l'initramfs. Mais ce n'est
pas gênant pour tester le boot en lui-même, à ce stade on est déjà au delà.

J'ai aussi tenté de mettre en type RAID la partition B.2.
et ensuite de définir le volume RAID1 correspondant à ces 2 partitions
(ie la partition B.2. sur sda et B.2 sur sdb) en type "Bios-boot-area"



Mauvaise idée. Pour le BIOS et la boot image, il n'y a pas de RAID.


Ok, c'est noté.



En fait, ça m'interpelle un peu tout ça. Pas de RAID au niveau du
Grub qui est installé 2 fois : sur sda et sur sdb, ok.



C'est cela.

Mais que se
passe-t-il en cas de mise à jour du noyau ou bien si je décide
d'ajouter une option de boot (via /etc/default/grub et update-grub) ?



Rien de spécial.

Est-ce que ce sont les 2 installations de Grub (sur sda _et_ sdb)
qui seront mises à jour (et auquel cas tout va bien) ou alors c'est
seulement l'une des deux (et auquel cas on peut avoir des mauvaises
surprises par exemple si un des disques est HS et le Bios fait appel
à l'autre Grub qui n'a pas subit les mises jour).



Contrairement à LILO le chargeur GRUB n'a pas besoin d'être réinstallé.
C'est seulement le fichier de configuration /boot/grub/grub.cfg qui sera
regénéré. Ce fichier, le nouveau noyau et tout le reste est en RAID donc
dupliqué sur les deux disques.

C'est seulement en cas de mise à jour ou réinstallation du paquet
grub-pc que le chargeur d'amorçage sera réinstallé. Pour qu'il soit
réinstallé automatiquement dans les deux emplacements, il faut qu'ils
soient définis dans debconf. A vérifier avec

debconf-show grub-pc

J'ai sous les yeux un serveur dont la partition /boot est est en RAID1
(c'est une Wheezy et le serveur a très probablement un bios non UEFI,
donc legacy). Donc avoir le Grub sur une partition RAID1 directement
ça doit être possible sous certaines conditions, non ?



Attention : ne pas confondre le système de fichiers qui contient /boot
(qu'il soit intégré à la racine ou séparé) et la partition "BIOS boot"
réservée à GRUB. Ton /boot est sur sur la racine qui est en RAID.

La partition BIOS boot est lue par la boot image de GRUB (stockée dans
le MBR), qui ne sait pas lire le format RAID logiciel. En revanche
/boot/grub est lu par la core image de GRUB (stockée dans la partition
BIOS boot) qui peut être construite pour savoir lire le format RAID
logiciel.
Avatar
Francois Lafont
On 21/10/2015 22:10, Pascal Hambourg wrote:

Alors, j'essaye d'installer une Debian Jessie via une netinstall
PXE, [...]



Je n'en demandais pas tant, juste ce qui se passe au démarrage.



Ah ben je donne tout le contexte. ;)

/dev/sda et /dev/sdb (2 disques à plateau de 2TB identiques), utilisation d'un partitionnement GPT :
sd[ab]1 => une partition de 250 MB de type "non-utilisée" au cas où un jour je décide de basculer le Bios en UEFI
sd[ab]2 => une partition de 1 MB de type "Bios-boot-area"
sd[ab]3 => une partition de 30 GB de type RAID (ce sera les partitions du système en RAID1)
sd[ab]4 => une partition de 64 GB de type RAID (ce sera les partitions de la swap en RAID1)



Ça fait beaucoup de swap. C'est la première fois que je vois un swap
plus gros que l'espace alloué au système.



Le serveur possède 64 GB de RAM alors comme en général j'ai l'habitude
de mettre en swap la taille de la RAM... mais c'est vrai que dans ce cas
là (un cas avec beaucoup de RAM donc) c'est complètement con. ;) Je pense
que 8 GB par exemple devrait suffire, non ?

Aussi, pourquoi utiliser des disques aussi gros pour en occuper moins de
100 Go. Il n'y a pas plus petit ?



En fait là c'est vraiment l'installation de base dont je m'occupe,
mais l'autre partie du disque servira a priori à du backups etc.

Je ne sais pas si cela a une importante, mais lors de la création
des volumes RAID (via `mdadm --create ...`) j'ai ces messages :

-----------------------------------------------------
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3 --force --run

mdadm: Note: this array has metadata at the start and may not be
suitable as a boot device If you plan to store /boot on
this device please ensure that your boot-leoder understands
md.v1.x metadata, or use metadata=0.90
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started
-----------------------------------------------------



Aucune importance.



Ok.

Q : Au passage, si vous connaissez un moyen de définir les points
de montages, les options de montages, ainsi que les filesystems à
formater sur les différentes partitions en ligne de commandes
dans le prolongement du script ci-dessus, je suis très intéressé.



Pour créer un système de fichiers : mkfs.<fstype>.
Pour créer un swap : mkswap.



Oui effectivement, je peux faire cela dans mon petit script
(ça sera toujours ça de moins à faire manuellement au niveau
du menu « graphique » du debian-installer). Mais par contre,
une fois que tout est partitionné et formaté via le script,
je ne vois pas (hélas) comment gérer toujours via le script
les points de montages et les options de montages. Pour que
l'installation se fasse, je suis obligé de passer par
« l'interface graphique » de l'installateur pour lui dire
« / sera monté ici avec telles options etc. ». Je sais bien
que via un fichier preseed on peut passer par une sorte de
manifest partman mais je trouve que cet outil est une énorme
daube ;) (la taille des partitions est difficile à prévoir
avec ce système pourri des poids, et en plus il y a plein
de limitations incompréhensibles avec cet outil).

La racine du système à installer doit être montée sur /target et les
autres systèmes de fichiers montés sur leurs points de montage
respectifs de cette future racine sous /target, mais je ne sais pas
comment l'installateur va réagir si on ne passe pas par partman pour
définir la racine et compagnie.



Oui moi non plus. J'ai effectivement constaté tout ça quand
j'ai cherché à faire en sorte que mon script remplace complètement
partman. J'ai pu voir effectivement que, une fois qu'on a terminé
le partitionnement manuel via l'installateur et que tout est
formaté etc. on se retrouve avec un /target qui correspond
au point de montage de /, le fichier /target/etc/fstab est
déjà présent, les autres points de montage (s'il en existe)
sont aussi montés etc. et ensuite il semble que l'installation
du système de base se fasse avec debootstrap. Bref, ça
m'avait semblé pas impossible de remplacer tout ça par un
script mais bon j'ai eu la flemme (compte tenu du gain pas
énorme à le faire et du temps dont je dispose ;)).

Dans l'installeur, manuellement, je définis donc les points
de montages, les options de montages etc. Là, il y a un petit
truc qui me chagrine. Lorsque je visualise le partitionnement
dans le menu de l'installateur, je vois la lettre "K" en face
des 2 partitions "biosgrub" ce qui voudrait dire que les partitions
sont laissées intactes par l'installateur.



Oui.

Or mes nombreuses
tentatives (sans succès) me laissent penser qu'il faut absolument
que l'installateur formate ces 2 partitions.



Non, cette partition n'a absolument pas besoin d'être formatée. Tout
formatage sera détruit lorsque grub-install y mettra la core image du
chargeur.



Les tests que j'ai pu faire te donnent raison. ;)
Effectivement, inutile de chercher à formater ces 2 partitions.
C'est donc une étape manuelle en fois à faire, c'est cool.

Ensuite, je définis le point de montage et le fs sur /dev/md0
et /dev/md1 et ensuite, plus aucune question ne m'est posée
jusqu'à Grub. Là, j'indique explicitement que je veux que
Grub soit installé au niveau de /dev/sda (je précise manuellement
le nom du device). Ensuite, l'installation va à son terme et me
propose le reboot. Là, je retourne en arrière au niveau de la partie
Grub à nouveau pour demander à l'installateur d'installer Grub à
nouveau mais cette fois-ci au niveau de /dev/sdb (pour avoir Grub
installé sur les 2 devices). Et là je termine définitivement
l'installation par le reboot.



En mode expert, il me semble qu'il est possible de spécifier plusieurs
emplacements en même temps. Ou alors c'est seulement quand on exécute
dpkg-reconfigure grub-pc ?



Perso, durant l'installation je ne peux choisir qu'un seul device
(même si rien ne m'empêche ensuite de revenir sans le menu GRUB
pour choisir un second device).

error: disk `mduuid/d_be60cc06.....738` not found.
Entering rescue mode...
grub rescue>



Bon, ça exécute au moins la core image de GRUB. Mais je suppose qu'elle
ne voit pas le volume contenant /boot/grub.

Qu'affichent "ls" (pour afficher les disques, partitions, volumes RAID
et LVM connus) et set (pour afficher les variables d'environnement dont
root et prefix) ?



grub rescue> ls
(hd0) (hd0,gpt4) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1) (md/1) (md/0)

Heu... ça représente quoi « (hd0,gpt3) » ? Le serveur a 4 disques
et là avec hd0 j'ai l'impression que Grub n'en voit qu'un, non ?

grub rescue> set
cmdpath=(hd0)
prefix=(mduuid/7be8be...f99aa)/boot/grub
root=mduuid/7be8be...f99aa

Je ne sais pas si ça t'inspire...

Un UUID de volume RAID qui contient un "_", ça me semble bizarre.



Oui mais n'en tiens pas compte c'est une faute de frappe de ma
part, désolé (étant donné que je ne peux pas faire de copier-coller,
j'ai fait une faute de frappe et en plus j'ai eu la flemme de saisir
tout le UUID, comme ci-dessus aussi d'ailleurs).

--
François Lafont
Avatar
Francois Lafont
On 21/10/2015 22:26, Pascal Hambourg wrote:

Ah, je crois que j'ai trouvé. C'est là où je me suis mélangé les
crayons. À la question "voulez-vous installer Grub sur le MBR",
je répondais "non" et ensuite je choisissais /dev/sda et je
recommençais à l'identique avec /dev/sdb. Mais en fait, il faut
que je réponde "oui" à la question et ensuite je choisis
/dev/sda puis je recommence à nouveau en choisissant /dev/sdb.



Normalement ça devrait revenir au même.



Et bien j'ai pu retester pour être sûr et je peux te confirmer que,
lorsque j'arrive à la partie installation de Grub et que j'ai la
question :

Install the GRUB boot loader to the master boot record?

Si je réponds "non" et que je sélectionne /dev/sda une première fois,
que je retourne dans le menu d'installation de Grub, que la même
question m'est posée et que je réponds encore "non" et que je sélectionne
ensuite "/dev/sdb", alors la fin de l'installation ça ne boote pas
et j'ai les messages d'erreurs que j'ai déjà indiqués précédemment.

Si je fais exactement la même installation (tout pareil) sauf que
je réponds "oui" à la question ci-dessus au lieu de "non" alors là
à la fin j'ai un système qui boote impeccablement.

C'est une simplement constatation empirique, je n'ai aucune explication.

En revanche, il faudrait que je teste avec un disque en moins
pour être sûr que ça boote bien malgré tout.



Depuis Jessie tu auras une mauvaise surprise : les ensembles RAID
comportant moins de membres qu'attendu (autrement dit un membre manquant
mais pas marqué comme tel dans les autres membres) ne sont pas assemblés
automatiquement et on tombe dans le shell de l'initramfs.



Heu... je ne suis pas sûr de comprendre (initramfs c'est encore un truc
un peu flou pour moi, le boot est décidément une phase que je maîtrise
mal). Est-ce que tu es en train de me dire qu'avec un RAID 1 soft sur
la partie système, si j'ai un des 2 disques HS, le système ne bootera
plus correctement ? Si c'est ça, c'est naze car ça limite quand même
grandement l'intérêt de faire un RAID1 soft.

Mais ce n'est
pas gênant pour tester le boot en lui-même, à ce stade on est déjà au delà.



Heu, perso si j'ai une machine qui me balance un shell interactif
dans l'initramfs, je ne considère pas que le boot est un succès, je
dirais même que c'est un échec complet du boot à mes yeux, non ?

En fait, ça m'interpelle un peu tout ça. Pas de RAID au niveau du
Grub qui est installé 2 fois : sur sda et sur sdb, ok.



C'est cela.

Mais que se
passe-t-il en cas de mise à jour du noyau ou bien si je décide
d'ajouter une option de boot (via /etc/default/grub et update-grub) ?



Rien de spécial.

Est-ce que ce sont les 2 installations de Grub (sur sda _et_ sdb)
qui seront mises à jour (et auquel cas tout va bien) ou alors c'est
seulement l'une des deux (et auquel cas on peut avoir des mauvaises
surprises par exemple si un des disques est HS et le Bios fait appel
à l'autre Grub qui n'a pas subit les mises jour).



Contrairement à LILO le chargeur GRUB n'a pas besoin d'être réinstallé.
C'est seulement le fichier de configuration /boot/grub/grub.cfg qui sera
regénéré. Ce fichier, le nouveau noyau et tout le reste est en RAID donc
dupliqué sur les deux disques.

C'est seulement en cas de mise à jour ou réinstallation du paquet
grub-pc que le chargeur d'amorçage sera réinstallé. Pour qu'il soit
réinstallé automatiquement dans les deux emplacements, il faut qu'ils
soient définis dans debconf. A vérifier avec

debconf-show grub-pc

J'ai sous les yeux un serveur dont la partition /boot est est en RAID1
(c'est une Wheezy et le serveur a très probablement un bios non UEFI,
donc legacy). Donc avoir le Grub sur une partition RAID1 directement
ça doit être possible sous certaines conditions, non ?



Attention : ne pas confondre le système de fichiers qui contient /boot
(qu'il soit intégré à la racine ou séparé) et la partition "BIOS boot"
réservée à GRUB. Ton /boot est sur sur la racine qui est en RAID.

La partition BIOS boot est lue par la boot image de GRUB (stockée dans
le MBR), qui ne sait pas lire le format RAID logiciel. En revanche
/boot/grub est lu par la core image de GRUB (stockée dans la partition
BIOS boot) qui peut être construite pour savoir lire le format RAID
logiciel.



Ah Ok, merci pour ces explications qui m'aident à y voir un peu plus
clair. Donc si je comprends bien le « noyau » GRUB (petit j'imagine)
est installé dans le MBR mais il passe la main à une deuxième entité
de lui-même, le "core image" (plus gros), qui lui sait lire du RAID
soft (entre autres) dans lequel il trouvera sa conf. Et lors d'un
« update-grub » c'est la conf qui est mise à jour, pas le « noyau »
GRUB du MBR ni le "core image" (qui eux ne bougent pas sauf si le
paquet grub-pc est lui-même mis à jour). Du coup, ma crainte sur un
éventuel problème en cas de mise à jour du noyau ou de l'ajout une
option de boot etc. est levée. ;)


--
François Lafont
Avatar
Francois Lafont
Bonjour,

Je voulais indiquer qu'après l'avoir testé, au niveau de l'installateur
Debian (sous Jessie) dans la partie Grub, bien que les messages d'aide
ne le laissent pas penser, on peut parfaitement indiquer en une seule
saisie deux devices séparés par un espace comme dans "/dev/sda /dev/sdb".
Ça marche très bien et une fois l'installation terminée on peut voir
grâce à la commande "debconf-show grub-pc" que le "boot image" de Grub
est bien installée sur le MBR des 2 disques.

Par ailleurs, je voulais juste avoir une précision sur ceci si c'est
possible :

On 22/10/2015 04:32, Francois Lafont wrote:

Ah Ok, merci pour ces explications qui m'aident à y voir un peu plus
clair. Donc si je comprends bien le « noyau » GRUB (petit j'imagine)
est installé dans le MBR mais il passe la main à une deuxième entité
de lui-même, le "core image" (plus gros), qui lui sait lire du RAID
soft (entre autres) dans lequel il trouvera sa conf. Et lors d'un
« update-grub » c'est la conf qui est mise à jour, pas le « noyau »
GRUB du MBR ni le "core image" (qui eux ne bougent pas sauf si le
paquet grub-pc est lui-même mis à jour). Du coup, ma crainte sur un
éventuel problème en cas de mise à jour du noyau ou de l'ajout une
option de boot etc. est levée. ;)



Je pense que ceci est assez clair mais du coup, c'est dans le cas d'une
partition système en msdos (pas GPT) sur du RAID1 je ne pige pas comment
ça fonctionne. En effet, dans le cas d'une partition msdos avec du RAID1,
il n'y a pas de partition de type "Bios boot" et du coup je ne vois pas
comment ça fonctionne.

J'imagine que le début est pareil que ci-dessus, ie le Bios lance le
"boot image" de Grub qui est sur le MBR d'un des 2 disques système
(normalement il sera installé sur les 2 j'imagine mais le bios en
choisira un) et ce "boot image" est un programme trop petit et trop
simple pour savoir lire du RAID1. Du coup, toujours comme ci-dessus,
il va passer la main à son "core image" (programme plus gros et plus
complexe sachant lire du RAID1) mais où diable est stocké ce "core image" ?
Car en effet, la comparaison avec le cas ci-dessus s'arrête là vu qu'ici
il n'y a pas de partition de type "bios boot".

La seule possibilité que je vois c'est que le "core image" se trouve
dans le MBR de chaque *partition* système mais ça ne semble pas logique
car si j'ai bien compris l'idée un MBR (de disque ou d'une partition
d'un disque) est de taille réduite et donc seul un programme « basique »
peut y être stocké.


--
François Lafont
Avatar
Nicolas George
Francois Lafont , dans le message
<56291881$0$3335$, a écrit :
mais où diable est stocké ce "core image" ?



En général, GRUB le met dans l'espace non partitionné entre le MBR et la
première partition.
Avatar
Francois Lafont
On 22/10/2015 19:32, Nicolas George wrote:

mais où diable est stocké ce "core image" ?



En général, GRUB le met dans l'espace non partitionné entre le MBR et la
première partition.



Ah ok. En regardant ce schéma [1], on peut voir que cet espace fait 32kiB
ce qui est effectivement nettement plus que les 446 Bytes (d'après ce que
j'ai vu sur le web) laissé au "boot image" dans le MBR.

Merci bien pour la réponse.

[1] http://unix.stackexchange.com/questions/81556/area-on-disk-after-the-mbr-and-before-the-partition-start-point

--
François Lafont
1 2 3