280 lines
14 KiB
Markdown
280 lines
14 KiB
Markdown
# Réinstallation d’ArchASP — procédure conditionnelle
|
||
|
||
Cette procédure est un **parcours sur papier** : aucun SSD neuf, premier
|
||
redémarrage, retour de snapshot ou restauration externe n’a été essayé dans ce
|
||
lot. Lire la [référence de reconstruction](reconstruction-baseline.md) et le
|
||
[bilan de finalisation](audits/2026-10-02-finalisation.md). Les commandes
|
||
marquées « live » s’exécutent depuis un support Arch UEFI vérifié ; celles
|
||
marquées « chroot » dans `arch-chroot /mnt` ; celles marquées « utilisateur »
|
||
après le premier démarrage. **Arrêter à chaque contrôle manquant**. Ne jamais
|
||
copier les exemples en bloc.
|
||
|
||
## 1. Copies et moyens de retour — avant de toucher au SSD
|
||
|
||
**Contexte : poste actuel, utilisateur.** Obtenir une copie indépendante du SSD
|
||
à remplacer de `arch-system`, des dotfiles séparés et des données personnelles,
|
||
dont Trainlog. Conserver les moyens de récupération de clés, réseau et Secure
|
||
Boot hors Git public. Pour chaque copie noter : support, date, empreinte et un
|
||
fichier récupéré lors d’un essai. Un remote déclaré, un export privé de
|
||
`backup.sh` et un snapshot sur le même SSD ne sont pas des restaurations
|
||
testées. **Arrêt** si l’un de ces accès est absent ; les sauvegardes ne sont pas
|
||
réalisées par cette procédure.
|
||
|
||
## 2. Support live et cible — live, avant toute mutation
|
||
|
||
Démarrer le support Arch en UEFI et vérifier `test -d /sys/firmware/efi`.
|
||
Contrôler le réseau de secours et l’accès aux copies indépendantes sans
|
||
publier de secrets. Installer sur le support live uniquement les dépendances
|
||
manquantes **après choix explicite de l’opérateur** ; la présente mission n’en
|
||
a installé aucune. Le script exige Bash, Python 3, `lsblk`, `findmnt`,
|
||
`swapon`, `readlink`, `wipefs`, `parted`, `partprobe`, `udevadm`, `mkfs.fat`,
|
||
`mkfs.btrfs`, `btrfs`, `mount` et `umount`. La suite demande aussi `pacstrap`,
|
||
`genfstab`, `arch-chroot` et Neovim. Vérifier leur présence et leur version
|
||
sur le support réellement démarré ; arrêter si l’éditeur ou un outil requis
|
||
manque.
|
||
|
||
Identifier manuellement la cible, le support live, le dépôt et les sauvegardes :
|
||
|
||
```bash
|
||
lsblk -e7 -o PATH,TYPE,MAJ:MIN,SIZE,MODEL,SERIAL,WWN,FSTYPE,MOUNTPOINTS
|
||
findmnt -o SOURCE,TARGET,FSTYPE
|
||
swapon --show
|
||
```
|
||
|
||
Aucun disque par défaut n’est fourni. Renseigner une variable dans **ce shell**
|
||
après recoupement de l’identité physique ; un nom `/dev/nvme*` seul ne suffit
|
||
pas :
|
||
|
||
```bash
|
||
: "${DISK:?Renseigner le disque entier confirmé avant toute suite}"
|
||
./scripts/prepare-disk.sh --dry-run "$DISK"
|
||
```
|
||
|
||
Le mode simulation n’écrit rien, ne confirme rien et ne prouve pas qu’un
|
||
contrôle privilégié inaccessible a réussi. Un overlay live n’est admis que si
|
||
son support physique apparaît séparément sous `/run/archiso/bootmnt`, reste
|
||
distinct de la cible et que chaque couche déclarée renvoie à ce support ou
|
||
à un `tmpfs` ; les overlays non attribuables et les Btrfs
|
||
multi-périphériques ambigus sont refusés. Dans ce cas **arrêt et revue de la
|
||
provenance du support**, pas de contournement. Examiner `/mnt`, les montages,
|
||
swaps et holders. Ne pas démonter ou désactiver une utilisation pour faire
|
||
passer le contrôle.
|
||
|
||
## 3. Préparation — live, destructive et humaine
|
||
|
||
Après les copies vérifiées et une seconde lecture de l’identité affichée :
|
||
|
||
```bash
|
||
: "${DISK:?Cible obligatoire}"
|
||
./scripts/prepare-disk.sh "$DISK"
|
||
```
|
||
|
||
Le script exige root dans un contexte live Arch UEFI, un verrou coopératif et
|
||
la saisie exacte `ERASE <chemin-canonique> <major:minor>`. Il revérifie la cible
|
||
avant `wipefs`. Résultat attendu : GPT, ESP FAT32 d’environ 1 Gio montée sur
|
||
`/mnt/boot`, Btrfs pour le reste et montages `@`, `@home`, `@log`, `@pkg`,
|
||
`@/.snapshots`. Vérifier les chemins réels avec `findmnt -R /mnt` et
|
||
`lsblk -f "$DISK"`. **Arrêt** si une étape échoue : le partitionnement est
|
||
irréversible, non transactionnel ; la dernière commande peut avoir eu un
|
||
effet même avec code non nul. Lire le bilan des étapes et les montages restants,
|
||
inspecter manuellement, ne jamais relancer aveuglément.
|
||
|
||
## 4. Socle officiel — live, après montages vérifiés
|
||
|
||
Vérifier la disponibilité des paquets sur le miroir configuré et le processeur
|
||
avant `pacstrap`. Pour la variante AMD observée, le socle proposé est :
|
||
|
||
```bash
|
||
pacman -Si base linux-lts linux-firmware amd-ucode btrfs-progs dosfstools \
|
||
networkmanager git sudo neovim limine mkinitcpio efibootmgr
|
||
pacstrap -K /mnt base linux-lts linux-firmware amd-ucode btrfs-progs \
|
||
dosfstools networkmanager git sudo neovim limine mkinitcpio efibootmgr
|
||
```
|
||
|
||
Pour un autre CPU, choisir le microcode correspondant et revalider la ligne.
|
||
Le noyau, l’initramfs, l’ESP, Limine et le réseau minimal doivent suffire au
|
||
premier démarrage sans `yay` ni liste AUR historique. **Arrêt** si un paquet
|
||
ou la signature du miroir n’est pas disponible ; ne pas substituer au hasard.
|
||
|
||
## 5. `fstab` — live, depuis les montages réels
|
||
|
||
Générer d’abord un candidat, le relire puis **remplacer** un nouveau fichier,
|
||
jamais `>>` sur un `fstab` existant :
|
||
|
||
```bash
|
||
genfstab -U /mnt > /mnt/etc/fstab.candidate
|
||
nvim /mnt/etc/fstab.candidate
|
||
findmnt -R /mnt
|
||
```
|
||
|
||
Vérifier une seule entrée pour `/`, `/home`, `/var/log`,
|
||
`/var/cache/pacman/pkg`, `/.snapshots` et `/boot`, leurs UUID et options.
|
||
Si `/mnt/etc/fstab` existe déjà, ouvrir aussi ce fichier avec Neovim et
|
||
comparer les deux versions ; ne pas écraser une configuration inconnue.
|
||
Après revue seulement : `mv /mnt/etc/fstab.candidate /mnt/etc/fstab`.
|
||
Comparer aux [modèles](../templates/fstab.btrfs) comme schéma, sans copier
|
||
l’ancien `fstab` ni ses swaps/espaces de travail. **Arrêt** si doublon ou
|
||
UUID incohérent.
|
||
|
||
## 6. Chroot et identité — live puis chroot root
|
||
|
||
Depuis le live, rendre le dépôt de reconstruction disponible dans le nouveau
|
||
système à partir de la copie indépendante **déjà vérifiée** ; ne pas présumer
|
||
qu’un remote sera accessible :
|
||
|
||
```bash
|
||
: "${REPO_SOURCE:?Chemin de la copie indépendante vérifiée obligatoire}"
|
||
test -f "$REPO_SOURCE/templates/limine.conf"
|
||
test ! -e /mnt/root/arch-system
|
||
cp -a "$REPO_SOURCE" /mnt/root/arch-system
|
||
```
|
||
|
||
Entrer par `arch-chroot /mnt` après vérification des montages et du dépôt.
|
||
Dans le chroot,
|
||
choisir explicitement fuseau, locale, nom de machine et identités ; exemple à
|
||
adapter :
|
||
|
||
```bash
|
||
ln -sf /usr/share/zoneinfo/Europe/Paris /etc/localtime
|
||
hwclock --systohc
|
||
nvim /etc/locale.gen
|
||
locale-gen
|
||
nvim /etc/locale.conf
|
||
nvim /etc/hostname
|
||
nvim /etc/hosts
|
||
useradd -m -G wheel -s /bin/bash NOM_UTILISATEUR
|
||
passwd NOM_UTILISATEUR
|
||
passwd
|
||
EDITOR=nvim visudo
|
||
systemctl enable NetworkManager.service
|
||
```
|
||
|
||
Dans `visudo`, n’accorder à `wheel` que la règle minimale choisie. Vérifier
|
||
`getent passwd NOM_UTILISATEUR`, `visudo -c`, les locales produites et les
|
||
fichiers édités. Le réseau de secours doit rester utilisable sans politique
|
||
nftables non décidée. **Arrêt** si l’identité, le mot de passe ou le réseau ne
|
||
sont pas contrôlables. Les commandes de construction AUR se feront plus tard
|
||
comme utilisateur non root.
|
||
|
||
## 7. Initramfs et Limine — chroot root
|
||
|
||
Vérifier d’abord les artefacts **effectivement fournis** par les paquets :
|
||
|
||
```bash
|
||
pacman -Ql linux-lts limine amd-ucode
|
||
ls -l /usr/share/limine/BOOTX64.EFI /boot/vmlinuz-linux-lts
|
||
findmnt /boot
|
||
blkid
|
||
mkinitcpio -P
|
||
ls -l /boot/initramfs-linux-lts.img /boot/amd-ucode.img
|
||
```
|
||
|
||
Vérifier l’ESP réelle sous `/boot` et les UUID relevés. Après avoir confirmé
|
||
qu’aucun fichier préexistant ne serait écrasé, déployer le binaire fourni par
|
||
le paquet et rédiger la configuration sur l’ESP :
|
||
|
||
```bash
|
||
test "$(findmnt -nro TARGET /boot)" = /boot
|
||
test -f /usr/share/limine/BOOTX64.EFI
|
||
test ! -e /boot/EFI/arch-limine/BOOTX64.EFI
|
||
install -Dm0644 /usr/share/limine/BOOTX64.EFI /boot/EFI/arch-limine/BOOTX64.EFI
|
||
cp /root/arch-system/templates/limine.conf /boot/limine.conf.candidate
|
||
nvim /boot/limine.conf.candidate
|
||
```
|
||
|
||
Dans Neovim, remplacer l’UUID racine, supprimer l’entrée Zen si `linux-zen`
|
||
n’a pas été installé, choisir `default_entry` correspondant à l’entrée LTS,
|
||
et contrôler `rootflags=subvol=@`. Vérifier l’absence de `@ROOT_UUID@`,
|
||
l’existence de chaque `kernel_path`/`module_path` et la syntaxe de la version
|
||
Limine installée avant `mv /boot/limine.conf.candidate /boot/limine.conf`.
|
||
Pour l’entrée UEFI, fournir séparément le **disque entier de l’ESP** et son
|
||
numéro de partition, puis vérifier `efibootmgr -v` :
|
||
|
||
```bash
|
||
: "${DISK:?Disque de l’ESP vérifié obligatoire}"
|
||
: "${ESP_PART_NUMBER:?Numéro de partition EFI vérifié obligatoire}"
|
||
efibootmgr --create --disk "$DISK" --part "$ESP_PART_NUMBER" \
|
||
--label 'Arch Linux Limine' --loader '\EFI\arch-limine\BOOTX64.EFI' --unicode
|
||
efibootmgr -v
|
||
```
|
||
|
||
La [documentation Limine](https://wiki.archlinux.org/title/Limine) distingue
|
||
le chemin UEFI et le fichier de configuration. Ne pas modifier l’EFI pendant
|
||
cette mission. Garder une entrée LTS normale et un retour au support live.
|
||
**Arrêt** si un artefact, UUID, numéro de partition ou chemin diffère ; aucun
|
||
démarrage n’a été éprouvé ici.
|
||
|
||
## 8. Secure Boot — décision conditionnelle, chroot/firmware par opérateur
|
||
|
||
Avant activation, déterminer la politique de clés et les moyens de récupération
|
||
existants. Si cette politique retient `sbctl`, vérifier sa disponibilité dans
|
||
les dépôts (`pacman -Si sbctl`) et l’installer après décision
|
||
(`pacman -S sbctl`). Avec la version réellement présente de `sbctl`, vérifier les
|
||
commandes `status`, `list-files` et `verify`, les fichiers EFI suivis, le
|
||
chargeur effectivement sélectionné, les noyaux et les copies historiques.
|
||
Comparer les signatures au chemin de confiance Limine retenu. Le hook ALPM
|
||
`zz-sbctl.hook` était masqué sur ArchASP ; **ne pas le réactiver du seul fait
|
||
de ce masquage**. Le post-hook mkinitcpio observé ne démontre que la voie
|
||
conditionnelle du noyau, pas une signature de toute la chaîne. Ne pas créer
|
||
ni enrôler de clés, supprimer des clés firmware ou imposer `ESP_PATH` par
|
||
habitude. **Arrêt** si les clés, fichiers à signer et déclencheurs ne sont pas
|
||
établis ; procéder avec le support live de secours. Voir
|
||
[la sécurité](security.md) et [sbctl(8)](https://man.archlinux.org/man/sbctl.8.en).
|
||
|
||
## 9. Avant et après le premier démarrage — opérateur
|
||
|
||
Avant de quitter le live : `findmnt -R /mnt`, `cat /mnt/etc/fstab`, présence
|
||
du noyau/initramfs et du chargeur sur l’ESP, entrée normale Limine, accès
|
||
réseau de secours et copies. Démonter uniquement après revue et sortir du
|
||
chroot. Le **redémarrage humain n’a pas été fait ici**. Après démarrage normal,
|
||
vérifier `findmnt`, `lsblk -f`, `systemctl --failed`, réseau, heure, entrée
|
||
réellement amorcée et, si choisie, la chaîne Secure Boot. Revenir au support
|
||
live en cas d’échec ; ne pas confondre présence de fichiers et démarrage réussi.
|
||
|
||
## 10. AUR et `yay` — utilisateur non root, après démarrage
|
||
|
||
Installer `base-devel` et `git` depuis les dépôts officiels, choisir une
|
||
source AUR explicite et vérifier `PKGBUILD`, fichiers annexes, provenance,
|
||
révision et dépendances. Comme utilisateur ordinaire, dans un répertoire de
|
||
travail privé : `git clone https://aur.archlinux.org/yay.git`, examiner avec
|
||
`nvim PKGBUILD`, puis seulement `makepkg -si`. Vérifier la version et la
|
||
provenance installées. Ne pas lancer `makepkg` en root ni `curl | sh`.
|
||
`deploy.sh --packages` refuse actuellement la liste AUR sans `yay` ; ce refus
|
||
ne réalise pas l’amorçage. Sélectionner les paquets étrangers nécessaires
|
||
individuellement, sans importer toute la liste de juillet.
|
||
|
||
## 11. Snapper et retour d’essai — root après premier démarrage
|
||
|
||
Installer d’abord `snapper` et `snap-pac` depuis leurs sources officielles
|
||
vérifiées (`pacman -Si snapper snap-pac`, puis `pacman -S snapper snap-pac`).
|
||
`limine-snapper-sync` était classé étranger sur ArchASP ; le sélectionner,
|
||
examiner sa provenance et le construire comme utilisateur non root seulement
|
||
après l’amorçage AUR du §10. Le schéma crée déjà `@/.snapshots` : vérifier
|
||
`findmnt /.snapshots`, `btrfs subvolume show /.snapshots` et la version Snapper.
|
||
Ne pas lancer `snapper create-config /` sur un chemin existant en supposant
|
||
qu’il l’écrasera. Pour cette topologie, préparer la configuration `root` à
|
||
partir du modèle de la version installée (`/usr/share/snapper/config-templates/default`
|
||
observé ici), renseigner `SUBVOLUME="/"`, `FSTYPE="btrfs"`, enregistrer
|
||
`SNAPPER_CONFIGS="root"` dans `/etc/conf.d/snapper` et vérifier
|
||
`snapper -c root get-config`/`list`. N’écraser aucun fichier préexistant sans
|
||
comparaison dans Neovim. Choisir ensuite les timers cleanup/timeline et hooks
|
||
réellement disponibles ; vérifier leur déclenchement et les entrées
|
||
limine-snapper-sync générées. Un retour de snapshot `replace` recrée la racine
|
||
`@` avec un nouvel identifiant ; il ne restaure pas `@home`, `@log`, `@pkg` ni
|
||
les données hors SSD. Faire un essai de démarrage sur snapshot et de retour
|
||
normal **avant** de déclarer cette voie opérationnelle ; aucun essai ici.
|
||
|
||
## 12. Fonctions du poste — utilisateur puis root ciblé
|
||
|
||
Restaurer les dotfiles depuis leur copie indépendante, puis sélectionner les
|
||
fonctions nécessaires : TLP et seuil de batterie, CUPS/impression et
|
||
numérisation, éventuellement Avahi selon la découverte réellement requise,
|
||
nginx local en boucle locale pour le proxy Trainlog, puis VMware/Samba à la
|
||
demande. Pour Trainlog, ce dépôt ne transporte que les dépendances système ;
|
||
backend, unité utilisateur et base restent dans leurs périmètres séparés.
|
||
Vérifier chaque fonction après installation, sans activer tous les services
|
||
historiques. Zram 6 Gio est le socle historique ; swaps additionnels et
|
||
espaces de travail demandent une décision de charge séparée. Ne pas copier
|
||
`rootfs/etc/nftables.conf` ni lancer `deploy.sh --all` tant que la politique
|
||
VPN/flux n’est pas décidée. Voir [les choix réseau et services](security.md),
|
||
[la matrice](reconstruction-baseline.md) et [le déploiement](deploy-safety.md).
|