[UEFI] Intérêt par rapport au BIOS

[bebr]

Bonjour à tous,

Je sais, je déterre un topic vieux de 2 ans, c'est mal.
Mais c'est le mien

En fait, c'est surtout que j'ai fini par tout installer en UEFI + GPT.
La raison de cette "migration" : le changement de mon SSD système vers un nouveau SSD de plus grande capacité et plus performant. (ca bombarde bien d'ailleurs)

Voici donc ce que j'ai fait :

1. Installation de Windows 7 en UEFI sur SSD vierge, donc il a crée l'ESP, une partition réservée, et sa partition système
2. Installation d'Archlinux en UEFI bien sûr, sur le même disque, en utilisant l'ESP créé par Windows
3. Installation de Refind pour charger tout ça

Tout fonctionne très bien, mais c'est perfectible.
Déjà, j'avais complètement oublié les bons conseils qui se trouvaient dans ce topic, donc, voici mes soucis :

1. L'ESP est monté sur /boot et non sur /boot/efi, du coup, c'est un peu mélangé, je vais corriger ça rapidement. En fait, j'ai suivi le wiki en, donc j'ai monté l'ESP sur /boot et patatra !
2. A cause du point 1., Refind ne parvient pas à détecter le type de distribution, donc j'ai un joli manchot à la place d'u magnifique logo Arch, rien de bien grave, mais c'est à corriger aussi. Explication (source : http://www.rodsbooks.com/refind/configfile.html#icons):

   rEFInd attempts to guess the Linux distribution based on data in the /etc/os-release file. This file will only be accessible if a separate /boot partition is not used, though. Manually adjusting the os-release file to change an OS icon in rEFInd is not recommended.

3. La taille de l'ESP, crée par Windows, me semble un peu petite, 100Mo, c'est limite. Si demain j'ajoute un 3ème système, ce qui peut arriver, alors je risque d'être à court d'espace.

Vient donc une question : est-ce que je peux redimensionner l'ESP et donc, décaler toutes mes partitions sans trop de souci ?
Mes partitions sont comme suit :
/dev/sda1 ESP 100Mo
/dev/sda2 Réservé système windows (me souvient plus de la taille exacte)
/dev/sda3 Système Windows 250Go
/dev/sda4 / 100Go
/dev/sda5 /mnt/fast_storage 150Go

J'ai surtout "peur" pour cette partition "réservé système windows".

Autre chose, pas de souci de ne pas avoir une partition dédiée pour /boot ?
Car à terme, /boot devrait revenir sous /, seul /boot/efi sera indépendant pour l'ESP.

Merci d'avance !

[Xorg]

Hen c'est mal, tu as déterré un topic inactif de plus de 2 ans et tu as monté ton ESP dans /boot. Je réclame le châtiment maximal pour toi.

Je vais reprendre tes points.
1. Tu démontes ton ESP, là proprement tu crées le répertoire /boot/efi et tu montes ton ESP dedans. Si tu appelles la commande mkinitcpio, il va bouder, donc il serait bien que tu recopies tes noyaux (vmlinuz-linux) dans ton /boot.
2. C'est beau les manchots aussi.
3. Ça dépend, il te reste quel espace libre sur ton ESP , parce que pour agrandir cette partition, ça va être une vraie misère si tu veux réduire une de tes grosses partitions. Il vaut mieux réduire (voir supprimer) ta partition Réservé système windows, /dev/sda2, pour agrandir /dev/sda1. Cette partition contient les outils de dépannage de Windows quand il ne veut pas démarrer, les fameux outils qui ne fonctionnent pas si bien que ça d'ailleurs. Bref, tu peux la réduire, ça ne devrait pas poser de problèmes je pense.

Ça ne sera pas la peine un /boot séparé, vu que les fichiers de boot sont dans l'ESP, il y a même moyen de vider totalement le /boot (c'est pour dire).
Donc concentre-toi surtout sur le point 1.

[oktoberfest]

Salut,

je ne vais répondre que pour un point : "pas de souci de ne pas avoir une partition dédiée pour /boot ?"

Pour savoir si tu vas avoir des soucis ou pas, il faut déjà savoir pourquoi il peut être utile d'avoir un /boot. Après tout, il y a des millions de linux qui démarrent sans partition /boot et pourtant ils n'ont pas de souci

Dissocier /boot de / est nécessaire si ton bootloader ne sait pas lire ton /, dans les cas suivants (lite non exhaustive) :
- ton / est formaté en f2fs (je prends un file system un peu exotique, parce que ext3 est bien lu par syslinux et autre grub)
- ton / est sur un volume LVM
- ton / est chiffré (LUKS).

