logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 08-10-2022 16:02:58

DebUser
Membre
Inscription : 08-10-2022

[Résolu] Bascule OS sur nouveau disque avec LVM et /boot séparés

Bonjour,

J'ai changé de config et je souhaite passer sur un NVMe.
Tant qu'a faire, je souhaite aussi utiliser LVM.

Sur mon nouveau NVME en GPT :
- partition 1: Ext4 pour le /boot
- partition 2: LVM destiné à ma partition / et ses snapshots éventuels
- partition3 : Swap

J'ai tout partitionné.
J'ai crée mon PV sur /dev/nvme0n1p2, mon VG sur ce PV, et mon LV encore dessus. J'ai formaté mon LV en EXT4

J'ai monté mon LV sur /mnt
J'ai crée les répertoires mnt, media, proc, sys, dev, run dans /mnt
J'ai monté /dev/nvme0n1p1 sur /mnt/boot
J'ai copié mon système (à l'exception de /mnt, /media, /proc, /sys, /dev, /run) dans /mnt avec rsync
J'ai monté /proc /sys /dev dans /mnt
Je me suis chrooté dans /mnt
J'ai fait un dpkg-reconfigure pour que grub s'installe sur le MBR de /dev/nvme0n1
J'ai modifié le fstab pour indiquer les UUID (récupérés avec blkid) de mon nouveau /, nouveau /boot et nouveau swap

Problème, lorsque (toujours chrooté dans /mnt), je fais un update-grub, Grub ne montre pas ce nouveau système...

# update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
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
Found linux image: /boot/vmlinuz-5.19.7-xanmod1
Found initrd image: /boot/initrd.img-5.19.7-xanmod1
Found linux image: /boot/vmlinuz-5.10.0-18-amd64
Found initrd image: /boot/initrd.img-5.10.0-18-amd64
Found linux image: /boot/vmlinuz-5.10.0-8-amd64
Found initrd image: /boot/initrd.img-5.10.0-8-amd64
Found linux image: /boot/vmlinuz-5.10.0-7-amd64
Found initrd image: /boot/initrd.img-5.10.0-7-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Debian GNU/Linux 11 (bullseye) on /dev/sda1
Found Debian GNU/Linux 10 (buster) on /dev/sda5
done

C'est bien sur os-prober le problème :

# 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é).

Pourtant linux-boot-prober vois bien mes kernels dans ma partition /boot :

# linux-boot-prober /dev/nvme0n1p1
/dev/nvme0n1p1:/dev/nvme0n1p1::/vmlinuz-5.10.0-18-amd64:/initrd.img-5.10.0-18-amd64:root=/dev/nvme0n1p1
/dev/nvme0n1p1:/dev/nvme0n1p1::/vmlinuz-5.10.0-7-amd64:/initrd.img-5.10.0-7-amd64:root=/dev/nvme0n1p1
/dev/nvme0n1p1:/dev/nvme0n1p1::/vmlinuz-5.10.0-8-amd64:/initrd.img-5.10.0-8-amd64:root=/dev/nvme0n1p1
/dev/nvme0n1p1:/dev/nvme0n1p1::/vmlinuz-5.19.11-xanmod1:/initrd.img-5.19.11-xanmod1:root=/dev/nvme0n1p1
/dev/nvme0n1p1:/dev/nvme0n1p1::/vmlinuz-5.19.7-xanmod1:/initrd.img-5.19.7-xanmod1:root=/dev/nvme0n1p1
/dev/nvme0n1p1:/dev/nvme0n1p1::/vmlinuz-5.19.8-xanmod1:/initrd.img-5.19.8-xanmod1:root=/dev/nvme0n1p1

Sauf que la aussi j'ai l'impression qu'il y a un souci étant donné que la partition root n'est pas sur /dev/nvme0n1p1, mais dans un LV sur /dev/nvme0n1p2...

Quelqu'un peut-il m'aider ?

Par avance, merci !

Dernière modification par DebUser (09-10-2022 17:14:10)

Hors ligne

#2 08-10-2022 16:48:02

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Bascule OS sur nouveau disque avec LVM et /boot séparés

DebUser a écrit :

