Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Passer Ubuntu du mode bios au mode UEFI.

Tekilou

Bonjour,

J’utilise sur mon ordinateur Ubuntu 20.04 (initialement une 14.04 si mes souvenirs sont bons, que j’update depuis) en single boot.

Je souhaite le passer en UEFI pour profiter du boot « flicker free ».

Après quelques recherches, je ne trouve pas comment faire. Soit la situation décrite ne correspond pas à la mienne, soit l’explication est trop compliquée pour moi, etc.
Du coup, j’hésite à me lancer sachant que mon système fonctionne vraiment très bien et que, depuis le temps qu’il est installé, il est vraiment fait à ma main.

Voici donc mes deux questions :

-Comment passer mon système du mode bios au mode UEFI ?
-En cas de problème, puis-je restaurer mon système avec une image clonezilla (mode disk to image) ? Sera-t-il « bootable » à nouveau ? (la question peut sembler bête car c’est à ça que sert une image, mais j’aurai quand même le coeur plus léger si vous me le confirmiez.)

Quelques infos sur mon système :

-Ubuntu 20.04 updaté depuis une 14.04
-Installé en mode bios
-Single boot
-Disque dur en mode LVM avec une partition /boot (même si je ne sais pas vraiment ce que ça implique)
-Dossier « home » chiffré à l’installation (seulement home, pas le disque en entier).

N’hésitez pas si vous avez besoin d’infos complémentaires ou de retours de commandes.

Merci d’avance !

lucmars

A ma connaissance il te faut réinstaller en EFI mais, si la conversion serait possible, ton installe a de belles casserolles : partoche /boot ; LVM et cryptage, bref autant de nids d'emmerdes qui malgré tes mises à niveau n'ont pas posés de soucis.

Tekilou

Effectivement, les recherches que j'ai faites pour résoudre mon problème m’ont confirmé que mes choix d'installation n'étaient pas les plus populaires (pour le dire gentiment ;-) ).

Et si pour moi le chiffrement de mon home est indispensable (en cas de perte de mon ordinateur), je n'aurais certainement pas installé en LVM si j'avais su.

À ma décharge, c'était la première installation de Linux de ma vie et j'ai fait avec mes faibles connaissances du système.

Ça a tellement bien marché dès le départ et depuis que je tourne dessus depuis lors sans jamais avoir ressenti le besoin de réinstaller.

lucmars

Depuis le début ton DD est préparé pour une installe bios (table ms-dos). Dans le principe on y case une partoche EFI en fat32 et ça le fait mais c'est cradingue et vu ton usine vas-y pour la caser !

Dans le principe cela aurait permis de garder ta partoche /home lors de la réinstalle en efi; mais c'est un reve !

Donc tu sauvergardes tes bijoux et tu refais tout :
1- tu crées un support 2004 et tu t'assures de la booter en efi (pour faire une installe efi)
2- en live avec gparted, tu passes la table du dd en en gpt (t'auras droit à 128 moins une partoche primaire)
3- tu fais ton installe en mode "autre chose", je te laisse la main, mais tu oublies LVM

Note: plus besoin d'une partoche swap, c'est désormais un fichier et la swapiness serait bien réglée.

malbo

Tekilou a écrit Je souhaite le passer en UEFI pour profiter du boot « flicker free ».

Bonjour,
C'est quoi le boot « flicker free » ?
D'autre part, c'est quoi le nom du modèle de ton ordi et son fabricant ?

Tekilou

@lucmars

Réinstaller, c'est précisément ce que je cherche à éviter.
Ça doit bien être possible d'une manière ou d'une autre.

Si j'en crois gparted, je n'ai ni partition home ni partition swap, juste une /boot en ext2 de 487mo (sda1) suivie d'une partition extended (sda2) intégralement remplie par une partition lvm2 pv (sda5).

@malbo

Le boot flicker free est un système qui permet de booter l'ordi avec le même splash screen et la même résolution de l'appui sur le bouton power à l'écran de login. On évite ainsi la séquence POST/logo du constructeur, splash screen de l'os puis écran de login ainsi que les changements de résolution et le "flickering" qui vont avec.
Ça donne à la séquence de boot un aspect plus moderne, mieux fini.

Ma machine est un Asus Zenbook comme celui-ci.

lucmars

tekilou a écrit@lucmars

Réinstaller, c'est précisément ce que je cherche à éviter.
Ça doit bien être possible d'une manière ou d'une autre.

Si j'en crois gparted, je n'ai ni partition home ni partition swap, juste une /boot en ext2 de 487mo (sda1) suivie d'une partition extended (sda2) intégralement remplie par une partition lvm2 pv (sda5).

Si donc tu n'as pas de partition /home alors quoique tu tentes ce sera une réinstalle complète; t'oublies le lvm et sa partoche /boot et depuis quelques années seul le home est cryptable.

Avec une partoche /home tu n'aurais eu qu'à réinstaller la racine, enfin dans le principe.

geole

Bonsoir,
Pour booter en EFI, la première condition est d'avoir un disque ayant une table de partition GPT.
avec la version 14.04, je sais que tu ne possèdes pas cela puisque tu dis avoir une partition extended incompatible.
Nota. il est possible que testdisk sache convertir...
Si tu as un autre disque formaté gpt, tu lances boot-repair en faisant attention de bien booter en efi et il installe tout ce qui manque. A condition que ton ordinateur sache booter en EFI.

Quel est l'intérêt d'avoir une autre photo affichée alors que les ordinateurs bootent de plus en plus vite.
https://bugs.launchpad.net/ubuntu/+bugs?field.tag=flickerfreeboot&_ga=2.51894377.159936037.1590179396-2051492058.1575502823

malbo

Bonjour,
Je te prie de faire un Boot-info depuis une session de ton Ubuntu 20.04 installé et de donner l'URL de ce Boot-info dans ta réponse.

Nasman

A priori :
- Une table gpt n'est pas indispensable pour booter en efi sur ubuntu (pour Windows c'est différent)
- Si la partition /boot dédiée n'est pas chiffrée, alors les fichiers de boot pour efi pourront s'y loger (il faudra néanmoins une partition efi).

Donc en théorie, je pense que c'est possible (sans doute avec un grub-install pour l'efi) mais compte tenu du chiffrement et autres nids à emmerdes (lvm), je ne le tenterais que sur une installation de test.

maxire

Salut,
+1 avec Nasman et ce n'est pas de la théorie mais de la pratique, créer un partition ESP (Efi system partition) fat de 50MO suffira puis réinstaller grub en mode uefi.
Mais avant cela fournir le boot-info demandé par Malbo.

ikewdu

Salut,

Pour info, j'ai fait une démo de ce genre ici : http://ikewdu.free.fr/convertir-une-xubuntu-19-04-de-mbr-a-gpt/
Mais comme vous tous, je ne me lancerais pas dans cette manip sur une installation chiffrée avec format LVM.

maxire

Salut Ikewdu,

Comme déjà indiqué par Nasman et confirmé par moi-même une installation de Linux en mode uefi ne nécessite pas une table de partitions GPT mais uniquement qu'une partition FAT existe et peu importe le type de la table de partitions.
C'est Microsoft qui impose cette restriction de table de partitions à GPT.
LVM ne pose pas de problème en tant que tel, Ubuntu reconnaît parfaitement les volumes LVM y compris en live-usb seule la partie utilisateur est chiffrée et celle-ci est inutile pour installer un mode UEFI.
Donc en utilisant une Live-USB je ne vois pas de problème particulier.
J'ajoute que Takilou peut parfaitement retailler /dev/sda1 pour créer une partition fat ESP en utilisant Gparted sous son Ubuntu installé puis sans même redémarrer installer Grub-efi.
C'est en réalité très simple.
J'ai juste un doute sur la possibilité de démarrer simplement en mode uefi suite à une installation de Grub-efi forcée sous le mode Bios/Legacy, la NVRAM ne pouvant alors être mise à jour.
Cela dépend du matériel.

maxire

[HS]
Intéressant, je viens de m'apercevoir que l'installation en mode assisté de Ubuntu 20.04 crée une partition ESP référencée dans la fstab et ceci en utilisant une table de partitions MBR/DOS.
Je n'utilise pas d'images ISO pour mes installations mais une installation en mode réseau via un serveur tftp, c'est peut-être la raison.
Pas encore testé une installation à partir d'une image disque standard, et chez vous cela se passe comment ?.
[/HS]

