Giving #OpenSuse Leap a try. Would like to go from my rather moody #ArchLinux to a more stable system. Feels like I learned everything I could in terms of usage, now I want something that needs less maintaining and gives me more time to do other things.
Given I do not trust US companies (not necessarily because of the company, but the legislation they have to follow) #Fedora or anything #Ubuntu was an absolute no-go. And #Debian just isn't modern enough, despite being dead-stable. 😉 #Linux
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.
À 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."
@TritTriton@alex pour alléger le cache sans tout effacer, j'utilise
paccache -rk2 (garde les 2 versions les plus récentes, faisable juste après une update) ou paccache -rk1 (garde la version la plus récente -- paccache est dans le paquet pacman-contrib).
Il m'est quand meme arrivé une fois où le pc s'est éteint (je sais plus pourquoi) en pleine mise à jour du noyau. J'ai du redémarrer avec une clé usb pour remettre le système en état. Sinon, tout roule !
Absolutly fascinated by my little #OptiPlex and the 24" monitor.
It feels so cozy and familiar.
Running a #Windows and #ArchLinux vm while browsing and way too many terminals/tabs open... no issues at all for that little system.
Good times indeed.
#ArchLinux : omfg, c'est trop compliqué de gérer différentes versions du kernel Linux. L'installation du nouveau noyau vire obligatoirement le noyau courant. Tant pis si ça pète. Tant pis s'il y a plein de régressions. OSEF. Pas notre problème.
Man, the longer I have :nixos: #NixOS and :manjaro: #Manjaro running in parallel, the more annoyed I am by the :archlinux: #ArchLinux way, e.g.:
· Python update ⇒ all python-based #AUR packages must be rebuilt. #pipx-installed packages also need reinstallation.
· separation between distro repos and AUR is anoying. 'yay -Syu' (or whatever) never really works in one go (be it some stupid sudo prompt later)
· so many AUR packages don't build reliably or at all.
...
...
· no guarantee that your own PKGBUILDs still build in two months. You WILL have to touch them again at some point. Quite tiring. Also, the rules for packaging always change and you get angry requests for your AUR packages. The AUR is quite a mess with regard to consistency and standards conformance.
· latent fear that an update breaks something
Sure, these points are very AUR-centric, but obviously #ArchLinux without the AUR isn't enough for real-world-desktop usage I would say.
My experience with #elementaryOS so far has not been great. After installing I had to do a bit of tinkering to install the right Nvidia drivers and be able to boot to GUI, many times the system hangs after coming back from suspend, the default terminal has some issue that makes it laggy, etc.
Since replacing my graphics card in March, my arch system crashes on resume 20% of the time. I don't see any obvious cause in the logs, so I finally cracked and posted a discussion thread: https://bbs.archlinux.org/viewtopic.php?id=296050
Just installed #xwayland 24.1! Now to wait for the new version of the #Nvidia drivers. This is part of why I installed an Arch-based distro, I don't want to wait six months to two years between significant updates, I don't have that much extra time to spare in my life for reasons outside me and my body that shouldn't exist but do exist in this world and I don't want to waste it waiting around for new versions of stuff.
I am once again getting the urge to install EndeavorOS but I... only use it to run firefox on it.
Seriously, this is the biggest reason I stopped using Linux; I don't actually use it for anything but browsing the web since gaming just is so much more convinient on Windows and I'm not into Linux for ideological reasons (yet).
I ALSO stopped because the number of bat shit racist libertarians on Linux forums I frequented were souring the experience. But that's another matter.
What do folks like for Linux offsite backup providers?
I have a Linux desktop with 1-2 TB of data that I want backed up on someone else's servers. I'm currently using Crashplan but my primary use case is data corruption which leads to lost files, and crashplan won't show me a list of recently deleted files that I need to restore. (also they're more business than individual focused now)