Archlinux.fr [Forums]

Bonjour à tous,

Voilà, je me renseigne depuis quelques temps sur le sujet.
J'ai trouvé des infos, mais pour moi, ce n'est pas assez complet, j'ai encore des doutes.

Je sais que l'on peut installer des applications réseau et autres, exécutables depuis l'UEFI, qu'on peut gérer des partitions >2.2Go grâce au partitionnement GPT, que ça peut pratique pour faire de la maintenance etc.
Mais s'il faut toujours un bootloader comme grub pour démarrer Arch, à quoi ça sert tout ça ?

J'ai lu un article qui disait que c'est plus performant, légende urbaine ?

Je dois aussi garder un Windows 7, et oui, je joue encore, donc est-ce que Windows 7 installé en UEFI nécessite sa propre partition UEFI dédiée ou est-ce qu'une seule partition pour l'UEFI peut être commune à plusieurs système ?
D'expérience je sais que Windows, installé hors UEFI écrase grub (MBR), en est-il de même lorsqu'on installe en UEFI ? Si oui, quel est l'ordre préconisé ?

Après, je n'en ai pas un besoin crucial, c'est surtout par curiosité, donc si c'est trop contraignant, je resterai avec notre bon vieux MBR/bios.

Merci !

Salut

l'interêt de l'UEFI est sutout la gestion du multi boot d'une simplicité enfantine. Mais Windows parvient à s'en servir et à fonctionner!.
Pour la partition UEFI ( ESP : EFI System Partition), c'est comme tu veux, une seule, une pour chaque os, ...
Windows crée 1 partition ESP de taille très réduite, et j'aurais tendance à laisser le propriétaire de coté ( On mélange pas le torchon sale avec arch propre ! ).
Il n'y a aucune obligation à utiliser grub, car c'est l'UEFI qui joue le rôle de bootloader.
Perso, j'ai 2 arch qui partage la même partition ESP, et Fedora 18 qui a sa propre partion ESP. Le tout avec le gestionnaire de boot rEFInd.
Si UEFI, il n'y a plus de notion de MBR ( associé au mode BIOS ou BIOS-legacy ).
A+

c'est un peu maigre comme avantage vu qu'on pouvait faire la même chose avec un gestionnaire de multiboot,

surtout que l'utilisateur lambda n'utilise en général qu'un seul système d'exploitation et que la partition système où sera installé l'OS n'a pas besoin d'être grosse ( 50 Go suffit largement ), du coup le bon vieux MBR peut suffire

sur wikipédia j'ai trouvé ça sur UEFI :

UEFI can support remote diagnostics and repair of computers, even without another operating system.

moi ce serait ça qui m’intéresserait, des utilitaires systèmes integrés dans une puce mémoire ( que l'utilisateur pourrait personnaliser ),

mais bon les clés USB bootable pouvaient déjà contenir ce genre d'application

GRUB permet déjà de gérer le multiboot en toute simplicité.

J'ai déjà installé des Arch en UEFI avec GRUB, à moins d'avoir des partitions > 2,2 To, une fois installé c'était la même chose à l'utilisation. Donc c'est assez transparent quand on utilise GRUB. Pour le multiboot je ne sais pas comment ça fonctionne, j'ai abandonné comme un lâche.

de toutes façons avec la puissance actuelle des PC on peut se passer de multiboot et utiliser à la place des machines virtuelles avec par exemple virtualbox si on veut tester des OS

Merci pour vos réponses.

Donc visiblement les avis sont partagés.
Justement l'intérêt pour moi serait de me passer de grub, et donc d'utiliser l'EFI à la place (avec un gestionnaire comme refind par exemple).
Ca me paraît plus moderne mais bon, c'est surtout pour expérimenter.
Et aussi la possibilité de faire de la maintenance plus facilement. Parce que le boot sur clé usb, ça fonctionne mais c'est pas très pratique.

Je crois que je vais tenter l'aventure en tout cas, je suis trop curieux.

@Elbarto : ca dépend vraiment de ton utilisation, perso j'ai besoin de toutes les ressources de ma machine sous tous mes OS, donc exit la virtualisation. Après oui, si c'est juste pour découvrir une nouvelle distrib, en effet, c'est moins contraignant.

Multiboot et VM ne répondent pas au même besoin. Avec une VM tu as un matériel émulé, donc si tu veux profiter de ta carte graphique sous deux OS, il te faut du multiboot.
Le côté performance pour moi c'est de la légende urbaine : ton noyau (et donc ton OS) n'ira pas plus vite parce que c'est UEFI/GPT qui l'a chargé en mémoire

Tout à fait oktoberfest, j'ai besoin de ma CG sous Windows pour jouer et sous Linux j'ai aussi besoin de ma carte graphique pour modéliser et d'autres ressources pour faire de la musique (enregistrement live, vst etc.)
Et merci pour ta réponse, moi non plus je ne voyais pas trop en quoi un système peut être plus performant en changeant de méthode de boot ...
C'est peut être juste le boot qui est un poil plus rapide ?
De toute façon, avec ma machine, j'ai pas vraiment besoin de plus : Core i7 2600k, 8Go ram, GTX560Ti et surtout SSD, mon archlinux boot en 5 secondes.

Merci en tout cas pour ces réponses.
Si d'autres ont des retours d'expérience ça m'intéresse.
Je ferai probablement un retour après avoir testé tout ça.

oktoberfest a écrit :Multiboot et VM ne répondent pas au même besoin. Avec une VM tu as un matériel émulé, donc si tu veux profiter de ta carte graphique sous deux OS, il te faut du multiboot.

il existe aussi un type de virtualisation où l'OS et les pilotes ont été conçus pour accéder directement au matériel malgré la virtualisation ( je n'ai plus le nom en tête de cette technologie ), ce qui permet en théorie de résoudre cette critique concernant le manque de performance/accès au matériel

