Reprise du message précédent :
Merci de ta réponse, je vais réfléchir car je ne suis pas super chaud d'installer un dual boot sur cette machine qui est ma plus "sensible", avec un Bios classique ça n'aurait pas posé trop de problème, mais l'UEFI j'y comprends rien donc j'ai pas envie de faire de connerie.

Ca me parait faisable et je crois que c'est qui est souvent recommandé.

C’est ce que j’ai fait en février 2017 sur le PC familial (bien que celui-ci n’ait qu’un BIOS, et pas un UEFI), après lui avoir ajouté un nouveau disque dur pour ça. Au passage, avec du SATA, il n’y a plus de notion de disque principal ou secondaire en soi : côté carte-mère, ils sont tous vus à égalité (c’est dans le BIOS/l’UEFI que tu décides sur lequel démarrer en premier).
 
C’est ainsi que j’ai fait : après avoir branché le nouveau disque, j’ai démarré sur un Live-DVD, puis j’ai tout mis sur le nouveau disque (/dev/sdb, donc), y compris Grub (assorti d’os-prober pour détecter les autres OS présents), en veillant bien à ne jamais toucher au disque Windows (qui était donc /dev/sda). Comme ça, je me retrouve avec un PC qui bascule d’emblée sur Grub, lequel me permet de démarrer aussi bien Arch que Windows. Et si, un jour, je décide de retirer le disque ou de remettre le disque Windows comme principal dans le BIOS, Windows démarrera sans s’être jamais rendu compte de quoi que ce soit, de son côté.
 
C’est donc clairement la solution la plus sûre, de réserver un disque par OS.
 
Note importante /!\ : fais cependant gaffe aux histoires de gestions de l’horloge interne : n’oublie pas que, par défaut, Windows la gère en mode « heure locale », et Linux en mode « heure UTC ». Tu auras donc un décalage d’une heure (en heure d’hiver) ou deux (en heure d’été, comme actuellement et jusqu’au 25 à 3h) quand tu passeras de l’un à l’autre des OS.
 
Pour corriger ça, soit tu demandes à Windows de gérer l’horloge en UTC an ajoutant cette clef au Registre (enregistre ce texte dans un fichier *.reg) :
 

Soit tu demandes à Linux de gérer l’heure système en « heure locale » :

• « Ancienne » méthode (non systemd) :

• « Nouvelle méthode » (systemd) :

Et tu vérifies que c’est bien pris en compte avec « timedatectl ».
Note (et ça te sera rappelé en gras) que Linux n’aime pas trop être en « heure locale » : ça l’empêche de bien prendre en compte le changement d’heure (sauf si la machine est allumée à ce moment-là ; sinon, il faudra resynchroniser manuellement).

A ma connaissance tous les UEFI ont un mode de compatibilité BIOS avec le loader sur le MBR d'un disque.
Donc si tu installes ton Arch en isolation totale sur un disque tu vas pas modifier la liste de boot UEFI qui continuera à ne connaitre que windows.
Puis tu bootes en mode BIOS à la demande sur ton disque Arch si j'ai bien compris ce que tu veux...
 
J'ai fait exactement ça, mais dans l'autre sens
Avec Arch installé en UEFI et windows en mode compat BIOS et qui touche pas à l'UEFI.

Nop, ils ont commencé à virer le BIOS/CSM mode depuis cette année

Ah. C'est bon à savoir
A voir si tromzy a ce mode ou pas du coup.

J'ai une CM récente (x570 inside), et j'ai toujours le mode BIOS, et heureusement car toute mon installation était en mode BIOS avant de changer de matos, comme ça j'ai rien eu a faire ...

X570 c'est 2019 non? (J'ai aussi une X570 et ma carte graphique ne supporte pas le boot en UEFI pour je ne comprend pas quelle raison, donc merci pour le CSM.)

Oui effectivement, mais me semblait que Xat avait écrit "depuis des années", surement un edit de fourbe juste avant mon quote

Non j'ai corrigé la faute "cet" par "cette"
2020 pour Intel la suppression du mode BIOS

D'ailleurs en parlant de ça, est-ce possible de transformer une installation type BIOS/MBR en UEFI, sans avoir besoin de tout résintaller (j'ai un dual boot win10 / Arch, chacun sur un disque dédié, que j'aimerai conserver) ?

Oui, j'ai fait cela il y a un an environ. Ce n’était pas drôle car je n'ai trouve aucun guide qui explique comment faire, j'y ai donc passe des heures en tâtant un peu.

