Installation d’openSUSE Tumbleweed: rolling release sans catastrophes

Ce à quoi vous vous engagez (et pourquoi cela peut être sensé)

Tumbleweed est une distribution rolling. Cela signifie que votre système évolue en continu : noyau, Mesa, systemd, pilotes, toute la pile. Vous ne « mettez pas à niveau de 15.5 à 15.6 ». Vous vous déplacez le long d’un flux d’instantanés testés.

L’avantage est évident : les correctifs de sécurité arrivent vite, le support matériel s’améliore rapidement, et les développeurs n’ont pas à vivre dans un musée. L’inconvénient est aussi évident : le changement est constant, et le changement constant punit les habitudes opérationnelles négligentes.

Donc vous n’installez pas Tumbleweed comme une machine de loisir que vous pouvez réinstaller un week-end pluvieux. Vous l’installez comme un poste qui doit continuer à fonctionner après des mises à jour, survivre à une coupure de courant et se remettre des mauvaises décisions de votre futur vous. La bonne nouvelle : les valeurs par défaut d’openSUSE sont étonnamment alignées avec cet état d’esprit — si vous ne les sabotez pas.

Un principe directeur, paraphrasé d’une idée souvent attribuée à John Allspaw : la fiabilité est une caractéristique de tout le système, y compris les humains qui l’exploitent.

Voici l’accord sur lequel je serai opiniâtre :

• Utilisez Btrfs pour la racine avec des instantanés sauf si vous avez une raison spécifique et répétée de ne pas le faire.
• Gardez /home séparé (soit en sous-volume séparé avec politique d’instantanés différente, soit sur un système de fichiers séparé) si vous tenez à un rollback facile et une utilisation disque raisonnable.
• Préférez l’UEFI. Les installations BIOS héritées fonctionnent, mais UEFI + GRUB2 est la voie avec moins de pièges.
• N’« optimisez » pas la sécurité. Si vous désactivez les instantanés parce que « je n’en ai pas besoin », vous découvrirez que vous en aviez besoin.

Blague #1 : Les rolling releases sont comme des levains — négligez-les une semaine et ils commencent à avoir des opinions.

Faits et historique qui expliquent la personnalité de Tumbleweed

Le contexte compte parce que les distributions sont une culture en code. Quelques faits concrets qui expliquent pourquoi Tumbleweed se comporte comme il le fait :

1. Tumbleweed est devenu la rolling release officielle en 2015, remplaçant la variante communautaire précédente. Ce changement a durci le processus de publication.
2. openQA est central pour Tumbleweed : des tests d’installation et systèmes automatisés filtrent les instantanés. Ce n’est pas magique, mais c’est pourquoi les cassures sont souvent « bizarres en bord de scène » plutôt que « tout est en feu ».
3. zypper a un solveur de dépendances robuste depuis des années, et SUSE a longtemps traité la gestion de paquets comme une préoccupation de production, pas un projet annexe.
4. L’intégration Snapper + Btrfs n’est pas une réflexion après coup. C’est une partie de l’histoire d’installation par défaut, y compris l’intégration au chargeur d’amorçage pour le rollback.
5. YaST porte des décennies d’ADN opérationnel. Que vous aimiez l’interface ou non, il a été construit pour des administrateurs qui ne veulent pas tout éditer à la main à 3h du matin.
6. Tumbleweed suit des « instantanés testés », pas « tout ce qui vient de compiler ». C’est une différence subtile avec certains modèles rolling qui poussent les paquets dès qu’ils compilent.
7. SELinux n’est pas l’histoire MAC principale ici ; AppArmor l’est. Cela influence les schémas de dépannage et les moments « pourquoi ceci est bloqué ? ».
8. La filiation entreprise de SUSE se manifeste dans des endroits ennuyeux : choix par défaut, choix de système de fichiers et outils de mise à niveau. L’ennuyeux est bon quand vous êtes de garde.

Aucun de ces faits ne garantit que vous n’aurez pas de régressions. Ils signifient simplement que le projet met un réel effort pour rendre « rolling » compatible avec « poste de travail dont vous dépendez ».

Décisions de conception qui évitent les désastres

Btrfs pour la racine est une caractéristique de fiabilité, pas un effet de mode

La tradition d’openSUSE « Btrfs pour /, XFS pour /home » n’est pas aléatoire. Le système racine change fréquemment et bénéficie d’instantanés et de rollback. Les répertoires home tournent avec des données volumineuses et personnelles et n’ont pas toujours intérêt à être instantanés à chaque transaction de paquet.

Pour Tumbleweed, l’impact pratique est énorme : si une mise à jour du noyau + pilote grille votre amorçage ou votre interface graphique, vous pouvez redémarrer sur un instantané antérieur et reprendre le travail. Ce n’est pas théorique. C’est mardi.

Snapper n’est efficace que si vous gardez des limites propres

Instantanéiser tout semble sûr jusqu’à ce que vous réalisiez que vous instantanéisez les caches du navigateur et les images VM à chaque installation d’une police. C’est comme ça qu’on remplit les disques en silence. Le schéma sensé est :