ikewdu

Re,

En effet, je sais que les distributions Linux sont souples au regard du format de disque. Mais comme 90 % des utilisateurs ont des dual-boot, je me limite aux configurations standards.

geole

Un certain nombre de bios LEGACY ne réussisent pas à booter lorsque le flag de boot est positionné sur une partition logique contenue dans une partition primaire.
Il en est de même pour un boot EFI probablement dans 99,9999% des cas.

Mais le fond du problème est que le bios legacy fonctionne parfaitement bien et qu'il n'y a absolument aucune raison de le modifier!!!!!
Surtout tester pour un truc expérimental qui n'a absolument auucun avenir.

Tekilou

Re,

Avant toute chose, merci pour toutes vos réponses très instructives.
Voici le boot-info demandé par Malbo.

Après vous avoir lu, j’émets l’hypothèse suivante :
Ne pourrai-je pas simplement :

-reformater ma partition /boot (actuellement en ext2) en fat32
-passer le bios du mode legacy au mode UEFI
-booter sur un live-usb et faire un boot-repair qui réécrirait automatiquement la partition /boot en mode UEFI ?

Étant entendu que :

-mon ordinateur gère l’UEFI
-que Linux ne demande pas que la table de partition soit en GPT pour booter en UEFI
-que, comme l’écrivait Maxire, seule ma partie utilisateur est chiffrée
-que, d’après son propre sourceforge, boot-repair sait gérer le LVM

ça devrait passer ! :-)

De toute façon, je ne me lance dans rien sans avoir sauvegardé !

D’ailleurs, j’en profite pour reposer la question de mon premier post : si je fais une image intégrale de mon SSD (avec clonezilla, en mode disk-to-image) puis-je espérer retrouver mon système « comme avant » en réinstallant cette image et en repassant le BIOS en legacy ?
J’imagine que oui, mais une confirmation me rassurerait.

Du coup, voici mes questions :

-la stratégie ci-dessus à t-elle une chance de fonctionner ?
-Si ça plante, puis-je réinstaller mon système avec une image intégrale clonezilla ?
-Ai-je raison de vouloir faire réécrire ma partition /boot par boot-repair au lieu d’en créer une autre « spéciale EFI » ?

geole

Bonjour
Il est nettement préférable de ne pas supprimer cette partition car elle met en route le UBUNTU contenu dans du LVM

sda1: __________________________________________________________________________
    File system:       ext2
    Boot sector type:  -
    Boot sector info: 
    Operating System:  
    Boot files:        /grub/grub.cfg /grub/i386-pc/core.img

Il faut que tu trouves le moyen de fabriquer une nouvelle partition dont la taille doit faire au moins 36 Mo (Méga octets) au format FAT32 en lui mettant un drapeau BOOT.

Puis trouver une solution pour y mettre la structure de boot EFI . Cette structure de boot EFI ira activer ce qui est contenu dans SDA1

Je suis incapable de te dire si boot-repair va savoir le proposer dans ce contexte Sinon, il faudra le faire en technique chroot.

Après il faudra voir si ton bios accepte de booter en EFI avec une partition sur un disque interne "MS-DOS". De préférence fabrique une partition primaire et pas une partition logique.

