Reprise du message précédent :
Encore une nouvelle version du paquet grub, la quatrième :
 

Pour résumer cette affaire de grub : apparemment faut s'assurer de faire grub-install ET mkconfig pour pas tout casser.
En général j'en fais aucun des deux et j'ai aucun problème, mais pour anticiper les rares cas ou je ferais un mkconfig seul dans le futur, je me suis dit que j'allais tout resynchroniser maintenant pour pas me retrouver coincé plus tard...
 
Bon alors j'ajoute un avertissement à la procédure :
Dans mon cas, commencer par grub-install puis mkconfig (comme suggéré par les devs ArchLinux) ne fonctionne pas.
 
grub-install reste bloqué indéfiniment devient difficile à tuer (même à coup de kill -9 il reste zombie plusieurs secondes et le système se met à devenir lent de partout, je sais pas pourquoi)
 
Bref, donc j'ai fait :

• mkconfig
• grub-install
• mkconfig

Et là c'est bon.
 

 
osef, on utilise tous efistub ici

Oh, que non ! Loin de là, même…
 
Enfin, je peux aussi m’en battre les steaks, puisque c’est encore une correction ne concernant que les machines en UEFI. C’est pas mon cas, donc encore une fois, j’ai simplement laissé la MAJ du paquet s’installer, et c’est tout.

maj faite ici, reboot (en efi) sans probleme.
c'est une correction mineure indépendante du probleme précédent

ouf !

Pour ne plus avoir peur du cas "installation de grub sur bios UEFI et partition GPT" et de ses conséquences négatives (installation qui foire, nécessiter de réinstaller grub, scénario compliqué avec multiboot windows, secure boot, des lignes de commandes grub obscures qu'on tape mécaniquement sans comprendre leur signification) :
il faudrait trouver une vidéo de formation qui explique les concepts du bios UEFI, puis du partitionnement GPT et enfin de grub.

Il y en a sans doute sur youtube, l'objectif étant de ne plus être dans le brouillard sur ces concepts à la base délicats à comprendre et peu intuitifs.
Voir aussi le site openclassroom.

Je suis comme Trit sur un vieux PC équipé d'un bios à l'ancienne (et j'ai que des partitions à l'ancienne, de type MS-DOS/MBR, partitions primaires/logiques limitées à 2.2 To), mais le jour où je passerai sur de l'UEFI je sais que ça va être chaud de maitriser ces 3 concepts (UEFI, GPT, grub dans de l'UEFI).

Le jour ou tu passeras a de l'UEFI tu utiliseras peut-être quelque chose d'autre que GRUB.

J'ai relu un peu les pages wiki concernant ESP / EFI Boot Stub  
 
Je sais que certaines machines Dell ont un souci avec le boot efistub, est-il possible d'essayer quand même en conservant mon boot grub classique ? Avoir les 2 types de boot en parallèle ? (sans tout casser)

Rappel de l'article sur efistub :
https://wiki.archlinux.org/title/EF [...] %C3%A7ais)

étant débutant aussi sur ces problématiques UEFI/GPT/boot EFI : ça m’intéresse de savoir si on peut laisser tel quel la configuration de grub de Berlo, pour tester à la volée (via un changement d'option dans le bios, ou une ligne de commande qui modifie le contenu de la mémoire flash du bios stockant ses paramètres) le boot "efistub" (le bios de la carte mère configurée pour lancer directement archlinux, en court-circuitant grub).

Lu vite fait on comprend que la carte mère est capable d'elle même (si on la configure correctement) de lancer archlinux, sans l'aide de grub, un peu comme si un gestionnaire de boot était intégré en dur dans sa mémoire flash.

Idéalement il faudrait une implémentation "user-friendly" dans les bios UEFI, pour que l'utilisateur puisse directement dans l'interface du bios choisir l'OS à démarrer, à la souris on donnerait toutes les infos à la carte mère de manière intuitive (en sélectionnant un disque dur/SSD, puis le chemin où est installé le noyau linux, voir laisser se débrouiller toute seule la carte mère pour qu'elle détecte automatiquement les OS installés, un peu d'IA, pour aider l'utilisateur pas très technicien).

