Avertissement de gparted mais tout semble OK

Support Debian
#1

bonjour ,
suite à un 1er échec de l’installation de debian 11 avec LVM ( dû à l’échec de l’installation de grub-efi ) je viens de refaire un essai après formatage du ssd externe qui me sert pour des tests .

Choisissant un partitionnement manuel j’ai d’abord réalisé une partition de type EFI puis je suis retourné dans le partitionnement en utilisant LVM avec formation d’un volume physique sur tout le ssd hors partition EFI . Même si lv-boot n’était pas indispensable pour Grub 2 ( à ce que j’ai compris ) je l’ai quand même ajouté .

A priori tout fonctionne sans problème mais il doit y avoir un truc qui cloche car gparted me signale une anomalie ( cf Avertissement ) , du moins c’est ce qu’il me semble :

Capture d’écran_2022-07-30_19-55-52

Capture d’écran_2022-07-30_19-08-04

fdisk -l 
********
Disque /dev/sdb : 111,79 GiB, 120034123776 octets, 234441648 secteurs
Modèle de disque : SU30            
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 33553920 octets
Type d'étiquette de disque : gpt
Identifiant de disque : A66937CC-4AC7-4516-ABC7-79CAC5955968

Périphérique  Début       Fin  Secteurs Taille Type
/dev/sdb1     65535    458744    393210   192M Système EFI
/dev/sdb2    458745 234418694 233959950 111,6G LVM Linux


Disque /dev/mapper/lv--1-lv--root : 27,94 GiB, 29997662208 octets, 58589184 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 33553920 octets


Disque /dev/mapper/lv--1-lv--home : 46,56 GiB, 49996103680 octets, 97648640 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 33553920 octets


Disque /dev/mapper/lv--1-lv--swap : 2,79 GiB, 2998927360 octets, 5857280 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 33553920 octets


Disque /dev/mapper/lv--1-lv--boot : 488 MiB, 511705088 octets, 999424 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 33553920 octets

ps : après avoir réalisé la partition pour EFI puis sélectionné le volume physique et au moment d’écrire ces opérations sur le disque , l’installateur m’a averti que la partition sur sdb1 , donc EFI , serait formatée . Or elle est encore là , mais avec un avertissement .

#2

Pourquoi ne pas commencer par installer dosfstools et mtools comme expliqué.

#3

dosfstools est déjà installé , bizarre que gparted ne le sache pas :

apt policy dosfstools
dosfstools:
  Installé : 4.2-1
  Candidat : 4.2-1
 Table de version :
 *** 4.2-1 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        100 /var/lib/dpkg/status

je vais installer l’autre pour voir

effectivement ça a résolu ce problème . Il fallait donc les 2 paquets . Au temps pour moi .

mais il reste cette histoire de formatage annoncé et non effectué . Mon ssd amorce-t-il à cause de sdb1 ou bien de la partition /boot ? Normalement ce devrait être sdb1 puisque je suis en mode UEFI mais cette histoire de formatage m’a brouillé les idées .
Si j’avais écouté l’installateur j’aurais dû arrêter l’installation pour essayer de comprendre . En fait je l’ai fait mais ne trouvant aucune solution j’ai décidé de continuer pour voir ce qui allait se passer . Je ne comprends pas pourquoi ça marche et c’est bien dommage .

#4

Je n’utilise pas de lvm, mais un installeur formate par défaut la partition système, sans trop se poser plus de question.
S’il considère que les limites exactes de la partition ne sont pas propres, il réaligne un peu, et formate.
Je ne pense pas que ce soit un réel problème.

#5

sauf que selon la remarque que j’ai ajoutée j’aurais dû arrêter l’installation car formater la partition EFI aurait dû empêcher le ssd d’amorcer … à moins que lv-boot m’ait sauvé la mise .car dans le tuto ( 2017 ) qui m’a servi de modèle seul lv-boot a été réalisé (peut-être n’était-il pas en mode UEFI ? ): Install Debian Server With LVM Partitions | Tech Space KH

en fait ce genre d’installation n’a pas d’intérêt pratique dans mon cas , je l’ai fait par curiosité pure .

merci pour les réponses .

#6

Et même en allant plus bas :

Pourquoi utiliser l’UEFI quand on n’en a pas besoin ?

Et du coup, sans démarrage en mode UEFI, il ne serait même pas nécessaire de créer une partition EFI.

1 J'aime
#7

mon portable habituel ne comporte que ce mode d’amorçage ou s’il y a possibilité d’amorcer façon « legacy » je ne l’ai pas trouvé dans mon µprogramme « InsydeH2O® UEFI BIOS » . Je préfère donc harmoniser mon micro-parc informatique pour être sûr de pouvoir utiliser mes 2 ssd externes sur n’importe quel portable : 2 asus en mode bios/uefi et LDLC en UEFI seulement ( sauf erreur de ma part ) .

#8

Bonjour

#9

@MicP
en voyant cette image je suis retourné dans le « Insydeh2o » : mes menus ne ressemblent pas du tout à ça que ce soit « settings » ou « boot » . Dans ce dernier il ne m’est proposé que le mode UEFI et la partie " boot menu" est inaccesssible .

j’ai enfin trouvé une photo qui correspond :
th-2072568068

note : ceci est bien plus préoccupant en ce qui me concerne car mon UEFI est fort probablement concerné :

" In total, Binarly found 23 flaws in the InsydeH2O UEFI firmware, most of them in the software’s System Management Mode (SMM) that provides system-wide functions such as power management and hardware control."

#10

Il existe peut-être une touche a appuyer ou un raccourci clavier à utiliser au moment du démarrage de la machine qui permettra d’accéder à la partie du microprogramme donnant accès aux options qui permettraient de désactiver l’UEFI.