• Instantanéiser la racine (OS + configs) fréquemment et automatiquement.
• Garder les chemins volatils ou énormes hors des instantanés (ou sur un autre système de fichiers/sous-volume).
• Gérer /var délibérément : les logs comptent, les caches non.

Rolling signifie que vous opérationnalisez les mises à jour

Une version stable peut survivre à la négligence. Une rolling release punira la négligence en attendant que vous mettiez à jour après trois mois puis en vous livrant une négociation de dépendances entre le vous d’hier et le vous d’aujourd’hui.

Donc : mettez à jour régulièrement, lisez la sortie du solveur, et ne traitez pas les invites de « changement de fournisseur » comme une aventure écrite par un singe du chaos.

Prévol : firmware, disques et choix réseau

Paramètres UEFI qui comptent

Avant de démarrer l’installateur, passez par le setup du firmware. Oui, c’est ennuyeux. C’est aussi là que naissent beaucoup de tickets « Linux est cassé ».

• Mode UEFI : activez-le. Si vous devez utiliser le BIOS hérité, acceptez que vous êtes dans un monde plus étroit et plus étrange.
• Secure Boot : Tumbleweed peut le gérer, mais les modules noyau tiers (notamment NVIDIA) ajoutent de la complexité. Décidez maintenant si vous voulez la propriété de sécurité ou la commodité.
• Mode SATA : passez en AHCI sauf si vous avez une raison (et les pilotes) pour le mode RAID.

Disposition des disques : votre stratégie de rollback commence ici

L’installateur peut créer une disposition par défaut décente. Mais vous devriez comprendre la structure du système que vous créez :

• Partition système EFI (ESP) : petite partition FAT32 montée sur /boot/efi. Conservez-la ; ne soyez pas trop malin.
• / (racine) : Btrfs, avec des sous-volumes que Snapper peut instantanéiser proprement.
• /home : XFS (commun) ou Btrfs avec une politique d’instantanés différente. Si vous utilisez un chiffrement disque complet, la cohérence importe plus que l’idéologie du système de fichiers.
• Swap : pour les portables, envisagez une partition swap si vous voulez la fiabilité de l’hibernation ; sinon un fichier swap suffit généralement.

Réseau : NetworkManager vs wicked

Sur postes de travail et portables : NetworkManager. Sur serveurs avec configuration statique : wicked peut convenir. Le mode d’échec ici est prévisible : choisissez wicked, puis attendez-vous à une expérience Wi‑Fi et VPN comparable à celle d’un OS de bureau. Ce n’est pas le rôle de wicked.

Listes de contrôle / plan pas à pas (avec choix et conséquences)

Étape 0 : Décidez quel type de machine Tumbleweed c’est

• Portable développeur : racine Btrfs + instantanés, /home séparé, NetworkManager, gestion d’énergie agressive, mises à jour fréquentes.
• Station de travail avec GPU : pareil, mais anticipez des frictions avec les pilotes et testez les instantanés avant de grandes présentations.
• Serveur domestique / labo : toujours des instantanés, mais soyez plus strict sur les mises à jour planifiées et les fenêtres de redémarrage.

Étape 1 : Installer avec les bons paramètres de système de fichiers

Dans le partitionnement de l’installateur :

• Conserver ou créer l’ESP (FAT32) montée sur /boot/efi.
• Mettre / en Btrfs avec sous-volumes activés (le mode guidé par défaut le fait généralement).
• Placer /home sur XFS ou sur un sous-volume Btrfs séparé avec instantanés désactivés ou limités.

Point de décision : Si le rollback ne vous intéresse pas, vous pouvez choisir ext4 partout. Si vous faites cela sur Tumbleweed, vous choisissez de déboguer avec votre visage au lieu d’utiliser des instantanés.

Étape 2 : Choisissez l’environnement de bureau comme vous choisiriez une rotation d’astreinte

• KDE Plasma : soigné, riche en fonctionnalités, excellent pour les utilisateurs avancés, un peu plus de pièces mobiles.
• GNOME : cohérent, forte intégration Wayland, UX très cadrée.
• Minimal + votre choix : bien si vous savez ce que vous faites et aimez vous bricoler vos propres petites blessures quotidiennes.

Étape 3 : Activez les instantanés et rendez-les amorçables

Sur openSUSE, Snapper et l’intégration GRUB sont généralement configurés. Mais « généralement » n’est pas un SLA. Après l’installation, vérifiez-le (commandes ci‑dessous).

Étape 4 : Décidez de votre cadence de mises à jour

• Mises à jour quotidiennes/hebdomadaires : meilleure expérience, diffs plus petits, moins de douleur pour le solveur.
• Mises à jour mensuelles : attendez-vous à des changements plus importants et plus de décisions de « changement de fournisseur ».

Choisissez une cadence que vous pouvez réellement tenir. Une rolling release ne pardonne pas l’illusion.

Tâches pratiques : commandes, sorties attendues et quoi faire ensuite

