Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Dernière modification par DebUser (09-10-2022 17:14:10)
Hors ligne
- partition 1: Ext4 pour le /boot
- partition 2: LVM destiné à ma partition / et ses snapshots éventuels
- partition3 : Swap
Pourquoi des partitions séparées pour /boot et le swap au lieu de les mettre dans LVM ?
Problème, lorsque (toujours chrooté dans /mnt), je fais un update-grub, Grub ne montre pas ce nouveau système
Et ça, c'est quoi ?
Found linux image: /boot/vmlinuz-5.19.11-xanmod1
Found initrd image: /boot/initrd.img-5.19.11-xanmod1
Found linux image: /boot/vmlinuz-5.19.8-xanmod1
Found initrd image: /boot/initrd.img-5.19.8-xanmod1
etc.
# os-prober
/dev/sda1:Debian GNU/Linux 11 (bullseye):Debian:linux
/dev/sda5:Debian GNU/Linux 10 (buster):Debian1:linux
Aucune mention de LVM ou de mon disque NVME, je ne vois que mes ancien disques/partition (dont l'actuelle Deb11 sur laquelle je suis booté).
os-prober ne rapporte jamais le système depuis lequel il est lancé. Son rôle est de détecter les autres systèmes.
# linux-boot-prober /dev/nvme0n1p1
Mauvaise commande, il faut exécuter linux-boot-prober avec le volume racine, pas le volume /boot.
Dernière modification par raleur (08-10-2022 16:48:41)
Il vaut mieux montrer que raconter.
Hors ligne
Pourquoi des partitions séparées pour /boot et le swap au lieu de les mettre dans LVM ?
J'ai regardé pas mal de forums, et beaucoup disent que mettre /boot sur LVM complique les choses, surtout en cas de problème de boot.
Pour le swap, il y a intérêt de mettre du LVM pour resize facilement, mais pas besoin de snapshot... c'est vrai que je pourrais le mettre sur LVM oui (je peux encore changer).
Et ça, c'est quoi ?
os-prober ne rapporte jamais le système depuis lequel il est lancé. Son rôle est de détecter les autres systèmes.
Ah ok, effectivement j'avais mal compris/lu le retour de update-grub et os-prober, la phrase "os-prober will be executed to detect other bootable partitions" est pourtant explicite, my mistake.
Mauvaise commande, il faut exécuter linux-boot-prober avec le volume racine, pas le volume /boot.
Ok, mais avec le volume racine, il ne détecte rien :
# linux-boot-prober /dev/mapper/rvg-rlv
#
Dans la description de linux-boot-prober il y a :
For example, for a system with a kernel at /boot/vmlinuz and an initramfs at /boot/initrd.gz, and with / on /dev/sda2 and /boot on
/dev/sda1, the command "linux-boot-prober /dev/sda1" will display:
/dev/sda2:/dev/sda1:Linux:/vmlinuz:/initrd.gz:root=/dev/sda1
Le seul truc c'est que dans l'exemple, la ligne commence par /dev/sda2, ce qui correspond a la racine, alors que moi j'ai /dev/nvme0n1p1, ce qui correspond à mon /boot
Bon, j'ai essayé de booter sur mon NVME, j'ai juste "GRUB _" qui s'affiche. (même pas d'invit grub-rescue)
Dernière modification par DebUser (08-10-2022 17:53:11)
Hors ligne
beaucoup disent que mettre /boot sur LVM complique les choses
Pas à l'installation, au contraire c'est plus simple puisqu'on a une partition de moins à gérer.
surtout en cas de problème de boot.
Mouais bof. En cas de problème grave de LVM, c'est vrai qu'une partition /boot séparée permet au moins de lancer le noyau et l'initramfs mais pas de monter la racine donc il faut encore être capable se débrouiller avec les ressources limitées de l'initramfs pour dépanner.
Pour le swap, il y a intérêt de mettre du LVM pour resize facilement, mais pas besoin de snapshot
Les snapshots se font par volume logique, on n'est pas obligé d'en faire pour le swap.
Dans la description de linux-boot-prober il y a :
For example, for a system with a kernel at /boot/vmlinuz and an initramfs at /boot/initrd.gz, and with / on /dev/sda2 and /boot on
/dev/sda1, the command "linux-boot-prober /dev/sda1" will display:
Quelle description ? Dans le fichier /usr/share/doc/os-prober/README installé par le paquet os-prober, je lis :
The linux-boot-prober command should be run with a single argument consisting of a partition that is known to have a linux root filesystem on it
Ok, mais avec le volume racine, il ne détecte rien
linux-boot-prober ne fait pas de recherche si le volume spécifié est monté sur /, /target ou /target/boot (les deux derniers sont utilisés par l'installateur pour monter le système en cours d'installation). On peut le voir dans /usr/bin/linux-boot-prober (c'est un script shell).
j'ai essayé de booter sur mon NVME, j'ai juste "GRUB _" qui s'affiche. (même pas d'invit grub-rescue)
L'affichage de "GRUB" sans "loading" signifie que la boot image de GRUB (dans le MBR) a été chargée et exécutée mais pas la core image.
Lors de la réinstallation de GRUB, as-tu bien spécifié le disque entier et pas la partition /boot ?
Comme tu as choisi le partitionnement GPT, as-tu bien créé une petite partition de type "BIOS boot" au début du disque ? Dans le cas contraire la core image de GRUB est installée pour charger le fichier /boot/grub/i386-pc/core.img en utilisant les listes de blocs, ce qui est déconseillé car l'emplacement physique du fichier peut changer et la liste de blocs ne serait plus valide.
Dernière modification par raleur (08-10-2022 19:17:15)
Il vaut mieux montrer que raconter.
Hors ligne
Les snapshots se font par volume logique, on n'est pas obligé d'en faire pour le swap.
Oui tout à fait, je réfléchissait a voix haute si on peut dire ainsi, et effectivement les possibilités ne serait-ce qu'en terme de resize peuvent être intéressantes.
En lisant le reste de ton commentaire, j'ai compris qu'il y a fait un souci au niveau de la procédure RTFM, car effectivement je n'avais pas de partition bios-boot 
J'ai donc tout refais proprement, et je me suis dit pourquoi ne pas essayer le boot legacy, et l'EFI.
Voici le déroulé complet :
Installation des outils pour gérer le FAT32 et l'EFI:
apt install dosfstools mtools efibootmgr grub-efi
Création des partitions et FS :
parted /dev/nvme0n1 --script mklabel gpt
parted /dev/nvme0n1 --script mkpart primary 1048576b 34602496b name 1 bios-boot-part set 1 bios_grub on
parted /dev/nvme0n1 --script mkpart primary 34603008b 571473408b name 2 efi-part set 2 boot on set 2 esp on
parted /dev/nvme0n1 --script mkpart primary 571473920b 1000204140032b name 3 lvm-part set 3 LVM on
pvcreate /dev/nvme0n1p3
vgcreate rvg /dev/nvme0n1p3
lvcreate -L600Gib -n rlv rvg
lvcreate -L130Gib -n slv rvg
mkfs.vfat /dev/nvme0n1p2 -n EFI
mke2fs -t ext4 /dev/mapper/rvg-rlv -L root-fs
mkswap /dev/mapper/rvg-slv -L "swap-fs"
Copie du système (oui mon /home est sur un autre disque donc je ne le copie pas) :
mount /dev/mapper/rvg-rlv /mnt
mkdir /mnt/{proc,sys,dev,run,mnt,media,home}
rsync -av --progress / /mnt/ --exclude /home --exclude /mnt --exclude /media --exclude /proc --exclude /sys --exclude /dev --exclude /run
Modification de /mnt/etc/fstab avec les ID retournés par blkid :
none /dev/shm tmpfs defaults,noexec,nosuid,nodev 0 0
UUID=91F9-D5FD /boot/efi vfat defaults 0 0
UUID=0d16876b-1063-488a-b48d-3f53e6774593 / ext4 errors=remount-ro 0 1
UUID=ab4d68e6-1169-494a-a7ea-d65fa3f7d7bb /home ext4 errors=remount-ro 0 1
UUID=754f95ae-5b96-4080-bc76-5eca6a452210 none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
tmpfs /tmp tmpfs defaults,relatime,mode=1777,nosuid,size=4196M 0 0
Paramétrage du Grub :
modprobe efivarfs
mount /dev/mapper/rvg-rlv /mnt
mkdir /mnt/boot/efi
mount /dev/nvme0n1p2 /mnt/boot/efi
for i in proc sys dev; do mount -B /$i /mnt/$i ;done
chroot /mnt
dpkg-reconfigure grub-pc
grub-install --target=x86_64-efi --efi-directory=/boot/efi
mkdir /boot/efi/EFI/boot/
cp /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/boot/bootx64.efi
grub-install /dev/nvme0n1
update-grub
Reboot sur le NVME en mode EFI (le mode Legacy fonctionne), puis :
efibootmgr -v
rm /boot/efi/EFI/boot/bootx64.efi
grub-install /dev/nvme0n1
update-grub
Bizarrement le boot EFI fonctionne avec SHIMX64.EFI, mais pas GRUBX64.EFI, dans ce dernier cas, j'ai des messages d'erreur au démarrage :
[FAILED] Failed to start daily apt download activities.
[FAILED] Failed to start daily apt upgrade and clean activities.
[...]
[FAILED] Failed to start LSB: This workstation as a server daemon.
Ce n'est pas gravissime, mais une de mes 2 entrées EFI ne fonctionne pas du coup.
Dernière modification par DebUser (09-10-2022 11:18:35)
Hors ligne
Voici le déroulé complet
Le déroulement. "Déroulé" est un néologisme inutile dont les journaleux se gargarisent.
apt install dosfstools mtools efibootmgr grub-efi
Le paquet mtools est inutile.
L'installation de grub-efi ou de sa dépendance grub-efi-<archi> entraîne l'installation automatique du chargeur d'amorçage qui va planter immanquablement si le système n'a pas été préparé pour ou n'a pas été amorcé en mode EFI. Si le but est d'installer le chargeur manuellement avec grub-install, il vaut mieux installer seulement grub-efi-<archi>-bin. A mon avis il aurait mieux valu installer grub-efi dans le chroot du nouveau système.
parted /dev/nvme0n1 --script mklabel gpt
parted /dev/nvme0n1 --script mkpart primary 1048576b 34602496b name 1 bios-boot-part set 1 bios_grub on
parted /dev/nvme0n1 --script mkpart primary 34603008b 571473408b name 2 efi-part set 2 boot on set 2 esp on
parted /dev/nvme0n1 --script mkpart primary 571473920b 1000204140032b name 3 lvm-part set 3 LVM on
Pourquoi n'avoir pas nommé directement les partitions lors de leur création au lieu de les nommer "primary" puis les renommer ensuite ?
Pas besoin de mettre "-part" dans les noms, on sait que ce sont des noms de partitions.
Le nom traditionnel de la partition EFI est "EFI System Partition".
En GPT, les drapeaux "boot" et "esp" sont synonymes, pas besoin de les mettre tous les deux.
vgcreate rvg /dev/nvme0n1p3
lvcreate -L600Gib -n rlv rvg
lvcreate -L130Gib -n slv rvg
Ces noms de VG et LV sont nuls. Pas besoin de les suffixer par "vg" ou "lv", on sait que ce sont des noms de VG et LV. Quant à ce qui reste "r" et "s", ce n'est franchement pas explicite même si je devine dans le contexte que ça veut dire "racine" et "swap" pour les LV.
Tu as vraiment besoin de 130 Gio de swap ?
mke2fs -t ext4 /dev/mapper/rvg-rlv -L root-fs
Pas besoin de suffixer par "-fs", on sait très bien que c'est une étiquette de système de fichiers.
mkswap /dev/mapper/rvg-slv -L "swap-fs"
Le suffixe "-fs" est encore plus inapproprié ici car le swap n'est pas un système de fichiers.
mon /home est sur un autre disque
Un SSD aussi ? Sinon, une raison particulière de ne pas le faire bénéficier de la vitesse du SSD ?
none /dev/shm tmpfs defaults,noexec,nosuid,nodev 0 0
UUID=0d16876b-1063-488a-b48d-3f53e6774593 / ext4 errors=remount-ro 0 1
UUID=754f95ae-5b96-4080-bc76-5eca6a452210 none swap sw 0 0
Je n'ai jamais eu besoin de mettre /dev/shm dans /etc/fstab, c'est monté implicitement au démarrage.
Il est d'usage (c'est ce que l'installateur fait) d'identifier les volumes logiques non par leur UUID mais par leur nom de périphérique /dev/mapper/<vg>-<lv>. Ces noms sont persistants et plus lisibles qu'un UUID. Les scripts de l'initramfs en ont d'ailleurs besoin pour savoir qu'il s'agit de volumes logiques et activer les VG correspondants.
modprobe efivarfs
Cette commande ne marche pas en mode legacy tant qu'on n'a pas démarré en mode UEFI.
grub-install --target=x86_64-efi --efi-directory=/boot/efi
--efi-directory=/boot/efi est déjà par défaut, inutile de le spécifier.
En mode UEFI, --target=x86_64-efi est déjà par défaut donc inutile de le spécifier.
En mode legacy, la commande terminera en erreur car elle échouera à mettre à jour les variables de boot EFI à moins de spécifier --no-nvram.
cp /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/boot/bootx64.efi
Mauvaise méthode. Si la variante signée de GRUB (avec shim) est installée, ce n'est pas grubx64.efi mais shimx64.efi qu'il faut copier en tant que bootx64.efi, et copier grubx64.efi en tant que tel.
L'option --force-extra-removable de grub-install, voire la commande "dpkg-reconfigure grub-efi-amd64" en choisissant le chemin de support amovible fait tout ça proprement.
grub-install /dev/nvme0n1
Commande inutile. En mode legacy, elle ne fait rien de plus que ce qui devrait avoir été déjà fait par "dpkg-reconfigure grub-pc". En mode UEFI, l'argument /dev/* est ignoré et cela installe GRUB EFI avec les options par défaut.
Reboot sur le NVME en mode EFI (le mode Legacy fonctionne), puis
Toutes ces commandes sont inutiles si ça boote déjà en mode EFI. update-grub ajoutera une entrée au menu pour accéder aux paramètres du firmware UEFI, mais c'est franchement secondaire, on peut y accéder directement sans passer par GRUB.
Il vaut mieux laisser GRUB dans le chemin de support amovible en permanence car les variables de boot EFI ne sont pas toujours très fiables. C'est ce que font Windows et d'autres distributions.
Bizarrement le boot EFI fonctionne avec SHIMX64.EFI, mais pas GRUBX64.EFI, dans ce dernier cas, j'ai des messages d'erreur au démarrage
A ma connaissance shim n'est qu'un intermédiaire entre le firmware UEFI et GRUB et ne sert que si le secure boot est activé. Dans ce cas le firmware UEFI devrait refuser de lancer GRUB directement. En tout cas je ne vois pas le rapport avec apt, et de toute façon il n'y a pas lieu d'y avoir une entrée EFI pour grubx64.efi.
Il vaut mieux montrer que raconter.
Hors ligne
Beaucoup de mes remarques peuvent sembler "cosmétiques" mais l'esthétique, ça compte pour la lisibilité.
Pas de problème 
Le déroulement. "Déroulé" est un néologisme inutile dont les journaleux se gargarisent.
C'est vrai, merci pour le rappel. D'ailleurs je suis le premier à râler quand j'entends des trucs du genre "tirer les conséquences...", et je ne parle pas du digital, cryptage...
A mon avis il aurait mieux valu installer grub-efi dans le chroot du nouveau système.
Entièrement d'accord, en fait j'avais installé efibootmgr pour pouvoir lancer "modprobe efivarfs" avant d'entrer dans le chroot suite à un message d'erreur pour lequel j'avais et des recherches, mais oui, la remarque est pertinente, merci.
Pourquoi n'avoir pas nommé directement les partitions lors de leur création au lieu de les nommer "primary" puis les renommer ensuite ?
Dans le --help de parted, j'ai vu ça :
mkpart PART-TYPE [FS-TYPE] START END make a partition
Du coup j'ai mis primary, même si en gpt il n'y a pas de notion de primaire/étendue.
Tu insinues que ceci fais la même chose :
parted /dev/nvme0n1 --script mkpart bios-boot-part 1048576b 34602496b set 1 bios_grub on
que cela (en moins redondant) ?:
parted /dev/nvme0n1 --script mkpart primary 1048576b 34602496b name 1 bios-boot-part set 1 bios_grub on
Pour tous les suffixes, que ce soit les -part, -fs, Xvg, Xlv, je préfère ainsi, même si on est d'accord ça n'apporte pas grand chose, ça permet de voir ou sont les choses et comment elles sont affichées.
Ceci pour éviter les trucs du style que j'ai vu sur le net ou on peut trouver des articles sur comment nommer ses partitions, avec ensuite les commandes pour mettre un label sur les FS.
Tu as effectivement deviné juste pour le "r" et le "s".
Je suppose qu'au bout d'un moment, je pourrais changer tout ça, car je ne configure qu'avec les UUID.
Le suffixe "-fs" est encore plus inapproprié ici car le swap n'est pas un système de fichiers.
Oui j'avoue. swap-blob alors ? (humour, la question n'attend pas forcément de réponse)
Tu as vraiment besoin de 130 Gio de swap ?
Ça me parait beaucoup aussi, idem j'ai lu des articles ou il y a indiqué qu'il faut la taille de la RAM + 2Go, avec même un tableau. dans les 2 cas ça me donne 130Go.
Du coup le swap en LVM ca va permettre de modifier ça si il le faut.
Un SSD aussi ? Sinon, une raison particulière de ne pas le faire bénéficier de la vitesse du SSD ?
Un disque mécanique de 3To, maintenant que la racine est OK, j'ai un raid soft sur 3xSSD 2To qui synchronise pour son remplacement.
Je n'ai jamais eu besoin de mettre /dev/shm dans /etc/fstab, c'est monté implicitement au démarrage.
Pour le coup ça ne vient pas de moi, c'était déjà dans le fstab.
En mode legacy, la commande terminera en erreur car elle échouera à mettre à jour les variables de boot EFI à moins de spécifier --no-nvram.
J'ai du mal a comprendre, car il est certain que j'étais en Legacy quand j'ai passé la commande (je n'avais pas encore rebooté en EFI, et efibootmgr -v ne renvoyait rien), et elle a fonctionné.
Mauvaise méthode. Si la variante signée de GRUB (avec shim) est installée, ce n'est pas grubx64.efi mais shimx64.efi qu'il faut copier en tant que bootx64.efi, et copier grubx64.efi en tant que tel.
L'option --force-extra-removable de grub-install, voire la commande "dpkg-reconfigure grub-efi-amd64" en choisissant le chemin de support amovible fait tout ça proprement.
Peut-être une mauvaise méthode, mais elle a fonctionné car j'ai ensuite pu booter en EFI (même si je ne comprend pas toutes les implications de ces commandes)
Commande inutile. En mode legacy, elle ne fait rien de plus que ce qui devrait avoir été déjà fait par "dpkg-reconfigure grub-pc".
Exact.
Toutes ces commandes sont inutiles si ça boote déjà en mode EFI. update-grub ajoutera une entrée au menu pour accéder aux paramètres du firmware UEFI, mais c'est franchement secondaire, on peut y accéder directement sans passer par GRUB.
Il vaut mieux laisser GRUB dans le chemin de support amovible en permanence car les variables de boot EFI ne sont pas toujours très fiables. C'est ce que font Windows et d'autres distributions.
Pour être sur, ca veut dire ne pas faire le rm ?
Quand Grub est mis à jour, il faudra que je re "cp" ce fichier du coup ?
A ma connaissance shim n'est qu'un intermédiaire entre le firmware UEFI et GRUB et ne sert que si le secure boot est activé. Dans ce cas le firmware UEFI devrait refuser de lancer GRUB directement. En tout cas je ne vois pas le rapport avec apt, et de toute façon il n'y a pas lieu d'y avoir une entrée EFI pour grubx64.efi.
Je ne vois pas le rapport non plus.
Si il n'y a pas lieu d'avoir cette entrée, peut-on la retirer ?
Dernière modification par DebUser (09-10-2022 15:46:29)
Hors ligne
j'avais installé efibootmgr pour pouvoir lancer "modprobe efivarfs"
C'est efibootmgr qui a besoin de efivarfs, pas l'inverse.
j'ai lu des articles ou il y a indiqué qu'il faut la taille de la RAM + 2Go
Cette formule est absurde. La quantité de swap nécessaire dépend de l'usage et pas de la quantité de RAM, même pour l'hibernation.
Pour être sur, ca veut dire ne pas faire le rm ?
Quand Grub est mis à jour, il faudra que je re "cp" ce fichier du coup ?
D'où l'intérêt de choisir le chemin de support amovible dans "dpkg-reconfigure grub-efi-amd64" qui s'occupera de ça automatiquement.
Si il n'y a pas lieu d'avoir cette entrée, peut-on la retirer ?
Oui, avec efibootmgr.
Il vaut mieux montrer que raconter.
Hors ligne
Cette formule est absurde. La quantité de swap nécessaire dépend de l'usage et pas de la quantité de RAM, même pour l'hibernation.
Cela confirme les doutes que j'avais.
Après tant que je n'ai pas de problème d'espace, pas besoin d'y toucher, et grâce a ton excellent conseil de mettre aussi le swap sur LVM, si je dois y toucher cela sera relativement simple.
Dernière modification par DebUser (09-10-2022 15:52:28)
Hors ligne
Je peux reboot en EFI, mais ca veut dire que je dois laisser cette entrée.
Là je ne comprends pas. Ta commande grub-install exécutée en mode legacy ne peut pas avoir recréé l'entrée.
Je vois que l'amorçage UEFI est toujours aussi capricieux et peu fiable... Pour les choses sérieuses je continuerai à privilégier l'amorçage legacy tant qu'il est disponible, et l'amorçage UEFI seulement pour m'amuser à découvrir ses innonmbrables bugs.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne