Installation preseed ramdisk HS

Bonjour,

j’ai une machine installée via un preseed.
Celui-ci fonctionne très bien en mode normal pour installer une machine de base sans GUI ou avec GUI LXQT.
J’ai fait la même machine mais avec un disque chiffré avec LVM over LUS.
grub s’installe, la machine démarre bien sur GRUB, mais au lancement du ramdisk ça plante:

 Volume group "vg01" not found
 Cannot process volume group vg01
 Volume group "vg01" not found
 Cannot process volume group vg01
 Volume group "vg01" not found
 Cannot process volume group vg01
Gave up waiting for suspend/resume device
 Volume group "vg01" not found
 Cannot process volume group vg01
Gave up waiting for root file system device.  Common problems:
 — Boot args (cat /proc/cmdline)
   — Check rootdelay= (did the system wait long enough?)
 — Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/mapper/vg01-root does not exist.  Dropping to a shell!


BusingBox v1.30.1 (Debian 1:1.30.1-6+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) _ 

je précise qu’en démarrant en mode rescue j’arrive à monter mes partition et à faire des commandes. Mais impossible de faire en sorte que la machine marche. je pense qu’il y a un problème avec le fait que le disque est chiffré, sauf /boot et /boot/efi bien sur.

Le système ne semble pas faire en sorte de déchiffrer le disque (il ne me demande pas le mot de passe).

Quel ramdisk ? Ça fait belle lurette que Debian démarre avec un initramfs (tmpfs/ramfs), et non plus un initrd (ramdisk).

Est-ce que le paquet cryptsetup-initramfs est installé ?
Est-ce que /etc/crypttab existe dans la racine et contient ce qu’il faut pour ouvrir le volume chiffré avec le bon nom ?
Est-ce que le contenu du fichier se retrouve dans /cryptroot/crypttab de l’initramfs ?

oui exact mal décris, après le lancement du ramdisk, l’initramfs plante.

aucun fichier de ce genre, mais le cryptab est bon

Il n’y a plus de ramdisk.

Non, il attend que le volume chiffré soit ouvert.

En fait c’est /cryptroot/crypttab.
Tu devrais pouvoir ouvrir le volume chiffré depuis le shell de l’initramfs et quitter le shell pour poursuivre le démarrage.

cryptsetup luksOpen /dev/<partition> yyy_crypt

où yyy_crypt est le même nom que dans crypttab.
Une fois le système complet lancé, tu pourras reconstruire l’initramfs avec update-initramfs -u et le fichier cryptroot devrait être présent.

C’est lui qui manquait, j’ai ajouté le packages à mon fichier de base crypto .packages et mon simple-cdd devrait marcher (j’ai un script qui assemble les divers élements d’un fichier de conf et génère pour chaque profil de conf, les fichiers preseed, packages, downloads, postinst qui sont ensuite traités par le build de simple-cdd, pour créer une iso avec les différents profils que je peux choisir celui que je veux installer. en moyenne 15 à 25 mn pour installer une machine virtuelle directement utilisable sans aucune manipulation supplémentaire; clef en main en quelque sorte; excepté le hostname qui est positionné uniquement grace au DHCP, sinon il faut le mettre à la main, et le mot de passe crypto car le mdp par defautg est simple pour faciliter l’installation)

Chacun a sa manière favorite de faire les choses.

Voici comment il m’arrive de faire :

  • téléchargement de iPXE depuis github, une version postérieure à ce commit qui introduit « initrd=initrd.magic »
  • compilation d’une version pour BIOS et une version pour EFI avec les commandes :
make -j 4 bin-i386-pcbios/ipxe.pxe
make -j 4 bin-x86_64-efi/ipxe.efi
  • configuration d’un serveur DHCP pour que les machines en BIOS ou en EFI téléchargent la version adéquate de iPXE depuis un serveur TFTP
  • ensuite, il n’y a plus qu’à écrire un petit script pour iPXE et à le mettre à disposition sur un serveur web quelconque

Exemple de script pour iPXE :

#!ipxe

set mirror http://ftp.fr.debian.org
set base_path ${mirror}/debian/dists/bullseye/main/installer-amd64/current/images/netboot/debian-installer/amd64