Voici les vérifications de base que j’exécute sur une nouvelle installation Tumbleweed ou après que quelque chose sente le brûlé. Chaque tâche inclut : commande, ce que signifie la sortie, et la décision à prendre.

Task 1: Confirm you booted in UEFI mode

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo BIOS
UEFI

Signification : « UEFI » signifie que le noyau voit l’environnement d’exécution EFI.

Décision : Si vous attendiez UEFI mais voyez « BIOS », corrigez le mode de démarrage du firmware maintenant — avant de déboguer GRUB dans le mauvais univers.

Task 2: Check current kernel and basic platform

cr0x@server:~$ uname -a
Linux server 6.7.9-1-default #1 SMP PREEMPT_DYNAMIC ... x86_64 GNU/Linux

Signification : Confirme la version et la variante du noyau. Sur Tumbleweed, les versions de noyau évoluent vite.

Décision : Si vous diagnosez une régression, notez le noyau. C’est souvent le facteur différenciant.

Task 3: Validate Btrfs on root and mount options

cr0x@server:~$ findmnt -no FSTYPE,OPTIONS /
btrfs rw,relatime,ssd,space_cache=v2,subvolid=258,subvol=/@/.snapshots/1/snapshot

Signification : La racine est en Btrfs ; le chemin du sous-volume montre que vous êtes dans une racine dérivée d’un instantané (normal pour openSUSE).

Décision : Si la racine est ext4 et que vous attendiez des instantanés Btrfs, décidez de réinstaller ou d’accepter la perte du rollback. La rétro‑adaptation est possible mais pénible.

Task 4: List Btrfs subvolumes to confirm layout

cr0x@server:~$ sudo btrfs subvolume list /
ID 256 gen 123 top level 5 path @
ID 257 gen 123 top level 5 path @/var
ID 258 gen 124 top level 5 path @/.snapshots
ID 259 gen 123 top level 5 path @/usr/local
ID 260 gen 123 top level 5 path @/tmp

Signification : Cela montre des sous-volumes séparés. openSUSE utilise cela pour contrôler ce qui est instantanéisé et comment.

Décision : Si vous voyez tout sous un seul sous-volume, Snapper va instantanéiser trop de choses. Envisagez de réinstaller avec le partitionnement guidé ou ajustez les sous-volumes avant d’accumuler des données.

Task 5: Verify Snapper configs exist and are active

cr0x@server:~$ sudo snapper list-configs
Config | Subvolume
-------+----------------
root   | /
home   | /home

Signification : Snapper est configuré au moins pour la racine (et peut-être pour /home).

Décision : S’il n’y a pas de configuration root, corrigez Snapper avant de faire confiance au rollback. Pas d’instantanés, pas de parachute.

Task 6: Confirm automatic snapshots around package operations

cr0x@server:~$ systemctl status snapper-timeline.timer --no-pager
● snapper-timeline.timer - Timeline of Snapper Snapshots
     Loaded: loaded (/usr/lib/systemd/system/snapper-timeline.timer; enabled)
     Active: active (waiting) since ...

Signification : Les instantanés de timeline sont activés (périodiques). Les instantanés liés aux paquets proviennent des plugins zypper ; les timers gèrent la rétention basée sur le temps.

Décision : Si les timers sont désactivés et que vous voulez de la sécurité, activez-les. Si le disque est petit, conservez-les mais ajustez la rétention.

Task 7: Inspect repositories and their priorities

cr0x@server:~$ zypper lr -P
#  | Alias                   | Name               | Enabled | GPG Check | Refresh | Priority
---+-------------------------+--------------------+---------+-----------+---------+---------
1  | repo-oss                | openSUSE OSS       | Yes     | (r ) Yes  | Yes     |   99
2  | repo-non-oss            | openSUSE Non-OSS   | Yes     | (r ) Yes  | Yes     |   99
3  | repo-update             | openSUSE Update    | Yes     | (r ) Yes  | Yes     |   99

Signification : Vous voyez quels dépôts existent, s’ils se rafraîchissent, et lequel l’emporte en cas de conflit de versions.

Décision : Si vous avez ajouté des dépôts tiers, assurez-vous de comprendre qui « possède » les paquets. Des priorités aléatoires sont comment on construit un système Franken.

Task 8: Run a safe “what would upgrade do?” simulation

cr0x@server:~$ sudo zypper dup --dry-run
Loading repository data...
Reading installed packages...
Computing distribution upgrade...

The following 12 packages are going to be upgraded:
  kernel-default systemd Mesa-libGL1 ...

Overall download size: 180.5 MiB.

Signification : Cela montre l’étendue. Cela révèle aussi les changements de fournisseur ou suppressions avant de vous engager.

Décision : Si le solveur propose des suppressions que vous ne comprenez pas (surtout la pile GPU, le bureau ou le réseau), arrêtez et enquêtez avant d’exécuter un véritable dup.

Task 9: Identify vendor change proposals before you accept them

cr0x@server:~$ sudo zypper dup
...
The following package is going to change vendor:
  libfoo  openSUSE -> obs://build.some.repo
