[Installation] Système introuvable UEFI/GPT/EFISTUB(Résolu)

[izakiel]

Bonjour à tous,

J'ai eu envi de sauter le pas et de passer sur Arch, en sachant bien que j'allais vivre une sacré aventure car c'est toujours compliqué la première installation
J'ai des difficultés à gérer le boot d'Arch sans vraiment savoir pourquoi malgrès mes longues recherches sur le wiki qui est très fourni en Français et en Anglais.
Quoi que je fasse après le redemarrage de la machine je fini sur un écran noir avec "Operating System Not Found"
Ce que je cherche à aboutir est l'installation d'Arch seul, sur une partition GPT, via UEFI et sans bootloader.
Je recherche donc l'aide de la communauté pour me dire ou j'ai fauté.

Je vais me permettre de donner un maximum d'informations sur les étapes que j'ai suivi
Je m'excuse pour la qualité médiocre des photos, je n'ai rien d'un artiste

- L'installation est éfféctuée sur un Sony Vaio S13 avec un firmware Insyde H2O Efi
- Le secure boot est désactivé dans le bios

- L'UEFI est activé

- Demarrage depuis une clé usb dont le label sera /dev/sdb
- Configuration du mapping clavier fr, de l'heure, ainsi que du réseau via iw+wpa_supplicant
- L'installation est faite sur un SSD avec pour label /dev/sda
- La table de partition est au format GPT
- Le disque est formaté via fdisk en 4 partitions


Rien de bien folichon, une ESP(fat32), une Swap, une Root(ext4) et une Home(ext4)

- Mon fstab

Encore une fois rien de fou, un mount bind de /esp/EFI/arch vers /boot
- Les fichiers sont bien présents, j'install le package intel-ucode via pacman
- Ensuite via efibootmgr j'ajoute une entrée via :

Code : Tout sélectionner

efibootmgr -d /dev/sda -p 1 -c -L "Arch Linux" -l /EFI/arch/vmlinuz-linux -u "root=/dev/sda3 rootfstype=ext4 initrd=/EFI/arch/intel-ucode.img initrd=/EFI/arch/initramfs-linux.img rw add_efi_memmap"

-Je check avec

Code : Tout sélectionner

efibootmgr -v

que mon entré à bien été ajoutée et c'est le cas avec un BootOrder à "0001".
-Je quitte le chroot, je reboot, et black screen "Operating System Not Found".

Après reboot sur la clé d'installation d'Arch, mon entrée dans efibootmanager n'existe plus et les labels des disques switches, la clé usb qui était en /dev/sdb passe en /dev/sda et donc inversement le SSD passe de /dev/sda à /dev/sdb.
Peut-être le fait de passer par des labels plutôt que des UUID pour les configurations qui pourrais expliquer le problème si les labels changent après reboot ?

J'ai rententé le processus d'installation plusieurs fois de zéro et j'arrive systèmatiquement au même résultat en passant par le guide FR ou US.
J'oublis forcément quelquechose mais ne vois pas quoi, à moins que l'UEFI de mon laptop soit buggué (car le guide en parle rapidement).

Toute aide est la bienvenue.

Merci d'avance à la communauté

[izakiel]

Bon il semblerait que mon intuition sur l'implémentation EFI était la bonne, à savoir le BIOS Insyde H2O Efi, cette immondice pose des problèmes à bien des ditributions et bien des bootloaders...
Slackware, Mint, les bootloaders comme Elilo et Grub2 et j'en passe.
Ce bios réinitialiserai les entrées EFI après reboot et ne va lire qu'une seule entrée dans \EFI\boot\bootx64.efi pour windows selon les bribes d'infos que j'ai pu recueillir à droite et à gauche sur les forum d'autres distributions.
Il y aurait moyen de bricoler avec reFind pour le faire passer mais bon si il faut bricoler déjà pour le chargement de l'OS ça respire pas le propre :/
source : http://www.linuxquestions.org/questions ... 175481293/

Encore des heures de perdus à cause d'une marque qui ne sait pas respecter un simple standard.

Peut-être une âme charitable pour confirmer ou non ces informations ?

[benjarobin]

Bonjour, ne cherche pas trop, une grosse partie des firmware UEFI ne permettent​ pas d'entrée une entrée personnalisée. Mais il y a un détail qui me fait dire que ce n'est peut être pas intégralement le cas. Essaye de renommer le kernel pour avoir une extension en .efi et adapte la commande efibootmgr

