Ubuntu-fr

strangeuser

Grub fallback

Bonjour,

Je rencontre un soucis avec le module fallback de grub, ou plus précisément je pense que je ne le configure pas correctement.

Le projet est le suivant :

voici mon partitionnement :

lsblk
nvmen1       259:0    0  100G  0 disk
  ├─nvmen1p1   259:1    0    2G  0 part
  ├─nvmen1p2   259:2    0    1K  0 part
  ├─nvmen1p5   259:3    0    4G  0 part
  ├─nvmen1p6   259:4    0   20G  0 part
  ├─nvmen1p7   259:5    0   20G  0 part
  └─nvmen1p8   259:6    0   20G  0 part

nvmen1p1 est la partition "/boot", c'est ici où se situe la configuration du grub
nvmen1p6 est la partition du système n°1
nvmen1p7 est la partition du système n°2

Mon objectif est mettre en place un système de secure boot, c'est à dire si mon système n°1 ne boot pas correctement, rebooter automatique sur système n°2.

Je pense que le fallback intégré dans grub correspond à mon besoin (lien vers doc officiel : https://www.gnu.org/software/grub/manua … only.html)

Voici maintenant ma configuration grub.cfg (partie menuentry) :

default=saved
timeout=5
hiddenmenu
fallback 0 1

menuentry 'Ubuntu 18 GNU/Linux' --class gnu-linux --class gnu --class os --id 0 {  
        recordfail
        load_video
        gfxmode $linux_gfx_mode
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos6'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos6 --hint-efi=hd0,msdos6 --hint-baremetal=ahci0,msdos6  b16042aa-2466-43a7-91d4-5df680d155d2
        else
          search --no-floppy --fs-uuid --set=root  b16042aa-2466-43a7-91d4-5df680d155d2
        fi
        linux   /bot/vmlinuz-4.15.0-20-generic root=UUID=b16042aa-2466-43a7-91d4-5df680d155d2 ro net.ifnames=0 biosdevname=0 nomodeset
        initrd  /boot/initrd.img-4.15.0-20-generic
        savedefault fallback
}

menuentry 'Debian GNU/Linux'  --class gnu-linux --class gnu --class os --id 1 {   
        recordfail
        load_video
        gfxmode $linux_gfx_mode
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos7'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7  b5bda3ce-0de3-46d8-bff4-c31d12207219
        else
          search --no-floppy --fs-uuid --set=root b5bda3ce-0de3-46d8-bff4-c31d12207219
        fi
        linux   /boot/vmlinuz-4.15.0-43-generic root=UUID=b5bda3ce-0de3-46d8-bff4-c31d12207219 ro net.ifnames=0 biosdevname=0 nomodeset
        initrd  /boot/initrd.img-4.15.0-43-generic
        savedefault fallback
}

Lorsque je génère une erreur dans le système n°1 pour qu'il ne boot pas correctement (erreur de nommage du kernel par exemple), le message erreur suivant s'affiche :

error: file `chemin erroné vers le kernel` not found
error: you need to load the kernel first

Press any key to continue...

Failed to boot both default and fallback entries.

Press any key to continue...

Tout en sachant que le système n°2 boot correctement...

Savez vous pourquoi cela ne fonctionne pas?

Un grand merci d'avance pour vos réponses, j'ai vraiment besoin d'aide

bruno

Re : Grub fallback

Bonjour,

Déjà c'est (sans le = ) :

default saved

Ensuite ce que tu fais semble correspondre à l'ancienne version de grub (https://www.gnu.org/software/grub/manua … stems.html).
Et normalement on modifie surtout pas directement le fichier grub.cfg sous Ubuntu. La configuration se fait dans /etc/default/grub et /etc/grub.d, le fichier grub.cfg étant régénéré avec update-grub.

Enfin, je ne vois pas trop le rapport avec la sécurité.

Dernière modification par bruno (Le 18/03/2019, à 19:36)

strangeuser

Re : Grub fallback

Bonjour Bruno,

Tout d'abord, merci beaucoup pour ta réponse.

Je viens de tester le correctif mais malheureusement cela ne fonctionne pas mieux

normalement on modifie surtout pas directement le fichier grub.cfg

Pour te répondre, il s'agit avant tout d'une toute petite partie d'un projet d'entreprise, et l'objectif est d'effectuer les configuration de manière automatique et silencieuse. De plus en vue de beaucoup de facteur, je ne peux malheureusement pas configurer le grub depuis /etc/default ou /etc/grub.d, c'est pour ça que je suis directement dans le grub.cfg.

je ne vois pas trop le rapport avec la sécurité

Et je n'ai pas pausé ma question dans le forum sécurité par hasard. Il s'agit là de sécurité fonctionnel, car je n'ai pas la possibilité d'avoir un poste de mon parc qui ne fonctionne pas suite à un déploiement. C'est sûr que ce n'est pas une faille de sécu ou une technique de pentest mais cela reste d'une manière ou d'une autre de la sécurité informatique Après c'est mon opinion.

bruno

Re : Grub fallback

De plus en vue de beaucoup de facteur, je ne peux malheureusement pas configurer le grub depuis /etc/default ou /etc/grub.d, c'est pour ça que je suis directement dans le grub.cfg.

Tu as bien conscience que ton fichier grub.cfg va être écrasé à chaque mise à jour du noyau.

Ceci dit j'ai testé l'option de fallback en utilisant set fallback avec différentes valeurs dans les scripts sous /etc/grub.d et en modifiant différentes variables d'environnement GRUb et j’obtiens toujours le me résultat que toi.
J'ai tendance à croire que cette option ne fonctionne pas avec les versions récentes d'Ubuntu (cela fonctionnait appartement en 2011 : https://ubuntuforums.org/showthread.php?t=1712140), ce qui ne serait pas étonnant vu le nombre de patchs pour gérer l'UEFI…

je n'ai pas la possibilité d'avoir un poste de mon parc qui ne fonctionne pas suite à un déploiement.

Même si tu arrives à utiliser cette fonctionnalité cela ne gère que l’absence du noyau ou du fichier initrd spécifié dans la configuration de GRUB. Si la partition est corrompue, ou si le démarrage plante après chargement du noyau, cela ne sera d'aucun secours.

strangeuser

Re : Grub fallback

Merci pour l'info

grub.cfg va être écrasé à chaque mise à jour du noyau

C'est déjà calculé dans le projet, ce n'est pas un soucis

Connaîtrais tu une autre solution qui me permettrais de répondre à mon besoin?

A tout moment mes postes auront un système fiable à 100%. Ce qu'on veut c'est suite à un déploiement si le nouveaux système est cassé pour x raison nous redémarrons sur le système fiable.

bruno

Re : Grub fallback

Non désolé. Je ne sais pas rendre un système fiable à 100%.

strangeuser

Re : Grub fallback

Non désolé. Je ne sais pas rendre un système fiable à 100%.

Super, c'était pas ma question

Je vais chercher ailleurs du coup

bruno

Re : Grub fallback

Ma réponse était un peu ironique
Je pense que tu es bien conscient qu'un système fiable à 100% ne peut pas exister.

Non, je ne connais pas de solution qui permette de redémarrer automatiquement un système qui a planté pour une raison X. Je crois que ce que tu demandes est tout simplement impossible.

Dernière modification par bruno (Le 25/03/2019, à 16:20)

strangeuser

Re : Grub fallback

D'accord Ce que je veux dire dans fiable, c'est que c'est un OS auquel nous somme sûr qu'il fonctionne (utilisé avant le potentiel déploiement).

Dans mon cas je dois me rapprocher de très près des 100% de fiabilité étant données qu'il s'agit d'un projet touchant des postes de production (interruption de service non toléré).

Je pense que le fallback fonctionne, sinon comment feraient les admin qui font une mise à jour de kernel sur des serveur très distant? Il faut bien s'assurer que le boot fonctionne

bruno

Re : Grub fallback

Sur un serveur distant il y a toujours une procédure de récupération (KVM sur IP, le plus souvent) permettant de démarrer sur un système minimal et de monter les partition système pour dépanner le système principal.
Dans la pratique, les mises à jour du noyau sur un serveur sont assez rares et donc les redémarrage aussi.

Désolé d'insister, mais l'option fallback de grub ne permet pas de démarrer automatiquement sur un autre noyau en cas de plantage. Elle n'est censée fonctionner qu'en cas d’absence de noyau ou d'initrd.
Et ce que tu demandes ne me semble pas cohérent : tu ne peux pas déployer un nouveau système ou un nouveau noyau sans interruption de service.