Il faudrait chercher dans le manuel de la machine ou faire des recherches sur internet avec les références de la machine.

#11

En effet ça n’a guère d’intérêt, sauf si tu envisages de monter /boot en lecture seule en fonctionnement normal. Dans ce cas il faudra bien sûr le remonter en lecture-écriture lors de l’installation, suppression ou mise à jour de paquets qui ont besoin d’écrire dans /boot. Cela concerne notamment linux-image*, grub* mais aussi initramfs-tools et tous les paquets dont des éléments sont inclus dans l’initramfs : udev, microcode, firmware, mdadm, lvm2, cryptsetup, plymouth…

Cela aurait un intérêt si /boot était dans une partition normale hors de LVM, plus simple donc moins de risque de problème qu’avec LVM, ou si tu voulais utiliser des types de systèmes de fichiers différents pour / et /boot, notamment si GRUB ne supporte pas le système de fichiers de /. Sinon un petit avantage est le moindre risque de corruption puisque /boot reçoit beaucoup moins d’ériture qu’une racine contenant tout le reste du système y compris les parties les plus variables comme /tmp et /var.

Question : cette copie d’écran de gparted a-t-elle été prise depuis le système installé ? Si oui, est-il normal que la partition EFI ne soit pas montée ? Elle devrait être montée sur /boot/efi au moins lors de l’installation ou la mise à jour des paquets grub* et associés (shim*, peut-être mokutil). Que contient /etc/fstab ?

En tout cas je vois qu’il y a plein d’espace libre dans le PV LVM, ce qui est un très bonne chose.

Normal, « formater » ne signifie pas « supprimer ». Toute partition nouvellement créée doit être « formatée », à de rares exceptions près comme une partition d’amorçage BIOS (bios_grub).

En principe les deux. D’abord la partition EFI qui contient GRUB puis /boot qui contient le fichier de configuration du menu de GRUB, le noyau Linux et son initramfs.
Note : ici /boot n’est pas dans une partition mais dans un volume logique LVM.

#12

bonne question ! Ça m’avait semblé curieux au point que j’avais vérifié sur mon portable habituel sans partitionnement LVM : EFI est bien montée sur /boot/efi .

tiré de /etc/fstab : # /boot/efi was on /dev/sda1 during installation , or sda1 est une partition Windows du disque interne du portable avec lequel j’ai réalisé l’installation sur le ssd externe : /dev/sda1 2048 206847 204800 100M Système EFI

Et pourtant debian 11 sur mon ssd de test réalisé avec LVM fonctionne très bien et n’a aucun problème d’amorçage . Mais pas sûr que si je change de portable ce ssd amorce , non ?
Maintenant je suis bien incapable d’en tirer quoi que ce soit . Peut-être un oubli de ma part à définir un point de montage lors de l’installation ? Pourtant il me semble que c’est l’installateur qui réalise l’opération automatiquement pour cette partition là .

Normal, « formater » ne signifie pas « supprimer ». Toute partition nouvellement créée doit être « formatée », à de rares exceptions près comme une partition d’amorçage BIOS (bios_grub).

je dois donc réviser mon approche du formatage que j’associais toujours à une perte de données . Mais effectivement l’installateur n’a pas mentionné " toutes les données seront effacées " , il a juste parlé de formatage .

ps : il va vraiment falloir que je trouve la doc de InsydeH2O pour passer en mode BIOS ; si possible !ne serait-ce qu’à cause des 23 bogues qui le gangrènent en mode UEFI

#13

Deux remarques.

  • Il ne faut pas se fier à la désignation /dev/sd* des disques et partitions lors de l’installation, elle est susceptible de varier après l’installation et à chaque démarrage. Il vaut mieux comparer l’UUID spécifié dans /etc/fstab avec celui des partitions actuelles et regarder les systèmes de fichiers montés (lsblk -f)

  • Même si c’est la partition EFI créée lors de l’installation de Windows, ce n’est pas une « partition Windows » mais une partition EFI utilisable par n’importe quel autre OS.

S’il s’avère que Debian monte la partition EFI du disque interne et y a installé son chargeur d’amorçage GRUB, alors non Debian ne démarrera pas sur un autre ordinateur. Ce n’est pas irréversible, il suffit de monter la bonne partition et d’y réinstaller GRUB.

Tu as peut-être oublié de marquer la partition EFI du disque interne « ne pas utiliser ». Par défaut le partitionneur marque toutes les partitions EFI « utiliser comme partition EFI ». A la fin du partitionnement il choisit la « première » marquée comme telle et la monte sur /boot/efi.

Ah si, le formatage fait perdre les données (le contenu). Mais pas la partition elle-même (le contenant).

#14

exact , et pourtant j’ai déjà eu à réaliser cette opération par le passé .

Il vaut mieux comparer l’UUID spécifié dans /etc/fstab avec celui des partitions actuelles et regarder les systèmes de fichiers montés (lsblk -f)

la comparaison des UUID confirme que /boot/efi était bien sur sda1 du disque interne .

merci pour toutes ces précisions .

suite:

  • n’aimant pas rester sur un échec j’ai repris l’installation en n’oubliant pas d’isoler sda1 où se trouve EFI de W10 et tout s’est bien passé : EFI est bien monté sur /boot/efi de mon ssd .

  • en me relisant je m’aperçois que j’ai vu des problèmes là où il n’y en avait pas sur des notions de base en plus . Pas brillant !

  • quant à mon « bios » UEFI je n’ai trouvé aucune info pour ma version et j’ai donc envoyé une demande au service technique de LDLC qui a assemblé ce modèle de portable .

#15

Come je l’ai écrit, il était possible de reconfigurer le système pour utiliser la partition EFI du SSD sans tout réinstaller.