[izakiel]

Merci pour l'info, j'ai éssayé de renommer le kernel dans /esp/EFI/arch ainsi que l'entrée avec efibootmgr et malheureusement ça na pas changé la donne, j'ai également testé d'installer Manjaro et Linux Mint en UEFI et j'ai exactement le même symptome.
Je me suis fait une raison l'UEFI de cette bécane est comme le frère siamois de Windows 8 et plus, l'un ne va pas sans l'autre.

J'ai tenté une install de Manjaro en Legacy + MBR et c'est passé comme une lettre à la poste, ducoup ça veut dire que je peux me rabattre sur du Legacy Bios + MBR pour installer Arch, je n'ai pas de disque > 2To sur mon laptop et je n'y verrais donc que du feu.

Je vais tag le post comme résolu bien qu'il soit plutôt insoluble dans le fond ^^'

Je te dit merci pour l'aide apportée en tout cas, et si tu as d'autres idées je suis prêt à tester car ça peut rester un challenge interessant.

[benjarobin]

Euh, tu peux très bien installer le tout en UEFI via Grub, la manipulation est très simple, il te suffira après avoir installé Grub (en UEFI) de recopier le fichier efi de grub dans \EFI\boot\bootx64.efi
Ce qui permet ensuite de gérer proprement un multiboot UEFI, car en effet le fichier .efi de Windows est aussi une recopie, donc le vrai n'est pas à cet emplacement (\EFI\boot\bootx64.efi)

Si tu comptes faire du multiboot, je te recommande vivement d'utiliser un Grub UEFI installé intégralement dans la partition ESP (Voir Wiki anglophone pour cela), tu auras bien moins de problème qu'avec un boot legacy/MBR. Avec cette méthode tu ne perdra jamais ton multiboot

[izakiel]

Oui en effet tu as raison je suis allé vite en besogne en disant qu'il n'y a pas de moyen d'utiliser l'UEFI, il y en a en passant par un bootloader et un utilisant le workaround que tu proposes, à savoir le recopier en tant que bootx64.efi pour avoir un EFI shell. Mais sans bootloader en passant juste par l'EFISTUB c'est juste impossible avec l'implémentation InsydeH2o.

Seulement je ne compte pas du tout faire de multiboot, il s'agit d'une machine de travail avec un seul OS (Arch) et je trouve un peu dommage de devoir ajouter un bootlader tel que Grub ou rEFInd pour gérer un unique OS (enfin avoir un shell EFI déja) tout en utilisant un "hack"(renommer le fichier efi du bootloader pour celui de win) pour permettre le boot.
l'EFISTUB est tout de même un des avantages de l'EFI quand ce dernier est implémenté proprement ^^.

Je ne pense pas prendre de gros risque en passant par du Legacy/MBR à partir du moment ou je sais que je resterai en singleboot et je reste propre sans utiliser de solution de contournement par contre je suis moins souple je te l'accorde complétement.

[benjarobin]

\EFI\boot\bootx64.efi n'est pas le nom du fichier de Windows, celui de Windows se nomme /EFI/Microsoft/Boot/bootmgfw.efi
Sauf que Windows sait que certaines carte mère sont toutes bugués et donc il recopie /EFI/Microsoft/Boot/bootmgfw.efi dans \EFI\boot\bootx64.efi, en bref Windows fait le même bricolage que ce que je te propose
bootx64.efi est le nom du fichier que la norme UEFI impose pour une clé USB UEFI par exemple.

[izakiel]

Hoooo merci je n'avais vraiment pas compris cela et pensais à tort que ce fichier était celui de windows, donc au final on peut dire que le workaround est un standard des cartes mères avec un gestionnaire UEFI pourraves.

Bon je vais me coucher moins bête ce soir

[izakiel]

Je souhaitais simplement signaler que le workaround foncionne très bien.

Avec une partition GPT en Boot UEFI, et en recopiant /boot/efi/EFI/grub/grubx64.efi dans /boot/efi/EFI/boot/bootx64.efi ça démarre bien.

Dommage pour l'EFISTUB mais la souplesse est présente pour un eventuel multiboot.

Merci benjarobin pour ton intervention