Continue? [y/n/v/...? shows all options] (y):

Signification : Un dépôt tiers veut remplacer une bibliothèque ou un composant central.

Décision : Par défaut, répondez non sauf si vous avez intentionnellement installé ce dépôt pour cet ensemble de paquets. La dérive de fournisseur est une cause fréquente de spirales de mise à jour.

Task 10: Check GRUB snapshot entries exist

cr0x@server:~$ sudo grep -R "openSUSE snapshots" -n /boot/grub2/grub.cfg | head
1023:menuentry 'openSUSE snapshots' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-snapshots' {

Signification : GRUB est configuré pour afficher des entrées d’amorçage par instantané.

Décision : Si elles sont absentes, le rollback au démarrage devient plus difficile. Corrigez l’intégration GRUB/Snapper avant d’en avoir besoin, pas pendant une panne.

Task 11: Confirm ESP is mounted and not full

cr0x@server:~$ findmnt /boot/efi
TARGET    SOURCE     FSTYPE OPTIONS
/boot/efi /dev/nvme0n1p1 vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro

cr0x@server:~$ df -h /boot/efi
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1  512M  120M  392M  24% /boot/efi

Signification : L’ESP est présente, montée et a de l’espace.

Décision : Si l’ESP est pleine, les installations de noyau et les mises à jour du chargeur d’amorçage peuvent échouer de façons déroutantes. Nettoyez les anciennes entrées EFI si nécessaire, mais ne supprimez rien à l’aveugle.

Task 12: Check disk health signs and IO scheduler hints

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL
nvme0n1    disk  953.9G              Samsung SSD 980
├─nvme0n1p1 part    512M vfat   /boot/efi
├─nvme0n1p2 part      2G swap   [SWAP]
└─nvme0n1p3 part  951.4G btrfs  / /home

Signification : Confirme ce qui est où. Vous seriez surpris de voir à quel point « ma racine est pleine » signifie en réalité « mon home est sur la racine ».

Décision : Si vous vouliez des systèmes de fichiers séparés et que vous ne les voyez pas, corrigez cela tôt avant que les données n’augmentent.

Task 13: Audit memory pressure and swap usage

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       9.2Gi       4.1Gi       1.1Gi        18Gi        21Gi
Swap:          2.0Gi          0B       2.0Gi

Signification : « available » est le chiffre clé pour « le système va-t-il commencer à swapper bientôt ? »

Décision : Si le swap est fortement utilisé durant le travail normal, le goulot est probablement la mémoire (ou un processus incontrôlé), pas « Linux est lent ».

Task 14: Check boot performance and recent failures

cr0x@server:~$ systemd-analyze time
Startup finished in 3.112s (kernel) + 8.904s (userspace) = 12.016s
graphical.target reached after 8.701s in userspace.

cr0x@server:~$ systemctl --failed
  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
● ModemManager.service          loaded failed failed Modem Manager

Signification : systemctl --failed montre ce qui est activement cassé. Ne pas ignorer les défaillances ; elles sont souvent le système d’alerte précoce.

Décision : Si un service est en échec et que vous n’en avez pas besoin, désactivez-le. Si vous en avez besoin, réparez-le maintenant — les services en échec deviennent souvent « pourquoi le VPN est instable ? » plus tard.

Task 15: Read logs like you mean it

cr0x@server:~$ sudo journalctl -p err -b --no-pager | tail -n 20
Feb 05 09:13:02 server kernel: nouveau 0000:01:00.0: firmware: failed to load nouveau/...
Feb 05 09:13:05 server systemd[1]: Failed to start Modem Manager.

Signification : Erreurs du démarrage courant, filtrées sur « err ». C’est une façon rapide de voir la cause réelle derrière des symptômes.

Décision : Si vous voyez des erreurs de firmware/pilote après une mise à jour, envisagez un rollback avant de commencer à réinstaller des paquets au hasard.

Mises à niveau comme un SRE : zypper dup sans drame

Les mises à niveau Tumbleweed ne se font pas avec zypper up. Le modèle mental supporté est une mise à niveau de distribution : zypper dup. C’est ainsi que vous restez aligné sur l’ensemble d’instantanés testés.

Le workflow qui vous évite les ennuis

1. Rafraîchissez les dépôts (et assurez-vous de leur fiabilité).
2. Faites un dry-run pour comprendre le changement.
3. Mettez à jour avec attention, pas en pilote automatique.
4. Redémarrez lorsque des composants centraux changent (noyau, systemd, Mesa, glibc). Oui, même sur une station de travail.

Commandes concrètes : rafraîchir, inspecter, mettre à niveau

cr0x@server:~$ sudo zypper refresh
Repository 'openSUSE OSS' is up to date.
Repository 'openSUSE Non-OSS' is up to date.
Repository 'openSUSE Update' is up to date.

Signification : Les métadonnées sont à jour. Si le rafraîchissement échoue, vous dépannez peut-être le réseau ou des miroirs, pas les paquets.

cr0x@server:~$ sudo zypper dup --details
...
Overall download size: 480.2 MiB. After the operation, additional 52.0 MiB will be used.