edit: Xen, paravirtualisation

Tu penses à Xen non ?
J'ai déjà fait des tests, pour certains besoins c'est vraiment bien.
Pour mes besoins en revanche, ce n'est pas suffisant, Windows n'est pas officiellement supporté et il y a des problèmes de stabilité quand tu sollicites trop de ressources matérielles.
Mais je pense que c'est le meilleur compromis.

Petit retour, j'ai essayé de refaire une installation complète en UEFI/GPT.
Ca a été un échec.
Premier constat, même en ayant créé de nouvelles partitions avec cgdisk, au premier reboot, j'avais un prompt "Grub".
Curieux, car il me semblait que le MBR aurait disparu.
Cela dit, cgdisk m'a obligé a créé la première partition à partir du bloc 34. Est-ce que cela correspondrait au MBR ?
Faut-il donc explicitement supprimé le MBR avant d'utiliser cgdisk ?

Deuxième chose, je voulais tester un ETI Stub + rEFInd, mais impossible de créer une entrée.
A priori c'est un bug connu, j'ai donc du le créer manuellement depuis l'EFI Shell, mais en choisissant l'option fraîchement créée, j'ai obtenu un beau freeze complet de ma machine.
C'est peut être dû à ces fameux bloc en début de disque ou simplement la table de partition et les blocs réservé pour GPT ...

Quoiqu'il en soit, j'ai trouvé ça très complexe à mettre en place. Donc, je me suis résigné, un petit coup de dd et j'ai retrouvé mon système tel qu'il était avant.

Si vous avez des infos à me donner je suis preneur, je n'aime pas trop rester sur un échec.
Mais par faute de temps, j'ai du laisser tomber, pour le moment ...

bebr a écrit :au premier reboot, j'avais un prompt "Grub".
Curieux, car il me semblait que le MBR aurait disparu.

Je ne vois pas bien le rapport. Si grub est lancé et qu'il a un souci quelconque, il affiche la ligne de commande.
S'il n'y a pas d'erreur, c'est souvent qu'il ne trouve pas de fichier de configuration.

Oui je suis bien d'accord (EDIT: avec le fait que le prompt grub ne s'affiche qu'en cas de problème)
Je reste persuadé d'avoir bien écrit la nouvelle table de partition GPT, donc suppression totale du disque, suppression de toutes les partitions existantes etc.
Alors comment le petit grub se trouve encore là ?

EDIT: je précise que je n'ai pas réinstallé grub, donc pas de grub-efi, d'où mon interrogation.

bebr a écrit :Je sais que l'on peut installer des applications réseau et autres, exécutables depuis l'UEFI, qu'on peut gérer des partitions >2.2Go grâce au partitionnement GPT,

Avec un BIOS, rien ne t'interdit d'utiliser une table de partitionnement GPT pour outre-passe cette limite de 2Tio. L'UEFI est juste capable de booter dessus, contrairement au BIOS.

bebr a écrit :Mais s'il faut toujours un bootloader comme grub pour démarrer Arch, à quoi ça sert tout ça ?

J'ignore où tu as lu qu'il faut toujours utiliser un bootloader. N'ayant pas vu le terme que je cherchais (oui, j'ai eu la flemme de lire tous les messages mais j'ai utilisé la fonction recherche), je dis clairement que non, tu peux bien entendu booter sans bootloader, un des gros avantages des UEFI (et j'en suis la preuve vivante).
Mais rien ne t'interdit d'avoir GRUB en "secours". Je te redirige vers le wiki : EFI_Boot_Stub.