kernel ${base_path}/linux
initrd ${base_path}/initrd.gz
initrd http://192.168.10.36/bullseye_install/auto_serial.preseed preseed.cfg
initrd http://192.168.10.36/bullseye_install/late.sh
initrd http://192.168.10.36/bullseye_install/onefs.pmr
imgargs linux initrd=initrd.magic DEBIAN_FRONTEND=newt net.ifnames=0 --- console=ttyS0,115200n8r
boot

Pour que iPXE aille chercher ce script, son chemin peut être fourni par le serveur DHCP. On peut aussi le faire manuellement grâce à l’invite de commandes d’iPXE :

dhcp net0
chain http://192.168.10.36/bullseye_install/auto_serial.ipxe

Ce qui est super pratique depuis ce commit c’est que tous les fichiers tels que late.sh sont téléchargés et mis à la suite dans l’archive CPIO de l’initrd. Y compris pour un boot en EFI.
Ils sont donc disponibles pour l’installateur de la même manière que des fichiers ajoutés dans une image de CD créée par simple-cdd.

Par exemple, le contenu de late.sh :

#!/bin/sh

in-target ln -s /dev/null /etc/systemd/network/99-default.link
in-target update-initramfs -u

Disons que cela m’évite de devoir générer une image ISO à chaque fois.
Eventuellement, je pourrais aussi écrire une appli web qui me permettra de configurer une installation via iPXE directement depuis un clickodrome


AnonymousCoward

Oui aussi, mais le preseed seul ne permet pas de tout faire, notamment l’inclusion de fichier spécifiques dans l’ISO, la gestion d’un script postinst dans l’environnement installé (un peu comme si tu étais en mode rescue), le in-target ne permettant pas de tout faire.

et surtout, l’objectif de ne pas être obligé d’avoir accès à des ressources réseau pour faire une installation :slight_smile:

Il me semblé que IPXE justement permettait d’utiliser le protocole HTTP nettement plus rapide que le tftp ?

Il y a une raison pour laquelle tu préfère utiliser le TFTP ? (faciliter, infra existante ?)

je n’utilise ni l’un ni l’autre. Tout est sur l’ISO.
La seule chose qui n’est pas faisable sans le réseau, ce sont les mises à jour de sécurité.
mais c’est juste un update à faire avec apt.

Je n’utilise pas les mises à jour automatiques sur mes serveurs. Je les fait toujours manuellement.

En fait, c’est la ROM de démarrage PXE intégrée à une carte réseau physique qui utilise TFTP pour télécharger iPXE.
Par exemple, le Intel Boot Agent (IBA) intégré dans les cartes réseau du constructeur.

Une fois que iPXE a la main, oui, on utilise de préférence autre chose que du TFTP.

Là où les choses sont un peu plus troubles, c’est que sur un hyperviseur tel que Proxmox VE, la ROM de démarrage PXE intégrée à une carte réseau virtuelle c’est iPXE lui-même. Dans une version généralement un peu ancienne.

Dans ce cas, iPXE télécharge puis donne la main à une version plus à jour de lui-même via TFTP.
Le reste du processus se poursuit ensuite, avec http.


AnonymousCoward

1 J'aime

Si tu as un exemple concret dont il est possible de le montrer, cela m’intéresse.

Au besoin, tu peux sans-doute télécharger puis exécuter un (ou plusieurs) scripts comme montré ici :

https://connect.ed-diamond.com/GNU-Linux-Magazine/glmfhs-045/une-installation-de-debian-automatique#index_h3_71


AnonymousCoward

Merci c’est plus clair ainsi

en beaucoup mieux en fait, car avec un simple-cdd, tu n’a absolument d’autre à faire que lancer l’install, selectionner la langue pour l’installer, puis ton profil, et c’est tout. l’installer fait tout:

  • il installe le système
  • il installe les paquets voulus en plus du système
  • tu peux avoir un early-command (pour moi c’est de vider le disque dur de ses partition
  • un late_command (commande de base pour mettre des fichiers sur le disque. cette commande a des possibilité bien plus limitées qu’un postint du simple-cdd
  • et le postinst

ensuite, tu te log et tu utilises directement sans rien d’autre à faire.

Actuellment, j’installe un VM avec LXQT + con,figuration adie + disque chiffré LUKs avec mise à zero de la partition cryptée, sur une virtual box de 2Go de RAM et 2CPU en moins de 40mn sur un host sous windows AMD Ryzen 5 3600X 6-Core 3.80 GHz , 32Go de RAM et full SSD sur 5 To et NVidia RTX 2080 8 Go.
Mise à jour comprise.