Si la sauvegarde est bonne, cela devrait se restorer à l'identique . Mais pourquoi clonezilla alors que tu disposes de gnome disk utility dans ton support d'installation? ( https://doc.ubuntu-fr.org/gnome-disk-utility#copierrestaurercloner_un_disque_entier )

malbo

Bonjour,
Le Boot-info dont tu as donné le lien ( https://paste.ubuntu.com/p/cXpW7RFv4s/ ) dans le post #17 est là :

boot-info-4ppa123                                              [20200525_1745]

============================== Boot Info Summary ===============================

 => Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 1 of 
    the same hard drive for core.img. core.img is at this location and looks 
    for (,msdos1)/grub. It also embeds following components:
    
    modules
    ---------------------------------------------------------------------------
    fshelp ext2 part_msdos biosdisk
    ---------------------------------------------------------------------------

sda1: __________________________________________________________________________

    File system:       ext2
    Boot sector type:  -
    Boot sector info: 
    Operating System:  
    Boot files:        /grub/grub.cfg /grub/i386-pc/core.img

sda2: __________________________________________________________________________

    File system:       Extended Partition
    Boot sector type:  Unknown
    Boot sector info: 

sda5: __________________________________________________________________________

    File system:       LVM2_member
    Boot sector type:  -
    Boot sector info: 


================================ 2 OS detected =================================

OS#1:   L'OS actuellement utilisÃ© - Ubuntu 20.04 LTS CurrentSession on mapper/ubuntu--vg-root
OS#2:   Ubuntu 20.04 LTS on sda1

============================ Architecture/Host Info ============================

CPU architecture: 64-bit
BOOT_IMAGE of the installed session in use:
/vmlinuz-5.4.0-31-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash acpi_sleep=nonvs vt.handoff=7


===================================== UEFI =====================================

This installed-session is not in EFI-mode.
EFI in dmesg.
[    0.011669] ACPI: UEFI 0x0000000086CF0F18 000042 (v01                 00000000      00000000)



============================= Drive/Partition Info =============================

Disks info: ____________________________________________________________________

sda	: notGPT,	no-BIOSboot,	has-noESP, 	not-usb,	not-mmc, has-os,	2048 sectors * 512 bytes

Partitions info (1/3): _________________________________________________________

mapper/ubuntu--vg-root	: is-os,	64, apt-get,	grub-pc ,	grub2,	grub-install,	grubenv-ok,	update-grub,	not-far
sda1	: is-os,	64, apt-get,	grub-pc ,	grub2,	grub-install,	grubenv-ok,	update-grub,	not-far

Partitions info (2/3): _________________________________________________________

mapper/ubuntu--vg-root	: isnotESP,	fstab-without-efi,	no-nt,	no-winload,	no-recov-nor-hid,	no-bmgr,	notwinboot
sda1	: isnotESP,	fstab-without-efi,	no-nt,	no-winload,	no-recov-nor-hid,	no-bmgr,	notwinboot

Partitions info (3/3): _________________________________________________________

mapper/ubuntu--vg-root	: not-sepboot,	with-boot,	fstab-has-bad-boot,	not-sep-usr,	with--usr,	fstab-without-usr,	std-grub.d,	sda
sda1	: not-sepboot,	with-boot,	fstab-has-bad-boot,	not-sep-usr,	with--usr,	fstab-without-usr,	std-grub.d,	sda

fdisk -l (filtered): ___________________________________________________________

Disk sda: 238.49 GiB, 256060514304 bytes, 500118192 sectors
Disk identifier: 0x499d5cc3
      Boot   Start       End   Sectors  Size Id Type
sda1  *       2048    999423    997376  487M 83 Linux
sda2       1001470 500117503 499116034  238G  5 Extended
sda5       1001472 500117503 499116032  238G 8e Linux LVM
Disk mapper/ubuntu--vg-root: 230.5 GiB, 247015145472 bytes, 482451456 sectors
Disk mapper/ubuntu--vg-swap_1: 7.92 GiB, 8480882688 bytes, 16564224 sectors
Disk mapper/cryptswap1: 7.92 GiB, 8480358400 bytes, 16563200 sectors

parted -lm (filtered): _________________________________________________________

sda:256GB:scsi:512:512:msdos:ATA HFS256G32MND-220:;
1:1049kB:512MB:511MB:ext2::boot;
2:513MB:256GB:256GB:::;
5:513MB:256GB:256GB:::lvm;
mapper/cryptswap1:8480MB:dm:512:512:loop:Linux device-mapper (crypt):;
1:0.00B:8480MB:8480MB:linux-swap(v1)::;
mapper/ubuntu--vg-swap_1:8481MB:dm:512:512:loop:Linux device-mapper (linear):;
1:0.00B:8481MB:8481MB:linux-swap(v1)::;
mapper/ubuntu--vg-root:247GB:dm:512:512:loop:Linux device-mapper (linear):;
1:0.00B:247GB:247GB:ext4::;

blkid (filtered): ______________________________________________________________

NAME                  FSTYPE      UUID                                   PARTUUID                             LABEL PARTLABEL
sda                                                                                                                 
â”œâ”€sda1                ext2        951b56a7-727f-4c66-b702-0e1ce66fbe44   499d5cc3-01                                
â”œâ”€sda2                                                                   499d5cc3-02                                
â””â”€sda5                LVM2_member d72npw-A63E-fKbE-HOTb-pF03-rBly-ee1qq8 499d5cc3-05                                
  â”œâ”€ubuntu--vg-root   ext4        591d1e20-b6be-449f-84c4-7bc817c5aa94                                              
  â””â”€ubuntu--vg-swap_1 swap        51cbd14b-9a57-4c67-966f-7409b40c8614                                              
    â””â”€cryptswap1      swap        ec680cac-99fd-4224-8c65-d7c4aefe19a4                                              

df (filtered): _________________________________________________________________

                        Avail Use% Mounted on
mapper/ubuntu--vg-root  96.7G  52% /
sda1                   241.9M  44% /boot

Mount options: __________________________________________________________________

mapper/ubuntu--vg-root rw,relatime,errors=remount-ro
sda1                   rw,relatime

============================== ls -R /dev/mapper/ ==============================

/dev/mapper:
control
cryptswap1
ubuntu--vg-root
ubuntu--vg-swap_1

======================== sda1/grub/grub.cfg (filtered) =========================

Ubuntu   591d1e20-b6be-449f-84c4-7bc817c5aa94
Ubuntu, avec Linux 5.4.0-31-generic   591d1e20-b6be-449f-84c4-7bc817c5aa94
Ubuntu, avec Linux 5.4.0-29-generic   591d1e20-b6be-449f-84c4-7bc817c5aa94
### END /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_uefi-firmware ###

==================== sda1: Location of files loaded by Grub ====================

           GiB - GB             File                                 Fragment(s)
   0,373051643 = 0,400561152    grub/grub.cfg                                  8
   0,367642403 = 0,394753024    grub/i386-pc/core.img                          3
   0,109494209 = 0,117568512    vmlinuz                                       12
   0,367707253 = 0,394822656    vmlinuz-5.4.0-29-generic                      11
   0,109494209 = 0,117568512    vmlinuz-5.4.0-31-generic                      12
   0,367707253 = 0,394822656    vmlinuz.old                                   11
   0,389271736 = 0,417977344    initrd.img                                    25
   0,223254204 = 0,239717376    initrd.img-5.4.0-29-generic                   26
   0,389271736 = 0,417977344    initrd.img-5.4.0-31-generic                   25
   0,223254204 = 0,239717376    initrd.img.old                                26


======================== Unknown MBRs/Boot Sectors/etc =========================

Unknown BootLoader on sda2

00000000  6e 00 67 00 65 00 6e 00  20 00 6e 00 69 00 63 00  |n.g.e.n. .n.i.c.|
00000010  68 00 74 00 2e 00 66 00  46 00 fc 00 72 00 20 00  |h.t...f.F...r. .|
00000020  64 00 69 00 65 00 73 00  65 00 73 00 20 00 5a 00  |d.i.e.s.e.s. .Z.|
00000030  65 00 69 00 6c 00 65 00  6e 00 73 00 65 00 74 00  |e.i.l.e.n.s.e.t.|
00000040  20 00 6b 00 f6 00 6e 00  6e 00 65 00 6e 00 20 00  | .k...n.n.e.n. .|
00000050  6b 00 65 00 69 00 6e 00  65 00 20 00 5a 00 65 00  |k.e.i.n.e. .Z.e.|
00000060  69 00 6c 00 65 00 6e 00  20 00 65 00 72 00 73 00  |i.l.e.n. .e.r.s.|
00000070  74 00 65 00 6c 00 6c 00  74 00 20 00 77 00 65 00  |t.e.l.l.t. .w.e.|
00000080  72 00 64 00 65 00 6e 00  2c 00 20 00 64 00 61 00  |r.d.e.n.,. .d.a.|
00000090  20 00 65 00 69 00 6e 00  65 00 20 00 64 00 65 00  | .e.i.n.e. .d.e.|
000000a0  72 00 20 00 41 00 63 00  68 00 73 00 65 00 6e 00  |r. .A.c.h.s.e.n.|
000000b0  20 00 6b 00 65 00 69 00  6e 00 65 00 20 00 50 00  | .k.e.i.n.e. .P.|
000000c0  6f 00 73 00 69 00 74 00  69 00 6f 00 6e 00 65 00  |o.s.i.t.i.o.n.e.|
000000d0  6e 00 20 00 65 00 6e 00  74 00 68 00 e4 00 6c 00  |n. .e.n.t.h...l.|
000000e0  74 00 2e 00 46 00 45 00  69 00 6e 00 20 00 50 00  |t...F.E.i.n. .P.|
000000f0  72 00 6f 00 76 00 69 00  64 00 65 00 72 00 20 00  |r.o.v.i.d.e.r. .|
00000100  69 00 73 00 74 00 20 00  6e 00 69 00 63 00 68 00  |i.s.t. .n.i.c.h.|
00000110  74 00 20 00 61 00 6e 00  67 00 65 00 67 00 65 00  |t. .a.n.g.e.g.e.|
00000120  62 00 65 00 6e 00 2c 00  20 00 75 00 6e 00 64 00  |b.e.n.,. .u.n.d.|
00000130  20 00 65 00 73 00 20 00  67 00 69 00 62 00 74 00  | .e.s. .g.i.b.t.|
00000140  20 00 6b 00 65 00 69 00  6e 00 65 00 6e 00 20 00  | .k.e.i.n.e.n. .|
00000150  53 00 74 00 61 00 6e 00  64 00 61 00 72 00 64 00  |S.t.a.n.d.a.r.d.|
00000160  70 00 72 00 6f 00 76 00  69 00 64 00 65 00 72 00  |p.r.o.v.i.d.e.r.|
00000170  2e 00 5f 00 44 00 69 00  65 00 20 00 61 00 6e 00  |.._.D.i.e. .a.n.|
00000180  67 00 65 00 67 00 65 00  62 00 65 00 6e 00 65 00  |g.e.g.e.b.e.n.e.|
00000190  20 00 56 00 65 00 72 00  62 00 69 00 6e 00 64 00  | .V.e.r.b.i.n.d.|
000001a0  75 00 6e 00 67 00 73 00  7a 00 65 00 69 00 63 00  |u.n.g.s.z.e.i.c.|
000001b0  68 00 65 00 6e 00 66 00  6f 00 6c 00 67 00 00 56  |h.e.n.f.o.l.g..V|
000001c0  19 3e 8e fe ff ff 02 00  00 00 00 e8 bf 1d 00 00  |.>..............|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200


=============================== StdErr Messages ================================

/usr/share/boot-sav/b-i-s-functions.sh: ligne 1653: 482451456S : valeur trop grande pour la base (le symbole erronÃ© est Â«Â 482451456SÂ Â»)

================================= User choice ==================================

Is there RAID on this computer? no

================================ LVM activation ================================

modprobe dm-mod  
vgscan --mknodes
  Found volume group "ubuntu-vg" using metadata type lvm2
vgchange -ay
  2 logical volume(s) in volume group "ubuntu-vg" now active
lvscan
  ACTIVE            '/dev/ubuntu-vg/root' [230.05 GiB] inherit
  ACTIVE            '/dev/ubuntu-vg/swap_1' [<7.90 GiB] inherit
blkid -g

Suggested repair: ______________________________________________________________

The default repair of the Boot-Repair utility would purge (in order to enable-lvm) and reinstall the grub2 of
mapper/ubuntu--vg-root into the MBR of sda.
Additional repair would be performed: unhide-bootmenu-10s

Je pense que geole est plus compétent que moi pour te conseiller.

Nasman

Actuellement le démarrage se fait ainsi :
- chargement du mbr en mémoire vive (1er secteur de LBA=0)
- exécution du code présent dans le mbr (en fait sa copie en mémoire vive)
- chargement de diskboot.img (1ère partie de core.img) qui est présent à la LBA=1 (donc juste après le mbr)
- chargement des 62 secteurs suivants (core.img) - contient l'emplacement de la partition où se trouve grub
- chargement du noyau présent dans /boot (partition dédiée ici)
- gestion de l'accès au LVM (mais je suis incompétent à ce niveau)

Le passage en uefi va shunter les premières étape (l'uefi recherche seulement les fichiers .efi dans la partition efi) mais la lecture de /boot devra toujours se faire.

Page suivante »