bebr a écrit :J'ai lu un article qui disait que c'est plus performant, légende urbaine ?

Oui et non. Je connais aussi bien les BIOS que les UEFI, et franchement, l'UEFI reste quand même plus moderne, mais après ça n'est qu'une étape pre-boot, autant dire que ça monopolise 10 secondes de ton temps dans une journée dans les deux cas, donc c'est négligeable.
Le seul truc avec les BIOS comme les UEFI, c'est de désactiver ce dont tu ne te sers pas dans leur setup. Par exemple, un contrôleur SATA tiers, si tu ne l'utilise pas, tu gagneras deux secondes de boot car le BIOS/UEFI ne va pas s'embêter à l'initialiser vu que tu l'as désactivé.

bebr a écrit :Je dois aussi garder un Windows 7, et oui, je joue encore, donc est-ce que Windows 7 installé en UEFI nécessite sa propre partition UEFI dédiée ou est-ce qu'une seule partition pour l'UEFI peut être commune à plusieurs système ?

Ouh, on a peur de faire le grand saut. Enfin j'étais comme toi avant tu me diras, avant de plaquer définitivement Windows pour Wine.

Je pense qu'on t'a déjà répondu à cette question, mais une partition EFI est constituée telle quelle (voici le schéma pour mon cas par exemple) :

Code : Tout sélectionner

.
├── EFI
│   └── arch
│       ├── grubx64.efi
│       ├── initramfs-arch-ck.img
│       ├── initramfs-arch-fallback.img
│       ├── initramfs-arch.img
│       ├── vmlinuz-arch-ck.efi
│       └── vmlinuz-arch.efi
└── shellx64.efi

Mais, admettons que tu aies Windows installé en EFI, ça devrait donné ceci :

Code : Tout sélectionner

.
├── EFI
│   ├── arch
│   |    ├── grubx64.efi
│   |    ├── initramfs-arch.img
│   |    └── vmlinuz-arch.efi
|   └── microsoft
|        ├── fichier.efi
|        └── dossiers, etc...
└── shellx64.efi

Un dossier par OS donc si tout va bien. Tu risques de te demander, autant te réponse maintenant : le shellx64.efi n'est pas indispensable ; c'est un shell que les UEFI 64 bits cherchent pour booter dessus, et il faut forcément qu'il porte ce nom. Il me semble que chez moi, ce n'est qu'une copie de grubx64.efi renommée.

En espérant avoir répondu à tes attentes.

Merci Xorg !

C'est beaucoup plus clair maintenant, surtout pour l'arborescence de la partition EFI.
Je vais sûrement retenté tout ça alors

Xorg a écrit :J'ignore où tu as lu qu'il faut toujours utiliser un bootloader. N'ayant pas vu le terme que je cherchais (oui, j'ai eu la flemme de lire tous les messages mais j'ai utilisé la fonction recherche), je dis clairement que non, tu peux bien entendu booter sans bootloader, un des gros avantages des UEFI (et j'en suis la preuve vivante).
Mais rien ne t'interdit d'avoir GRUB en "secours". Je te redirige vers le wiki : EFI_Boot_Stub.

C'est ce que j'avais compris, ou plutôt mal compris, au début.
Mais oui, après avoir tenté l'expérience, je me suis vite rendu compte qu'on peut se passer de grub ou autre.

Pour mon histoire de grub toujours présent après écrasement total de mon SSD, tu as une idée ?

