alex

alex, 8 hours ago

Même en basculant en mode bureau ou en faisant défiler, le bouton défile en même temps et reste toujours au dessus du clavier.

alex, 23 hours ago

@framasky Qui c’est ? Jamais entendu parler.

alex, 1 day ago

Autrement dit : avec un kernel custom, l'initramfs sert à rien.

alex, 2 days ago

Nan, c'est pas possible. Il y a un gros problème, là, avec Arch...

alex, 2 days ago

Ok, ça démarre tellement vite que l'écran (en HDMI) a à peine le temps de basculer que l'environnement graphique est déjà démarré.
Avec ma carte de capture vidéo, j'ai le temps de voir les messages de démarrage.

video/mp4

alex, 2 days ago

Bon, juste à corriger l'erreur de son (j'ai du rater un truc côté ALSA. J'ai bien le son en HDMI mais pas sur la sortie analogique (jack 3.5)

EDIT : faut brancher un truc sur la prise sinon c'est éteint >.<

alex, 2 days ago

bon, le problème du noyau étant réglé, comprendre maintenant pourquoi les exécutables x86 ne fonctionnent pas.
Et c'est pas un problème de noyau Linux, c'est le même qui tourne (quasiment, à part l'option USB4 que j'ai ajouté après) qui tourne sur mon autre PC

alex, 2 days ago

Bon, ça, c'est fait. Comme ça, ça pétera plus.

alex, 2 days ago

Du coup, récapitulatif :

Mise à jour classique #ArchLinux (pacman -Syu)

Mise à jour du noyau Linux en version 6.9.1

Redémarrage

Plus de bluetooth, du coup, plus moyen d'utiliser mon clavier USB.

Une recherche rapide : ok, bug identifié côté kernel. Action recommandée : faire un rollback et réinstaller le kernel précédent.

Et c'est là que la merde est arrivée : il n'y a AUCUN moyen de basculer sur l'ancien noyau de manière simple, ArchLinux EFFACE systématiquement le noyau précédent.

Installation du kernel LTS. Démarrage dessus : kernel panic, pas d'USB ni quoi que ce soit.

Redémarrer sur le kernel problématique : impossible.

Booter sur un live Arch, chroot.
Virer 6.9.1 et lts.

Récupérer le noyau 6.8.9 et tenter de l'installer. Ok, mais mkinitcpio indique que /lib/module/6.8.9 n'est pas trouvable.

Fin de soirée, mal de crâne, je râle fortement (ce genre de connerie ne m'est jamais arrivée en 24 ans de Debian). Je lâche l'affaire.

Ce matin : mise à jour du noyau sur mon PC principal (source : kernel.org, version vanilla, sans patches, version 6.8.2)
Paramétrage, compilation, installation, redémarrage, réinstallation du pilote proprio nvidia : aucun souci.

J'active 2-3 paramètres spécifiques pour mon miniPC dans les paramètres du noyau (wifi/bluetooth MediaTek, support de USB4/Thunderbolt), compilation vers un tar.xz et copie sur une clé USB.

Démarrage du miniPC depuis le live arch, extraire le kernel 6.9.2 dans /boot, /lib/module et /lib/firmware (créés, parce que non trouvés¹).

Redémarrage.

Le système démarre, mais j'ai pas d'affichage correct (Framebuffer EFI), pas de wifi ni de bluetooth. Un coup de dmesg m'indique qu'aucun firmware n'a pu être chargé.

Retour sur mon PC Debian, la doc Gentoo indique deux cases à cocher côté config (les éternelles PDCAC), re-compilation, package tar.xz, copie sur clé USB, brancher la clé sur le miniPC, écraser à chaud le noyau dans /boot et les modules dans /lib/module.

Redémarrer.

Et là : OMFG.

Capture vidéo pour comprendre ce qu'il se passe. J'ai un écran noir et l'écran de connexion sddm qui apparaît dans la foulée.

En fait, le système démarre tellement rapidement (rEFInd -> kernel efi -> sddm en moins de 5 secondes) que l'écran a à peine le temps de capter le changement de résolution en HDMI et de basculer que le système est déjà prêt.

Je me rends également compte que j'ai oublié de générer les initramfs (ça sert à rien en fait quand le noyau est paramétré et compilé correctement).

Test : et là, c'est le drame. Pas de support de ebi32. Problème de kernel ? Nope. Le même noyau Linux sur l'autre PC lance Steam et Wine sans souci.

Après recherches et tâtonnements, je finis par constater que glibc32 censé être présent dans /lib n'est pas là.
En fait, c'est pire que ça : /lib est vide, sauf module et firmware. Mais qu'est-ce !!!

Une comparaison rapide sur mon autre PC, /lib est en fait un symlink sur /usr/lib (une systemderie à tous les coups).

Déplacer /lib/modules et /lib/firmware dans /usr/lib (firmware présent mais pas modules, je cherche plus à comprendre), supprimer /lib et créer un lien symbolique /lib qui pointe sur /usr/lib.
Redémarrer.

Le système démarre correctement sur mon kernel custom, wine et Steam aussi.

--
¹ : c'est LÀ que j'aurais du me douter qu'il y avait un gros souci à cette étape.

alex, 2 days ago

Problème trouvé (et résolu) pour arch : /lib corrompu.

Ce qui explique pourquoi les kernels pétaient tous (/lib/module) et que multiarch (wine, steam…) ne fonctionnaient plus (glibc32 dans /lib)

et concrètement, j'aurais du percuter plus tôt, quand j'ai eu les erreurs de firmware impossible à charger.

alex, 2 days ago

À noter : le problème des kernels Linux mal gérés dans #ArchLinux est connu depuis 2009.

"The problem:
The current method of upgrading kernels will remove the current kernel, modules, and initrd on upgrades.
This is a problem because: imagine if the new kernel has a serious regression in it on your hardware, or worse yet, it doesn’t boot at all. Now all of a sudden, the user is stuck with no clear, straight forward path to fix the issue."

https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/10

Ça tombe bien, j'ai cumulé les deux : régression critique et ne boote plus.

alex, 1 day ago

@devnull @TritTriton il est grand le bras du voisin… un peu moins de 800 km.

alex, 2 days ago

alex, 2 days ago

alex, 2 days ago