Signification : Le delta disque « après l’opération » est votre alerte précoce pour de petites racines.

Décision : Si la racine a < 5–10 GiB libres et que vous téléchargez de grosses mises à jour, purgez d’abord les instantanés et caches. N’attendez pas un « disque plein » en plein milieu de la transaction.

Quand le solveur propose des suppressions

Les suppressions ne sont pas automatiquement mauvaises. Elles sont automatiquement suspectes.

• Si il veut supprimer un méta-paquet de bureau, vous allez passer une mauvaise journée.
• Si il veut supprimer une bibliothèque obsolète que vous n’utilisez pas, ça va.
• Si il veut supprimer votre pile de pilotes GPU, arrêtez et comprenez pourquoi.

Blague #2 : Le solveur de dépendances est comme un avocat — si vous ne lisez pas les petites lignes, il vous laissera signer la perte de votre environnement de bureau.

Instantanés, rollback et comment ne pas les saboter

Comprenez ce que fait réellement le rollback

Le rollback sur openSUSE avec Btrfs/Snapper signifie généralement : démarrer sur un instantané antérieur du système racine. C’est puissant parce que cela remet les binaires système et les configs à un état antérieur. Ce n’est pas une machine à remonter le temps pour tout.

Choses qui peuvent ne pas revenir proprement à moins d’être conçues pour :

• Les données dans /home si elles sont sur un système de fichiers séparé ou exclues des instantanés.
• Les bases de données ou services avec état dans /var si vous les instantanéisez mais ne gérez pas la cohérence.
• Le firmware stocké en dehors du système racine, selon le matériel.

Comment utiliser les instantanés en toute sécurité en exploitation

Pour un poste de travail, voici la démarche :

1. Exécutez zypper dup.
2. Redémarrez rapidement si le noyau/graphisme/systemd a changé.
3. Si le démarrage échoue ou que le graphisme est cassé, redémarrez sur un instantané précédent via GRUB.
4. Depuis l’instantané fonctionnel, évaluez : attendez un nouvel instantané, ajustez les dépôts, ou épinglez/remplacez les pilotes.

N’accumulez pas les instantanés indéfiniment

Les instantanés coûtent de l’espace. Sur Btrfs, le coût est incrémental — jusqu’au moment où il ne l’est plus. Les gros changements, images VM, conteneurs et la turbulence des caches de navigateur peuvent faire exploser les deltas d’instantanés.

cr0x@server:~$ sudo snapper list | tail
  90  | single |       |         | root | 2026-02-01 09:00:01 |      | number cleanup
  91  | pre    |  5123 | zypp(zypper) | root | 2026-02-03 18:41:22 |      | zypp pre
  92  | post   |  5123 | zypp(zypper) | root | 2026-02-03 18:45:10 |      | zypp post

Signification : Vous voyez des instantanés de timeline (« single ») et des instantanés de transaction de paquet (« pre/post »).

Décision : Si vous en avez des centaines, la rétention est peut‑être trop généreuse pour votre disque. Ajustez le nettoyage Snapper, ne supprimez pas simplement des instantanés au hasard.

cr0x@server:~$ sudo btrfs filesystem df /
Data, single: total=120.00GiB, used=92.15GiB
Metadata, DUP: total=8.00GiB, used=6.90GiB
System, DUP: total=32.00MiB, used=16.00MiB

Signification : Btrfs rapporte alloué vs utilisé. « Used » est la consommation réelle ; « total » est les chunks alloués.

Décision : Si le Metadata est presque plein, vous pouvez rencontrer ENOSPC alors qu’il y a beaucoup de « Data » libre. C’est une surprise classique de Btrfs — résolvez-la en libérant de l’espace et en lançant un balance si nécessaire, pas en réinstallant par panique.

Fiche de diagnostic rapide : quoi vérifier en premier/deuxième/troisième

Quand Tumbleweed « semble cassé », la panne peut venir de l’état des paquets, du chargeur d’amorçage, de la pression sur le système de fichiers, de la pile GPU, ou du bon vieux DNS. Voici comment arrêter de deviner.

Premier : Démarre‑t‑il dans l’environnement attendu ?

• Mode de démarrage : UEFI ou BIOS ? (Task 1)
• Version du noyau : a‑t‑elle changé récemment ? (Task 2)
• La dernière mise à jour s’est-elle terminée ? Vérifiez l’historique zypper et les services en cours d’exécution.

cr0x@server:~$ sudo tail -n 30 /var/log/zypp/history
2026-02-03 18:41:22|install|kernel-default|6.7.9-1.1|x86_64|repo-oss|...
2026-02-03 18:45:10|remove |kernel-default|6.7.8-1.1|x86_64|@System|...

Décision : Si les mises à jour sont à moitié faites ou interrompues, ne redémarrez pas en espérant que ça se corrige. Terminez la mise à jour ou faites un rollback.

Second : Le goulot est‑il CPU, mémoire, disque ou réseau ?