Si tu veux, je peux être plus clair que ça (ou t'embrouiller

) : cette fameuse partition EFI dont j'ai montré l'arborescence se monte dans un point de montage peu commun, qui est /boot/efi (enfin, je crois que c'est écrit dans le Wiki).

Code : Tout sélectionner

/boot
├── efi
│   └── EFI
│       └── arch
├── grub
│   ├── fonts
│   ├── locale
│   ├── themes
│   │   ├── Archlinux
│   │   │   └── icons
│   │   └── starfield
│   └── x86_64-efi
├── lost+found [error opening dir]
└── memtest86+

Ce n'est pas tout le SSD qu'il faut écraser, mais juste une partie du MBR (le MBR fait 512 octets, mais les derniers octets servent à la table de partitions, donc si on y touche...) :

Code : Tout sélectionner

dd if=/dev/null of=/dev/sdX bs=446 count=1

Avec cette commande, ça effacera les 446 premiers octets. Et si ça ne marche pas, vérifie que ça ne soit pas, par exemple, un HDD dont tu avais oublié de supprimer le bootloader.

Le seul "problème" du boot stub, c'est que tu ne peux avoir qu'un paramètre par noyau, et non par initrd. Donc en gros, le jour où tu voudras utiliser le mode fallback, ça sera compliqué.

bebr a écrit :Pour mon histoire de grub toujours présent après écrasement total de mon SSD, tu as une idée ?

Supprimer toutes les partitions de ton disque ne modifie que la table des partitions, donc une toute petite partie du MBR. Si tu veux supprimer toute trace de grub, il te faut mettre à 0 les 446 premiers octets du MBR :

Code : Tout sélectionner

dd if=/dev/zero of=/dev/sda bs=1 count=446

/dev/sda est à adapter bien sur...

cf https://wiki.archlinux.org/index.php/Ma ... estoration

EDIT : Grillé....

Voilà !
C'est bien ce qu'il me semblait, mais je n'en étais pas sûr.
Je pense d'ailleurs que ce serait une information à ajouter au wiki pour ceux qui veulent migrer de BIOS/MBR à UEFI/GPT.
Ca a toujours été assez obscure pour moi les tables de partitions, le MBR etc, maintenant, j'y vois bien plus clair.
Merci à tous !!

@Xorg: très honnêtement, ouais, tu m'embrouilles

Mais je crois quand même comprendre.
Dans tous les cas, je crois que les wiki en ou fr ne sont pas assez explicite pour les néophytes comme moi.
Des exemples avec les points de montage et une arborescence bien décrite amélioreraient grandement la compréhension.
Car perso, j'avais rien compris à comment et où écrire les fichiers pour l'EFI.

Donc, voilà ce que j'ai compris, dites moi si c'est bon:
J'ai un partionnement très classique :

Code : Tout sélectionner

/dev/sda1 /
/dev/sdc1 swap
/dev/sdc2 /home

Avec l'EFI en plus j'ajoute (en ayant modifié/décalé /):

Code : Tout sélectionner

/dev/sda1 /boot/efi
/dev/sda2 /
/dev/sdc1 swap
/dev/sdc2 /home

Et donc, ma partition EFI (sda1) contiendrai un truc du genre :

Code : Tout sélectionner

.
├── EFI
│   └── arch
│       ├── grubx64.efi
│       ├── initramfs-arch-ck.img
│       ├── initramfs-arch-fallback.img
│       ├── initramfs-arch.img
│       ├── vmlinuz-arch-ck.efi
│       └── vmlinuz-arch.efi
└── shellx64.efi

A adapter si je veux utiliser rEFInd.

J'ai bon ?

bebr a écrit :
Code : Tout sélectionner
/dev/sda1 /boot/efi
/dev/sda2 /
/dev/sdc1 swap
/dev/sdc2 /home

Oui, c'est ça.

bebr a écrit :Et donc, ma partition EFI (sda1) contiendrai un truc du genre :

Code : Tout sélectionner

.
├── EFI
│   └── arch
│       ├── grubx64.efi
│       ├── initramfs-arch-ck.img
│       ├── initramfs-arch-fallback.img
│       ├── initramfs-arch.img
│       ├── vmlinuz-arch-ck.efi
│       └── vmlinuz-arch.efi
└── shellx64.efi

À peu près. Je pense que ça sera ça chez toi, dans le cas d'une configuration "par défaut" et sans GRUB :

Code : Tout sélectionner

.
└── EFI
    └── arch
        ├── initramfs-arch-fallback.img
        ├── initramfs-arch.img
        └── vmlinuz-arch.efi

bebr a écrit :A adapter si je veux utiliser rEFInd.

Je ne connais pas rEFInd, mais il me semble que le Wiki est suffisant à son sujet. Elle est disponible ici. Bien entendu, tu n'oublieras pas de monter la partition EFI dans le /boot/efi...

Au pire, si tu as peur d'oublier un jour, le /etc/fstab reste ton ami.
J'ai lu vite fait et j'ai vu qu'il y a un modprobe efivars ; il n'est pas nécessaire car le module efivars est compilé en dur maintenant dans le noyau.

Bonne chance à toi.

Merci beaucoup pour détails.
Ca me fait une bonne base pour tout reprendre et peut être réussir

Je vais certainement ouvrir une discussion sur les wiki pour améliorer tout ça.
C'est assez nouveau l'UEFI, je pense que ça ne fera pas de mal s'il y a plusieurs exemples types (multiboot, avec ou sans grub etc.)
En attendant je vais essuyer les platres, et profiter quand même un peu du soleil !

Merci à tous !

Archlinux.fr [Forums]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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