Comme a l'ancienne tu peux avoir GRUB sur un DD et autre chose ailleurs.

C'est un peu ce que j'ai, 2 disques NVMe avec chacun sa partition ESP, avec le menu F12 du bios, pas de problème pour démarrer l'un ou l'autre, ça me suffirait.
Sur mon disque Linux, la partition ESP contient grub qui peut lancer Linux ou Windows. Mais dans le fond ça ne me sert pas à grand-chose vu que j'ai le boot menu du bios et que je démarre windows rarement.
Je me demandais surtout si ça est si ça ne mettra pas le bazar dans mon installation d'arch à vouloir faire grub et efistub en même temps. le même souci qu'avec la mise à jour de grub récemment.
Bon en plus il y a probablement un souci avec le Bios Dell, donc je suis moyen chaud pour tester...

Je dirais que la présence d'un menu grub reste utile malgré Efistub,

afin d'avoir la possibilité au boot de lancer des utilitaires de diagnostic (memtest), un noyau différent, ou lancer un mode "rescue" (archlinux en ligne de commande, sans interface graphique, pour rétrograder un paquet problématique, contourner un bug du gestionnaire de connexion graphique).

Il reste le truc de la touche F12 pour choisir de booter sur une clé USB contenant des utilitaires de dépannage, mais c'est moins pratique que d'avoir intégré ces utilitaires dans le menu grub (grub étant capable de lancer des images ISO présentes sur le disque dur/SSD interne du PC).
https://doc.ubuntu-fr.org/tutoriel/ [...] images_iso

 
 
Bien sur, tu peu tout a fait avoir une (ou plusieurs entrées) configurées dans ton BIOS pour démarrer en EFI Stub tout en conservant grub.    
 
 
Concernant Dell (dans mon cas un latitude 5480), l'EFIStub marche bien  
en revanche il n'est pas possible de directement ajouter/éditer correctement les entrées à partir du BIOS (car les arguments sont pas sauvegardés ) et il faut donc passer par l'outil efibootmgr.

Systemd-boot ici : simple et facile
 
Grub c’est très bien mais j’ai pas besoin de 99% des fonctions, il me faut juste un menu qui me permette de choisir ma version de noyau, pour Windows j’utilise F12 (sauf sur mon laptop où systemd-boot lance aussi Windows)

Ok, mon Dell doit être a peu près de la même génération, faudra que je tente ...
 

Hello
 
Après être allé faire un petit tour sur la dernière ubuntu, je me reinstall un arch à la place, je préfère.
J'ai finis l'install classique, avec un boot direct de l'UEFI sur le noyau, aucun multiboot sur la machine ... pe que je mettrai un systemd-boot plus tard pour avoir le choix du noyau ou un mode rescue, à voir...
 
Bref j'ai juste une question, vu que c'est une fresh install sur du matos assez récent (fixe HP, processeur intel, carte graphique intel du proc, SSD) j'ai bien envie de tester une install full wayland (sans X11 donc, à part la couche de compat de wayland au cas où)...  
Du coup j'install quoi comme paquet ? juste : pacman -Sy wayland gnome
et ça roule ? ou y'a d'autre trucs mystère à mettre ?

Ca depends de la methode d'installation et des dependances.  
 
Pour Gnome je ne sais pas mais par exemple pour KDE si tu ne souhaite absolument pas de xorg-server, suivant si tu installe le meta-package ou groupe plasma complet tu aura dedant par exemple SDDM qui lui necessitera xorg en dependance donc dans ce cas là faut installer la liste du meta/groupe au cas par cas ou l'exclure et remplacer SDDM par autre chose.
 
Il y à peu être plus simple mais en tout cas c'est comme ca que j'avais fait.

PS : après dans un environnement purement wayland /xwayland faudra peu etre un peu bataillé à configurer/debugger certaines appli pour qu'elles s'executent par defaut en wayland et/ou qui auront parfois des comportement un peu etranges.  
 