• Saturation CPU : charge élevée avec faible IO wait suggère lié au CPU.
• Pression mémoire : usage du swap et faible « available » suggèrent un manque de mémoire.
• Pression disque : ENOSPC Btrfs et métadonnées pleines créent des illusions « tout est lent ».
• Réseau/DNS : les échecs de rafraîchissement des dépôts et « le web est lent » signifient souvent DNS.

cr0x@server:~$ uptime
 09:22:11 up 3 days,  1:02,  2 users,  load average: 0.42, 0.55, 0.60

Décision : Les charges moyennes < 1 sur un système multi-cœur ne sont généralement pas votre problème. Cherchez ailleurs.

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 4200000 120000 18000000  0    0    12    28  410  900  3  1 95  1  0

Signification : wa est l’IO wait ; si/so montre l’activité de swap. Un wa élevé pointe vers le stockage ; un so élevé pointe vers la pression mémoire.

Décision : Si wa est élevé, vérifiez le disque et le système de fichiers. Si le swap est actif, cessez d’accuser le GPU.

Troisième : Un service unique échoue‑t‑il bruyamment ?

cr0x@server:~$ systemctl --failed
UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
● display-manager.service loaded failed failed X Display Manager

Décision : Un gestionnaire d’affichage en échec après une mise à jour hurle « problème de pile graphique ». Faites un rollback ou repassez à une combinaison noyau/driver connue bonne avant de commencer à éditer des configs au hasard.

Puis : Confirmez la pile graphique (douleur commune sur postes de travail)

cr0x@server:~$ loginctl show-session "$(loginctl | awk 'NR==2{print $1}')" -p Type
Type=wayland

Signification : Wayland vs X11 affecte le comportement des pilotes et les étapes de dépannage.

Décision : Si vous êtes sur NVIDIA et que Wayland est instable après une mise à jour, testez X11 (ou un instantané précédent) pour bisecter si c’est le compositeur/le pilote/le noyau.

Erreurs courantes : symptôme → cause racine → correctif

1) « Après la mise à jour, l’écran reste noir »

Symptôme : Le système démarre, mais le gestionnaire d’affichage n’apparaît jamais ; peut‑être un curseur clignotant.

Cause racine : Incompatibilité noyau/pilote (souvent NVIDIA), initramfs cassé, ou gestionnaire d’affichage qui échoue à cause de changements dans la pile graphique.

Correctif : Démarrez sur un instantané antérieur depuis GRUB. Confirmez avec systemctl --failed et journalctl -p err -b. Si c’est NVIDIA, alignez les paquets du pilote avec le noyau en cours d’exécution, et envisagez de retarder les mises à jour jusqu’à ce que le dépôt du pilote rattrape le noyau.

2) « zypper dup veut supprimer la moitié de mon bureau »

Symptôme : Le solveur propose de supprimer des patterns Plasma/GNOME ou des bibliothèques clés.

Cause racine : Dépôts tiers avec paquets conflictuels, changements de fournisseur, ou mises à jour partielles dues au mélange de up et dup au fil du temps.

Correctif : Stoppez. Inspectez les dépôts (zypper lr -P). Préférez les dépôts officiels. Si vous devez utiliser des dépôts tiers, gardez-les minimaux et comprenez les changements de fournisseur. Exécutez zypper dup --dry-run jusqu’à ce que le plan ait du sens.

3) « Mon disque est “plein” mais df montre de l’espace »

Symptôme : Les écritures échouent, les installations de paquets échouent, mais df -h indique de l’espace libre.

Cause racine : Épuisement des métadonnées Btrfs ou problèmes d’allocation de chunks.

Correctif : Vérifiez btrfs filesystem df / et btrfs filesystem usage /. Libérez de l’espace en purgeant des instantanés et caches ; envisagez un balance si vous savez ce que vous faites. Ne lancez pas des « commandes magiques btrfs » au hasard à 2h du matin.

4) « Le rollback n’a pas réparé mes données d’application »

Symptôme : Vous avez rollbacké, mais votre dossier projet/config dans home est toujours « cassé ».

Cause racine : /home ne fait pas partie des instantanés racine (par conception), ou les données pertinentes résident en dehors des chemins instantanéisés.

Correctif : Décidez ce que vous voulez que le rollback couvre. Pour des configs critiques, gardez-les dans des emplacements gérés par la racine ou utilisez une stratégie de dotfiles avec contrôle de version. Pour les bases de données, utilisez de véritables sauvegardes et des instantanés conscients des services.

5) « Le réseau ne revient pas après la mise en veille »

Symptôme : Reconnextion Wi‑Fi instable ; VPN ne revient qu’après reboot.

Cause racine : Choix inadapté de la pile réseau (wicked sur portable), particularités de gestion d’énergie, ou régression de pilote.

Correctif : Utilisez NetworkManager sur les portables. Vérifiez les logs de NetworkManager et les messages du pilote Wi‑Fi noyau. Si régression, démarrez sur un noyau ou un instantané précédent et attendez un instantané corrigé.

6) « Secure Boot a cassé mon module noyau tiers »