Dans ce cas tu n'as pas le choix : tu dois placer le noyau dans une partition que le bootloader sait lire, donc tu créés une partition distincte pour ton noyau, que tu montes sur /boot.

Dans les autres cas c'est juste soit une commodité (ex : tu as plusieurs os linux et tu places tous les noyaux dans la même partition) soit un copier/coller d'un tutoriel sans se poser de questions

Dans le cas de l'UEFI ton noyau est stocké dans ta partition ESP, tu peux donc en déduire qu'un /boot distinct est inutile. Par contre il te faut un mécanisme pour recopier ton noyau (+ initramfs) dans ta partition ESP à chaque mise à jour (cf wiki).

[bebr]

Yes !
J'étais sûr que j'allais vous retrouver tous les 2 !!

Ok, donc, ça confirme ce que je pensais pour le point 1.
Du coup, si je fais ça bien, le point 2. sera résolu dans la foulée.
Pour le point 3., il faut effectivement voir l'espace disponible sur l'ESP, je vérifie ça ce soir

Et ok pour boot, à vrai dire, je ne sais même pas pourquoi j'ai posé la question, je sais que c'est toujours optionnel de séparer le système en différentes partitions.
Mais j'avoue que cette histoire de montage de l'ESP dans /boot/efi m'a mis un gros doute, vu que ce n'est pas courant (pour l'instant !)

Vu que je n'entre pas dans les particuliers que tu as donné oktoberfest, je peux remettre tout ça dans /, bien plus simple.
Je vous tiens au courant pour la suite, je fermerai définitivement ce topic.
Le fameux 'résolu' va finir par arriver

Merci !

[otacon]

Je voudrais pas mettre ma zone, mais mon install UEFI monte l'ESP dans /boot.
Obligé si on veut utiliser par exemple systemd-boot (qui en passant démarre un peu plus vite que les copains).
Exit les grubs, refind ou autre.

J'avais juste avant un montage de l'ESP dans /boot/efi avec grub (permet d'avoir les noyaux dans la partition racine et d'avoir juste arch_grub/grubx64.efi dans la partion ESP partagée avec les dossiers windows).

Je viens de migrer à systemd-boot, ça marche au poil.
inutile mais sait on jamais : le topic de migration -> viewtopic.php?f=1&t=17045

[Xorg]

Je voudrais pas mettre ma zone, mais mon install UEFI monte l'ESP dans /boot.
Obligé si on veut utiliser par exemple systemd-boot (qui en passant démarre un peu plus vite que les copains).

Ça, c'est toi qui l'a fait comme ça... Si ton monte l'ESP dans /boot/efi, ça marche aussi... C'est juste qu'il faut que les noyaux et les initramfs soient copiés dans l'ESP après chaque mise à jour pour que ça fonctionne correctement (il y a toutes les explications nécessaires sur le wiki sur comment automatiser tout ça).

Je prends un exemple tout bête pour montrer pourquoi cette méthode est à éviter (monter l'ESP directement dans /boot). On installe une première Arch, qui viendra mettre son noyau et ses initramfs à la racine de l'ESP. On installe une seconde Arch, qui va faire de même. La deuxième aura donc écrasé les fichiers de la première.
C'est pour ça qu'on trouve, en principe, dans l'ESP, un répertoire nommé EFI, qui contient un sous-répertoire par système, ce qui évite ce genre de conflits.

[otacon]

J'entends bien tout ce que tu exprimes.
copier des noyaux à chaque mise à jour n'a aucun sens, pour moi. C'est tout sauf kiss.
Jusque recemment si tu m'as lu, j'étais configuré pareil, $esp dans /boot/efi, commande d'install grub en uefi et ça roule. pas de probleme.
Mais le bootloader étant maintenant intégré à systemd, j'ai résisté un peu avec mon grub puis j'ai migré. Exit les paquets bootloaders. La prochaine étape consiste à booter efistub directement depuis le bios avec efibootmgr (la NVRAM du thinkpad le permet). Dans ces deux cas (systemd-boot et efibootmgr), le noyau doit être dans l'$esp.

Cette machine a en dur windows et arch. Toutes les autres distribs de test passent en VM qmu/kvm. Le problême que tu soulèves n'existe pas pour moi.

On trouvera toujours un exemple ou un cas ou les dispositions retenues posent un problême. Une question de choix éclairé, comme toujours !

[Xorg]

C'est vrai, ce n'est pas KISS d'avoir à copier les fichiers comme tu le dis. Et c'est vrai que ça marche de monter l'ESP dans /boot, donc c'est un peu se compliquer la tâche pour pas grand chose d'utiliser /boot/efi.
Il est relativement simple de changer l'emplacement par défaut des initramfs (il faut modifier le fichier /etc/mkinitcpio.d/linux.preset), mais pour le noyau c'est un peu moins évident. Actuellement, j'utilise des unités spéciales avec Systemd pour déplacer les noyaux (les fichiers .path), mais j'admets que je rencontre un problème avec cette méthode (est-ce que je suis le seul, je l'ignore), car après une mise à jour du noyau, ma machine n'arrive pas à charger le nouveau noyau alors qu'il est bien là il ou doit être, avec le bon nom et les bonnes permissions. Donc il faut utiliser une autre méthode pour déplacer le noyau.

Vu que ton noyau est déjà dans l'ESP, tu as juste besoin de faire une commande avec efibootmgr pour ajouter une entrée de boot de ton UEFI, qui chargera directement le noyau au boot (sans passer par de bootloader). Tu as déjà fait le plus gros du travail en voulant utiliser systemd-boot.

[bebr]

Salut à tous,

@otacon : effectivement, rien n'est imposé, j'avais bien la même configuration que ta précédente, à savoir l'ESP monté sur /boot et ça fonctionnait très bien. Mais si tu relis mon post, tu verras que j'avais un petit problème cosmétique avec refind. Et moi, j'aime bien quand c'est beau !

Blague à part, pour moi Refind a surtout l'avantage de détecter automatiquement les applications EFI et autres systèmes. Plus besoin de passer par le menu de la carte mère pour choisir sur quoi booter, tu branches une clé USB, un nouveau disque ou autre, et tu as tout de suite une entrée dans Refind.
Et tu peux même brancher ta clé sur l'écran de Refind, faire un refresh (Esc de mémoire), et hop nouvelle entrée !
Ca c'est KISS !

De plus, comme l'a dit Xorg, séparer l'ESP de /boot te permet d'avoir plusieurs noyaux facilement (surtout s'ils ont le même nom). Qui plus est, l'ESP reste donc dédié au bootloaders et autres appli EFI et /boot reste dédié au système dont il fait partie. Pas de mélange, c'est plus propre et c'est dans la logique de ce que doit être un ESP : une partition système, multi-plateforme, dédiée uniquement aux bootloaders et applications EFI.

Monter l'ESP dans /boot est en fait une limitation de gummiboot, aka systemd-boot, qui nécessite d'avoir les noyau et initramfs sur la partition ESP, car il ne peut pas charger d'applications depuis un autre type de partition. Donc c'est plus simple de tout laisser à cet emplacement. Mais comme dit plus haut rien n'empêche de monter l'ESP /boot/efi et déplacer/copier les noyau et initramfs vers cette partition.

Et puis créer 2 fichiers de 4 lignes pour automatiser la copie, on ne peut pas dire que ce soit compliqué non ?

Dernier point, utiliser le menu de la carte mère n'est envisageable que si ta carte mère le permet.
Le point dur reste le passage de paramètre au noyau (le microcode intel au hasard...), facile avec un bootloader dédié et tout automatisé, alors qu'avec une entrée créée avec efibootmgr et EFI Stub, il va falloir la recréer si on change les paramètres. Là, pour le coup, c'est fastidieux.

Et oui, je me suis quand même bien renseigné sur le sujet

Bref, de mon côté, j'ai refait le montage de EFI selon mon envie, donc dans /boot/efi.
Tout est nickel, ça boote sans souci, le point 1 est donc résolu et a corrigé le point 2.
Pour ce qui est de l'espace disponible sur mon ESP, je suis à 50% des 100Mo. Et je n'ai que 2 systèmes pour le moment, pas d'application EFI autre que refind et celle de Windows, je verrai donc à l'usage.

Merci encore pour vos réactions et rapides conseils.
Vu que je suis en pleine réinstallation, il y a des chances pour que je revienne par là.
Donc à bientôt

[Xorg]

C'est vrai que pour modifier les paramètres du noyau en EFISTUB, ça implique de recréer l'entrée (mais l'ancienne disparaît toute seule).
Ce n'est pas si dur que ça les paramètres du noyau. Un exemple pour le microcode est ici. À titre personnel, je stocke ces commandes dans un script, ce qui me facilite la tâche quand je veux ajouter ou modifier des options.

[bebr]

De toute façon, les scripts, c'est la vie
Ce serait impensable de ne pas avoir quelques scripts sous la main quand on utilise Linux depuis quelques temps.
C'est une des raisons pour lesquels j'adore Linux, tellement plus simple, transparent et versatile.

Merci pour le tuyau en tout cas
Comme quoi, il y a des solutions à tout !