Ahhhhhhh, du coup ton retour d'expérience m'intéresse fortement

J'ai une carte mère MSI Tomahawk B450 Max, elle doit avoir deux ans je pense, donc je pense que le mode de compatibilité existe encore.
 
Par contre si je fais ça, il faut que je pense à passer en mode Bios avant d'installer Arch (mais je crois pas que je vais le faire en fait, désolé ).

Ca fonctionne bien.
J'utilise systemd-boot au lieu de GRUB2, c'est un peu different mais bon.
De mémoire, mais attention je peux me tromper, il m'a fallu installer systemd-boot, le configurer ce qui n'est pas automatique comme pour GRUB (ce que je ne comprend pas d'ailleurs) c'est a dire créer un fichier conf par noyau, et changer l'option dans le BIOS.

Faudra tâtonner un peu mais en gros suffit de booter un live CD Arch en mode UEFI, te chrooter sur ton système déjà installé puis de là gérer ton ESP, y installer un loader et l'ajouter à la liste de boot UEFI et c'est fini.
Il te faudra un disque en gpt pour l'ESP par contre.

Perso je suis sur grub2 pour l'UEFI.
J'ai jamais eu le courage d'en changer et ça marche parfaitement.

Ah, pas de disque en GPT pour l'instant, ça attendra alors  

Il y a pas moyen en UEFI de démarrer sur grub, permettant ainsi d'avoir un menu de démarrage pour choisir le système d'exploitation ?
 
En faisant passer grub pour un OS par exemple, le bios UEFI n'y verrait que du feu.

C'est surement possible, c'est ce que je fais avec systemd-boot.
Et GRUB est un OS

Oui bien sûr, il suffit de lire le wiki.

Archlinux j'ai jamais essayé, par contre faire un dual boot en UEFI avec W10 et Manjaro ne pose aucune difficulté... faut juste désactiver le secure boot par contre ( contrairement à Ubuntu qui peut s'installer avec le secure boot )