Symptôme : Après activation de Secure Boot, les modules NVIDIA/VirtualBox ne se chargent plus.

Cause racine : Exigences de signature des modules. Les modules non signés ne se chargeront pas sous Secure Boot sans enrollment MOK/signature.

Correctif : Utilisez des modules signés depuis des dépôts de confiance qui prennent en charge le workflow Secure Boot, enregistrez une clé et signez les modules, ou acceptez de désactiver Secure Boot. Choisissez une voie ; les demi-mesures gaspillent des après‑midis.

Trois mini-récits d’entreprise (parce que vous reconnaîtrez ces personnes)

Incident #1 : La panne causée par une mauvaise hypothèse

Une organisation d’ingénierie de taille moyenne a déployé Tumbleweed sur des postes développeur parce que le support matériel importait : nouveaux portables, nouveaux GPU, beaucoup d’écrans externes. Le pilote s’est bien passé. Puis ils ont rapidement étendu le déploiement, parce que l’équipe pilote était bruyante et persuasive — toujours une combinaison dangereuse.

Ils ont supposé que rollback signifiait « tout revient ». Ils ont donc laissé les équipes garder d’énormes arbres de projet sous /home sur un système de fichiers séparé, et ils ont dit à tout le monde : « Si une mise à jour casse quelque chose, faites un rollback. » C’est vrai pour l’OS. Ce n’est pas vrai pour le bazar à état vivant dans les home.

L’incident : une mise à jour a changé un composant de chaîne d’outils, et plusieurs équipes ont reconstruit des caches locaux et des artefacts intermédiaires. Quand une régression a été découverte, ils ont rollbacké l’instantané OS. Les caches dans /home sont restés « nouveaux ». Certaines builds ont alors utilisé d’anciens binaires avec des caches plus récents, produisant des échecs étranges et intermittents.

La panne n’était pas une explosion unique. C’était pire : une incohérence de bas niveau. Les ingénieurs ont perdu des jours à chasser des bugs fantômes.

La correction n’a pas été héroïque. Ils ont tracé une frontière. Les toolchains et caches de build critiques ont été déplacés vers des emplacements contrôlés avec nettoyage explicite au rollback, et ils ont documenté que le rollback restaure l’OS, pas votre ensemble de travail. Ils ont aussi ajouté un script d’« hygiène post-rollback » pour vider les caches connus pour causer des corruptions inter-versions. La leçon : les hypothèses sont l’option de configuration la plus coûteuse.

Incident #2 : Une optimisation qui s’est retournée contre eux

Une autre entreprise s’est standardisée sur une racine Btrfs avec instantanés — bien. Puis quelqu’un a remarqué que l’utilisation disque grimpait sur des portables 256 Go, et a décidé que la solution était d’« optimiser le stockage ». Leur plan : désactiver agressivement les instantanés timeline, réduire les instantanés zypp, et exclure plus de chemins des instantanés. Sur le papier, cela réduisait la churn.

Pendant quelques mois, tout allait bien. Moins d’instantanés. Plus d’espace libre. Tout le monde se félicitait d’être discipliné plutôt que « hoarders d’instantanés ».

Puis est arrivée une régression graphique qui affectait un modèle de portable spécifique. La bonne réponse aurait été : démarrer sur le dernier instantané connu bon et continuer à travailler pendant que la correction arrive. Mais ces systèmes avaient presque plus d’instantanés — juste quelques-uns issus de transactions récentes, et la fenêtre de rétention avait déjà supprimé l’état bon.

Résultat : reconstructions d’urgence, épinglage manuel de paquets, et beaucoup de questions « pourquoi le rollback ne nous a-t-il pas sauvés ? » dans des réunions où personne ne voulait admettre la réponse.

La solution finale a été ennuyeuse et légèrement humiliante : restaurer une rétention d’instantanés sensée, déplacer les grosses données non-OS hors de la racine instantanéisée, et implémenter une surveillance disque pour accorder la rétention sur des usages réels plutôt que sur des impressions. Optimiser la sécurité est juste une dette de risque avec une meilleure posture.

Incident #3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une organisation réglementée utilisait Tumbleweed pour une petite flotte de postes d’ingénierie — oui, vraiment. Ils l’ont fait parce qu’ils avaient besoin de noyaux modernes pour des interfaces matérielles spécifiques et que leurs ingénieurs étaient allergiques aux toolchains anciennes. L’équipe conformité a accepté à une condition : les mises à jour doivent être étagées et réversibles.

Ainsi l’équipe ops a fait quelque chose d’impopulaire : elles ont créé une cadence simple. Une fois par semaine, un petit groupe canari mettait à jour en premier. Ils redémarraient. Ils exécutaient un script de test court qui validait le VPN, l’authentification par carte à puce, et quelques applications internes. Ce n’est qu’ensuite que le reste de la flotte mettait à jour.

Un week-end, les canaris ont rencontré une régression dans un composant de la pile réseau. Le VPN échouait d’une manière qui ressemble à « peut-être le concentrateur VPN est down ». Le script de test a prouvé que non. Les canaris ont rollbacké sur l’instantané précédent en quelques minutes et sont restés productifs.

