14 KiB
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 et le
bilan de finalisation. 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 :
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 :
: "${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 :
: "${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 :
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 :
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 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 :
: "${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 :
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 :
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 :
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 :
: "${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 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é et sbctl(8).
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,
la matrice et le déploiement.