C'est ce que j'ai, tu fais une install classique (enfin, avec Anarchy pour moi) en bootant en uefi et en choisissant grub.
J'avais essayé de me passer de grub, et de démarrer directement par l'uefi (EFISTUB), mais je n'avais pas réussi à l'époque, ça ne fonctionne pas sur mon Dell.
Sur mon portable, j'ai mis le windows d'origine sur un petit m2 supplémentaire dans le port wwan, et le linux sur le m2 d'origine, c'est peinard comme ça pour éviter les boulettes.
je démarre sur le "disque" linux par grub, qui affiche un menu avec windows dedans (il y a un paquet à installer pour détecter les autres os, j'ai oublié le nom).

os-prober. J’en parle dans mon message posté plus haut.

j'ai pas lu et je me doutais bien que quelqu'un viendrait donner le nom du paquet

Pour l'EFISTUB, c'est plus ou moins bien implémenté suivant les constructeur/BIOS.
Sur un Dell Latitude de 2018 par exemple tu peu rajouté ta ligne de boot directement dans le bios (ou via un utilitaire comme efibootmgr), ex :

Sauf que le Dell en aura rien à branlé des arguments ou même plutôt de tous ce qui suivra le premier espace. Il va simplement interpréter :

et d'un coup ça plantera lamentablement    
 
 
 
 
La solution dans ce cas là c'est l'Unified Kernel Images :
 
En gros le principe c'est de rassembler tous ton bordel de boot (kernel, initram, ucodes & arguments, etc..) en un seul est unique fichier et de faire pointer ton bios sur celui-ci
https://wiki.archlinux.org/index.ph [...] rnel_image
mkinitcpio, ne propose pas de base ce genre de fonctionnalité d'un coup faut bidouiller soit même (ou fouiller sur github) son propre script qui ce lancera (avec un hook pacman) après chaque maj de kernel par exemple
 
Sinon alternativement à mkinitcpio il existe dracut, qui lui à apparement cette fonctionnalité (jamais essayé)
https://wiki.archlinux.org/index.ph [...] rnel_image  
 
 
 
Edit : il y à une discussion récente à ce sujet  ici : https://lore.kernel.org/linux-efi/2 [...] rdale.lan/
j'ai pas tout pigé mais peu être que maintenant ça marche directement

rokin-k a écrit : a écrit :       Edit : il y à une discussion récente à ce sujet  ici : https://lore.kernel.org/linux-efi/2 [...] rdale.lan/ j'ai pas tout pigé mais peu être que maintenant ça marche directement

 
 
Je m'autoquote, je viens de retesté et ça marche toujours pas "outofbox"    
 

au reboot je tombe en emergency :

ouia, bah je ré-essayerai sur mon prochain portable

Avez-vous remarqué un changement de style de police depuis une récente mise à jour de pacman ? (paquet fontconfig et version de plasma 5.20)

Elles semblent avoir un aspect un peu plus "resserré" (notamment dans la boite d'édition des messages de ce forum),

et dans l'éditeur de texte Kate (kde) la police de texte est devenue toute petite.

J'ai rien remarqué de spécial pour la console ou pacman mais j'ai pas la police par défaut (et j'utilise pas kate)

C’est pas ce qu’il a demandé.
 
Elbarto veut savoir si, après avoir fait la mise à jour de Plasma vers la 5.20, ceux qui utilisent ce DE ont aussi remarqué une différence visuelle dans l’affichage des textes dans l’interface graphique et les programmes par rapport à avant.

Je n'avais pas remarqué mais je crois bien que tu as raison.

Yay vient de se mettre à jour, et bizarrement depuis la vérification des mises à jour pour AUR est extrêmement lente à se faire  ( cad que les lignes 9,10 et 11 mettent plusieurs secondes à apparaître -> cad 7 secondes environ )
 

Il y a un rapport de bog sur GH, espérons que le dev trouve le soucis.

En effet, ça le fait chez moi aussi.

Bon ça va, c'est pas non plus le bug le plus gênant du monde  

Utopie : est-ce que c'est prévu un jour que pacman soit capable de télécharger le PKGBUILD d'un paquet, de le compiler, puis de l'installer, puis ensuite de suivre les mises à jour de ce PKGBUILD ?

En gros faire exactement ce que font les utilitaires de type yay, il suffirait de créer une option "--install-from-pkgbuild" (ou --aur), et de créer une nouvelle section dans le fichier de configuration pacman pour ajouter le dépot AUR.

Comme ça il n'y aurait qu'un seul logiciel à lancer pour mettre à jour à la fois les paquets officiels, et les paquets de type AUR (provenant d'un PKGBUILD distant), plus besoin de surcouche de type yay.

Non jamais.

Vu que Aur est une "tolérance", jamais en effet.

Sauf si les dirigeants d'archlinux sont destitués  

une nouvelle gouvernance, avec une modernisation de pacman :

- passage au format binaire pour la base de données, plutôt que le format texte lent à parser quand on a un disque dur classique
- possibilité d'installer et de mettre à jour les paquets depuis les sources, sans passer par la case makepkg
- un mécanisme user-friendly pour annuler un "pacman -Syu" et revenir à un état antérieur, avec possibilité de réaliser plusieurs clichés de sauvegarde de sa config de paquets à des dates différentes
- informer via pacman de manière plus claire l'utilisateur lorsque des news figurent en une du site archlinux, afficher dans la console ces news avant que la mise à jour se fasse
- un peu d'intelligence artificielle pour que pacman se débrouille tout seul en cas de blocage, quand la solution semble évidente, de l'IA désactivable dans les options pour ceux qui n'en veulent pas

et d'autres choses, telle que :

- un installateur 100% graphique comme à une époque, en plus de la méthode "100% console", pour ne pas exclure les débutants
- des modérateurs moins policiers sur le forum anglais d'archlinux, l'un des forums les moins agréables pour les débutants
- une refonte totale du système de rapport de bug archlinux, pour qu'il soit similaire à celui du noyau linux, il y a en marre des administrateurs qui ferment illico
les rapports de bug sans laisser le temps à l'auteur de dialoguer ou de comprendre ce qui se passe, sur celui du noyau linux même si le rapport de bug est mis sur "résolu", ou "fermé" tu peux quand même poster un message
- resserrer la vis lors de la phase de testing, pour réduire le nombre de paquets bogués qui arrivent sur les dépôts classiques, inciter les packageurs à être plus rigoureux dans les tests
- Coopération avec les gens de Manjaro, pour réutiliser leurs bonnes idées en terme d'outils user-friendly

Sinon un fork d'archlinux sans les défauts, c'est parfois ce qui arrive quand la base n'est pas écoutée par ceux qui sont en haut de la pyramide.

 
Je vote pour, et pas qu'une fois! Le nombre de fois ou j'ai du faire cela a la main pour trouver le mauvais paquet... C'est archi lourd...
 
J'imagine qu'en lisant pacman.log on pourrait savoir ce qui était installer a quel moment, mais c'est un peu lourd...