README : documente comment forcer une mise a jour immediate

Trois options (timer, systemctl start nixos-upgrade.service, ou
git pull + rebuild manuel sur place) au lieu d'attendre le prochain
passage hebdomadaire.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
2026-09-12 13:52:54 +02:00
co-authored by Claude Sonnet 5
parent 73c93f3aac
commit 8f99c20ec5
+32 -2
View File
@@ -388,9 +388,39 @@ Vérifier `/dev/sdX` avant de lancer `dd`.
## Mises à jour de la flotte
Chaque PC tire ses mises à jour directement depuis ce repo, chaque semaine.
Chaque PC tire ses mises à jour directement depuis ce repo, chaque semaine (`system.autoUpgrade`, `persistent = true` : se rattrape au boot suivant même si le PC était éteint au moment prévu).
Pas de `git pull` manuel sur les PC. Juste `git push` ici.
Pas de `git pull` manuel sur les PC en fonctionnement normal. Juste `git push` ici.
### Appliquer un changement immédiatement (sans attendre la semaine)
1. Pousser le changement depuis le poste de dev :
```bash
git add -A
git commit -m "description"
git push
```
2. Sur le PC cible, trois options, du plus lent au plus immédiat :
**Rien faire** : le timer hebdomadaire s'en charge tout seul.
**Forcer maintenant, sans y toucher physiquement** (ex. à distance via SSH) : lancer le même service que le timer, il fetch tout seul depuis l'URL du repo, pas besoin que `/etc/nixos` soit à jour :
```bash
sudo systemctl start nixos-upgrade.service
```
**Rebuild manuel sur place** (typique en test, devant la machine) :
```bash
cd /etc/nixos
sudo git pull
sudo nixos-rebuild switch --flake .#usagers
```
Le `git pull` est obligatoire ici : contrairement à `nixos-upgrade.service`, ce rebuild lit les fichiers locaux de `/etc/nixos`, pas l'URL distante.
## Avant la première vague de 100 PC