Parce que la régression a été détectée avant le déploiement large, l’organisation a évité un lundi matin où la moitié du département d’ingénierie ne pouvait pas s’authentifier. Pas d’héroïsme, pas de salle de crise nocturne. Juste une petite porte et un plan de rollback qu’ils avaient répété.

La pratique n’était pas excitante. C’est pour cela qu’elle a marché.

FAQ

1) Dois‑je utiliser Tumbleweed pour un serveur de production ?

Vous pouvez, mais il faut de la discipline : dépôts contrôlés, mises à jour étagées, fenêtres de maintenance et plan de rollback. Si vous voulez « installer et oublier », choisissez une branche stable à la place.

2) Pourquoi tout le monde dit « utilisez zypper dup » au lieu de « zypper up » ?

dup aligne votre système sur l’instantané de distribution courant, gérant correctement les changements de fournisseur et les transitions. up convient dans certains cas, mais sur Tumbleweed ce n’est pas le bon défaut car il peut vous laisser dans un état partiel avec le temps.

3) Dois‑je vraiment redémarrer après les mises à jour ?

Si le noyau, systemd, Mesa ou des bibliothèques centrales ont changé : oui. Vous pouvez bricoler sans redémarrer, mais vous exécuterez un mix de processus anciens et de fichiers nouveaux. C’est comme ça que naissent les bugs « ça ne casse qu’au bout de deux jours ».

4) Btrfs me fait peur. ext4 ça va ?

ext4 est techniquement correct. Opérationnellement, vous renoncez au rollback de première classe et à une récupération facile après de mauvaises mises à jour. Si vous utilisez Tumbleweed, Btrfs pour la racine est le choix pragmatique.

5) /home sur Btrfs ou XFS ?

XFS est solide pour de grands home et évite la churn des instantanés. Btrfs pour /home est possible si vous ajustez la politique d’instantanés et n’instantanéisez pas par erreur des téraoctets d’images VM à chaque installation de pilote.

6) Comment savoir quel instantané choisir pour rollback ?

Choisissez l’instantané juste avant la transaction qui a introduit le problème (généralement une paire zypp pre/post). Utilisez la date et la description de snapper list, puis démarrez‑le depuis les instantanés GRUB.

7) Secure Boot en vaut‑il la peine sur Tumbleweed ?

Pour beaucoup de portables : oui, si vous valorisez le modèle de menace qu’il adresse. Si vous dépendez de modules noyau tiers, prévoyez la signature des modules ou acceptez la friction supplémentaire. N’activez pas Secure Boot à la légère puis ne soyez pas surpris que des modules non signés ne se chargent pas.

8) NetworkManager ou wicked ?

NetworkManager pour portables et postes de travail. wicked pour serveurs où vous voulez une configuration stable et déclarative et où l’UX de roaming Wi‑Fi ne compte pas.

9) Comment éviter que mon système devienne un bazar de dépôts ?

Gardez les dépôts tiers minimaux et intentionnels. Évitez de mélanger plusieurs dépôts qui fournissent des composants centraux qui se chevauchent. Si vous avez besoin d’un paquet spécial, demandez-vous si installer un seul paquet n’est pas mieux que d’activer un dépôt entier qui remplace des bibliothèques.

10) Quelle est la commande de dépannage la plus utile sur Tumbleweed ?

journalctl -p err -b. Si vous n’avez le temps que pour une seule chose, lisez les erreurs du démarrage courant et arrêtez de deviner.

Étapes suivantes que vous devriez réellement faire

Installer Tumbleweed est la partie facile. Le garder stable est une routine — courte, répétable et légèrement ennuyeuse. C’est le but.

Étapes immédiates (aujourd’hui)

• Vérifiez le démarrage UEFI, le montage de l’ESP et la disposition des sous-volumes Btrfs (Tasks 1, 4, 11).
• Confirmez que Snapper est configuré et que les timers sont activés (Tasks 5, 6).
• Exécutez zypper dup --dry-run et familiarisez-vous avec la planification (Task 8).
• Apprenez à démarrer un instantané depuis GRUB avant d’en avoir besoin.

Étapes opérationnelles (cette semaine)

• Choisissez une cadence de mises à jour que vous pouvez maintenir (hebdomadaire est un bon défaut).
• Décidez de votre position sur Secure Boot et tenez‑y vous.
• Si vous utilisez des dépôts tiers, documentez pourquoi chacun existe et quels paquets il fournit.
• Faites une répétition de rollback : mettez à jour quelque chose de petit, puis entraînez‑vous à identifier et démarrer un instantané antérieur. La répétition est peu coûteuse ; la surprise est chère.

Tumbleweed ne vous garantit pas une vie sans drame. Mais installé avec la bonne disposition de système de fichiers, des instantanés et un workflow de mise à jour adulte, c’est l’une des rares rolling releases qui peut être à la fois moderne et fiable. Vous n’avez pas besoin de chance. Vous avez besoin de garde-fous — et de l’humilité pour les maintenir.