J'avais eu firefox dans ce cas là qui s'ouvrait hors de l'ecran et qui ne retenait pas les positions des fenetres et ou j'avais du trafiquer le profil,  VSCode auquel il faut rajouter une config specifique pour qu'il s'ouvre par defaut en wayland, un probleme avec le dualscreen et quelques autres bricoles.

Je trouve pas ça très mûr… disons que hors cas spécifiques (tu veux pas de tearing / tu veux du scaling différencié par écran), je trouve pas que les bénéfices dépassent les inconvénients pour le moment

J'avais fait cette installation l'année derniere (et j'y suis toujours dessus) par curiosité et par envie d'essayer de virer xorg qui niveau securité... à fait sont temps
 
Globalement ça marche pas trop mal et j'ai jamais eu de gros crashs sur KDE mai wai c'est pas encore forcement clé en main out of the box et je comprends que ca puisse donné envie de mettre xorg qui lui juste marche
 
Toutes les apps KDE/QT marchent parfaitement et j'imagine que c'est aussi le cas pour celles de la suite Gnome.  
 
Après les appli "externes" de la suite KDE ou Gnome wai ca peu etre encore assez rock&roll
 
Actuellement sur KDE j'ai encore quelques bugs au niveau de la gestion du dualscreen et quelques jeux steam qui ne se lancent pas en wayland (mais xwayland oui.) Plus les "bug" fixés/cités le post d'avant.

Depuis un petit moment les maj de firefox beta echoues, car l'adresse de téléchargement n'existe pas, il y a toujours une version d'avance.
Probablement parce que les versions locales sont légèrement en différé.

C'est le paquet "firefox-beta-bin-all-localizations" sur AUR, avec un petit fichier de configuration pour prendre en français à l'emplacement /home/berlo/.config/ff-downloader.conf qui contient seulement "ff_fr"

Hello
 
J'ai fini mon install, gnome sous wayland
Juste un petit soucis, quand je modifie le param Ecran Noir d'Energie, pour mettre plus long que 5mn, il n'est pas conservé, il suffit que je change d'item puis revienne pour que ce soit repassé à 5mn
 
Une idée ?

Ça y est : Python 2.x a été dégagé d’Arch Linux ! Pensez à le désinstaller s’il l’était encore chez vous, ainsi que ses dépendances éventuelles, parce qu’il n’existe plus dans les dépôts et ne sera donc plus mis à jour sur vos machines (pour ma part, il n’y avait que les paquets « python2 » et « python2-pyinotify »).

J’ai remarqué une chose à partir du noyau 5.19.10 sur le PC familial : l’ouverture d’une session XFCE met moitié moins de temps à se charger si aucun autre utilisateur n’en a une d’ouverte en arrière-plan. Par exemple : au lieu de devoir attendre 3 minutes pour charger la session de mon père devant un écran noir avec juste un pointeur de souris visible, je n’attends plus qu’1mn30. Le PID de Thunar (qui est un des derniers processus à se lancer) est d’ailleurs moins élevé : dans les 6 500 au lieu de 12 000 et des bananes (et ça, pour la toute première ouverture de session après démarrage). Je sais toujours pas à quoi ce délai d’attente est dû exactement (ça le fait pas sur mon portable, où XFCE se charge en 20 secondes et Thunar affiche un PID entre 780 et 810), mais je vais pas m’en plaindre.

Pour les PIDs en tout cas c'est normal : ils sont incrémentés au niveau système, pas au niveau utilisateur.
Donc pour le nième utilisateur, ils commencent à (n - 1) * (nombre de processus d'une session Xfce) + (processus système), en gros.

Et… Y a rien qui te fait tiquer quand je dis que juste après le démarrage (donc PID partant de zéro), lorsque le démon d’arrière-plan de Thunar se lance à l’ouverture de la toute première session XFCE lancée dès l’apparition de l’écran de connexion de LightDM, son PID est à 6 500 (ou 12 000, comme c’était le cas jusqu’à il y a peu), alors que rien n’a été lancé dans l’intervalle ? Quand, dans les mêmes conditions, ce même PID est dans les 800 sur une autre machine ?
 
La raison de ce PID anormalement élevé, je la connais : pendant ce délai d’écran noir où le PC semble bloqué et ne pas vouloir ouvrir la session, j’ai pu observer avec un Htop lancé dans une console TTY que le CPU était à fond sur ses 4 cœurs et que tout un tas de processus « xfce4-desktop » n’arrêtaient pas de se lancer en continu pour planter aussitôt (plusieurs milliers, donc). Et ce n’est qu’après un certain délai (variable selon le compte utilisateur : 3 mn pour mon père, 2 pour moi et 1 pour ma mère ; avant que tout ça ne fût réduit de moitié dernièrement) que le bureau et les tableaux de bord s’affichent enfin et que l’activité CPU se calme.
 
Maintenant, pourquoi ça fait ça, je l’ignore et j’ai même renoncé à chercher, parce que j’en ai eu marre de chercher une cause qui m’échappe totalement. Tout comme j’ignore pourquoi, quand je passe par la fonction « Changer d’utilisateur » (pour ouvrir une autre session XFCE en parallèle d’une autre, qui reste ouverte en arrière-plan), ça n’impose pas ce délai d’attente.

Ah désolé, je m'étais pas focalisé sur la bonne info.

De toute façon, la seule piste qui me resterait à explorer, ce serait celle de la fréquence de rafraîchissement de l’écran (sur 75 Hz au lieu des 60 « classiques » sur un écran LCD acheté en 2001). Mais j’en doute, parce que la bascule à 75 Hz se fait au démarrage des services de systemd (donc encore en mode console texte pur), et que ça n’a pas d’impact sur le démarrage de X et l’affichage de LightDM. C’est après l’identification que ça coince. Mais quand ça se passe, XFCE est déjà techniquement démarré : la session de ma mère utilise un pointeur de souris blanc, et il a le temps de basculer sur ce modèle avant la phase d’inactivité apparente. De même, en soirée, le changement de teinte opéré par xfluxd se fait aussi durant ce laps de temps. De fait, je sèche.
 
Comme ça a commencé vers fin 2018, je croyais que c’était dû à une incompatibilité du pilote Nouveau, vu que la CG n’était plus prise en charge par les pilotes Nvidia proprio. Mais même en la remplaçant par une CG AMD (et avoir fait la bascule des pilotes avant le changement de carte), ça a continué. Donc, même ça, c’est pas en cause.

Salut, j'ai toujours pas fait la MaJ grub mais j'ai vu des messages dessus. ça fait longtemps que je ne m'y suis pas repenché dessus mais si je pouvais éviter une galère
Au final je fais juste la MaJ puis :
grub-install --target=x86_64-efi --efi-directory=/boot/EFI/ --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfg
?
edit : ça a l'air bon.
Petit problème côté lightdm par contre, je ne peux plus login en graphique
mouarf c'était : https://bbs.archlinux.org/viewtopic [...] 3#p2058733

Arf, j'avais oublié de faire la réinstall de grub suite à la mise à jour, la j'ai installé un nouveau kernel, du coup après avoir fait le grub-mkconfig et reboot, direct sur l'UEFI    
 
Un petit reboot sur la clé d'install Arch, chroot, réinstall de Grub et roule
 
Prochaine fois je fais la maj dès qu'on en parle ici, ça m'évitera ce genre de petite surprise ^^

 
Ce matin en démarrant le portable du taf sous Arch, surprise, Grub me monte une erreur je sais plus quoi, bref, ça boot pas.
 
Bizarrement, après avoir booté sur la clé d'install Arch et chroot, je constate qu'il n'y a plus rien dans /boot
 
J'ai forcé la réinstall du noyau qui a remis les fichiers dans /boot, et ensuite réinstallé Grub puis refait la config, tout est rentré dans l'ordre, mais c'est bizarre ce truc, non ?
Vous avez déjà eu ça ?

C'était monté au moins ?

Bah non    
 
Je viens de me rendre compte que lors de on install il y a 3 mois, j'avais mis /boot dans une partition dédiée    
 
Bref, problem solved, j'avais oublié de refaire l'install de grub après maj, et avec ma mémoire de poisson rouge, j'ai oublié que /boot était séparé, ça n'arrivera plus j'ai tout noté maintenant  

Y a eu une MAJ de GRUB, il y a quelques jours. Comme d’hab’, j’ai rien eu à faire car mes machines n’ont pas d’UEFI ; mais celles qui en ont auraient apparemment toujours besoin de refaire une réinstallation complète de GRUB une fois la MAJ installée (le message d’avertissement est toujours présent après cette étape, je croyais qu’ils avaient oublié de le retirer)…

Suite à la sortie de systemd 251.6 tout récemment, ça y est : le bip du haut-parleur système lorsqu’on veut éteindre ou redémarrer l’ordi a été supprimé ! On n’aura plus à sursauter en craignant qu’il y a eu un souci.
 
En revanche, le message finissant par un gros « NOW! » reste (au moins depuis une session XFCE, car ça ne le fait pas depuis l’écran de connexion de LightDM).

j'ai redémarré en serrant les fesses avec cette nouvelle maj de GRUB et le noyau linux 6. Mais nickel, ça redémarre bien, ras.
 

Un bug sur Arch Linux (ou qui apparaît en tout cas en premier sur Arch), ça faisait longtemps !
 
Toujours avec XFCE, il y a normalement une icône dans le dock qui ouvre un menu en cascade permettant d’ouvrir directement une fenêtre du gestionnaire de fichiers (donc Thunar, par défaut) sur le dossier que l’on veut.
 
Ben, suite aux MAJ faites ce matin (au plus tard), cette fonction est cassée : elle affiche un message d’erreur si jamais le dossier visé contient des espaces dans le nom du chemin d’accès (il les remplace par la chaîne « %20 »). En revanche, ouvrir un dossier sans espaces dans le chemin, ou l’ouvrir depuis Thunar fonctionne. Mais bon, c’est ennuyeux quand on a pris l’habitude de passer par ce menu pour aller plus vite que de devoir déployer l’arborescence dans Thunar ou double-cliquer en série…
 
Mon tweet avec des captures d’écran
 
Le rapport de bug que j’ai envoyé sur Arch, même si j’ignore encore quel paquet mis à jour dernièrement est le véritable fautif (mais faut bien commencer quelque part, et Thunar est impacté, donc…).
 
EDIT : et ce problème ne se produit pas sur l’autre ordi, que j’ai pourtant mis à jour dans la foulée ! Je comprends pas, là… Pourquoi il y en a un où c’est cassé, et pas l’autre ?

Des nouvelles de mon bug : il viendrait en fait de xfce4-settings 4.16.4. Ce qui est bizarre, c’est que c’est bien cette version qui est installée sur les deux ordis, et elle ne pose problème que sur un seul. Pourquoi une telle différence, ça reste un mystère complet…
 
Enfin, le problème est identifié, donc on peut espérer une résolution prochaine, hein ?

Bug corrigé avec xfce4-settings 4.16.5 ! \o/

J’ai l’impression qu’il n’y a plus que moi, ici… Il est parti, Elbarto ?
 
Bon, c’est pour dire que la dernière MAJ de mkinicpio apporte quelques changements à l’usage : de nouveaux hooks lors de la génération des initramfs (au moins [kms] et [consolefont], et des nouveaux aussi dans la liste des potentiellement manquants pour les fallbacks) ; de plus, le pilote vidéo semble désormais chargé juste après systemd, avant le résultat de l’analyse fsck de la partition racine, et non plus à mi-parcours du processus de démarrage des services. Ça se voit surtout si on en est resté au HDD et ça surprend, au début.