- 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 ?

DebUser a écrit :

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 ?

DebUser a écrit :

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.

DebUser a écrit :

# 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.

DebUser a écrit :

# 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

#3 08-10-2022 17:01:00

DebUser
Membre
Inscription : 08-10-2022

Re : [Résolu] Bascule OS sur nouveau disque avec LVM et /boot séparés

Bonjour raleur,

Merci pour ta réponse.

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

#4 08-10-2022 19:09:50

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Bascule OS sur nouveau disque avec LVM et /boot séparés

DebUser a écrit :

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.

DebUser a écrit :

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.

DebUser a écrit :

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.

DebUser a écrit :


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


DebUser a écrit :

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).

DebUser a écrit :

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

#5 09-10-2022 11:03:51

DebUser
Membre
Inscription : 08-10-2022

Re : [Résolu] Bascule OS sur nouveau disque avec LVM et /boot séparés

Bonjour raleur,

Merci pour toutes ces explications.

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 lol

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

#6 09-10-2022 14:06:05

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Bascule OS sur nouveau disque avec LVM et /boot séparés

Beaucoup de mes remarques peuvent sembler "cosmétiques" mais l'esthétique, ça compte pour la lisibilité.

DebUser a écrit :

Voici le déroulé complet


Le déroulement. "Déroulé" est un néologisme inutile dont les journaleux se gargarisent.

DebUser a écrit :

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.

DebUser a écrit :

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.

DebUser a écrit :

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 ?

DebUser a écrit :

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.

DebUser a écrit :

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.

DebUser a écrit :

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 ?

DebUser a écrit :

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.

DebUser a écrit :

modprobe efivarfs


Cette commande ne marche pas en mode legacy tant qu'on n'a pas démarré en mode UEFI.

DebUser a écrit :

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.

DebUser a écrit :

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.

DebUser a écrit :

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.

DebUser a écrit :

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.

DebUser a écrit :

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

#7 09-10-2022 14:47:05

DebUser
Membre
Inscription : 08-10-2022

Re : [Résolu] Bascule OS sur nouveau disque avec LVM et /boot séparés

Beaucoup de mes remarques peuvent sembler "cosmétiques" mais l'esthétique, ça compte pour la lisibilité.



Pas de problème smile

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

#8 09-10-2022 15:36:44

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Bascule OS sur nouveau disque avec LVM et /boot séparés

DebUser a écrit :

j'avais installé efibootmgr pour pouvoir lancer "modprobe efivarfs"


C'est efibootmgr qui a besoin de efivarfs, pas l'inverse.

DebUser a écrit :

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.

DebUser a écrit :

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.

DebUser a écrit :

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

#9 09-10-2022 15:46:14

DebUser
Membre
Inscription : 08-10-2022

Re : [Résolu] Bascule OS sur nouveau disque avec LVM et /boot séparés

J'ai supprimé comme suit (8 correspond à GRUBX64.EFI) : efibootmgr -b 8 -B

Suite à la suppression de l'entrée GRUBX64.EFI, ca ne boote plus (même problème que lorsque j’essayai de booter dessus).
Du coup j'ai rebooté en Legacy, et j'ai repassé cette commande (qui je confirme fonctionne) :
# grub-install --target=x86_64-efi --efi-directory=/boot/efi
Installation pour la plate-forme x86_64-efi.
grub-install : attention : EFI variables are not supported on this system..
Installation terminée, sans erreur.

Je peux reboot en EFI, mais ca veut dire que je dois laisser cette entrée.

Merci pour "dpkg-reconfigure grub-efi-amd64", je vais regarder ça.

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. smile

Dernière modification par DebUser (09-10-2022 15:52:28)

Hors ligne

#10 09-10-2022 16:39:17

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Bascule OS sur nouveau disque avec LVM et /boot séparés

DebUser a écrit :

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

#11 09-10-2022 17:12:23

DebUser
Membre
Inscription : 08-10-2022

Re : [Résolu] Bascule OS sur nouveau disque avec LVM et /boot séparés

Oui, je pense que c'est ce que je vais faire, merci encore !

Hors ligne

Pied de page des forums