# 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 `. 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).