Vous n'êtes pas identifié(e).
L'OS cherche encore les anciens points LVM de /dev/mapper/root-root_crypt.
Pourtant, j'ai bien modifié le /etc/crypttab et le /etc/fstab.
Effectué un chroot de mon système, grub-install et update grub.
Je démarre bien avec grub
Pour utiliser plusieurs disques dur, je suis passé en GPT avec partition EFI.
Avant j'avais juste le /boot sans EFI.
Une idée pour indiquer les nouveaux points de montage LVM ?
Merci
Hors ligne
Du coup je suis passé par plusieurs opérations depuis.
Mon système LVM a changé,
Quelles opérations ? Qu'est-ce qui a changé ? Quelle est la structure actuelle des volumes LVM/LUKS ?
L'OS cherche encore les anciens points LVM de /dev/mapper/root-root_crypt.
Pourtant, j'ai bien modifié le /etc/crypttab et le /etc/fstab.
Est-ce que tu as reconstruit l'initramfs avec update-initramfs ?
Il vaut mieux montrer que raconter.
Hors ligne
lsblk
---------------------------
CONFIG ACTUELLE
J'ai utilisé l'installeur de debian pour repartitionner.
Je suis passé d'un boot legacy (bios) à un EFI.
J'ai effacé le système installé par l'installeur pour y mettre l'ancien.
Grossièrement : rm system_actuel && rsync -PahhlHx --delete system_sauvegardé system_actuel
AJUSTEMENTS DEJA EFFECTUES
(J'ai crypté les PV au lieu des LV, bon pas grave. Je referais plus tard si besoin.)
-----------------------------
INITRAMFS
Je n'ai pas effectué update-initramfs encore, est-ce que ça va reconstruire le LVM & LUKS au démarrage ?
Hors ligne
Je suis passé d'un boot legacy (bios) à un EFI.
Une raison particulière à ce changement ?
J'ai crypté les PV au lieu des LV, bon pas grave
Au contraire, c'est plus simple et logique de chiffrer le PV que de chiffrer individuellement les LV qu'il contient.
Par contre il y a un détail que je ne comprends pas : apparemment il y a maintenant un VG distinct pour chaque VG. Pourquoi cela ?
Plus de swap ?
Je trouve que les noms des volumes chiffré ne sont pas bien choisis car ils font références à des noms sd* qui ne sont ni explicites ni garantis fixes. Pour moi le nommage doit être lié au contenu (comme les noms de LV), pas au contenant.
Je n'ai pas effectué update-initramfs encore, est-ce que ça va reconstruire le LVM & LUKS au démarrage ?
Ça va mettre à jour l'initramfs avec le nouveau contenu du fichier crypttab nécessaire pour ouvrir le volume chiffré contenant le système de fichiers racine.
Note que tu devrais pouvoir les ouvrir manuellement avec cryptsetup dans le shell de l'initramfs et poursuivre le démarrage.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Pour le changement de boot legacy à EFI, c'est un conseil qu'on m'a donné.
Avec quel motif ?
L'initiramfs m'a reglé le problème quand j'avais juste le HOME et les DATA de chiffrés.
L'initramfs n'a pas besoin de monter home ni data. Il n'a besoin d'accéder qu'au système de fichiers racine et au swap (si utilisé pour l'hibernation).
Il vaut mieux montrer que raconter.
Hors ligne
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
En ligne
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par joffrey575 (08-04-2021 15:41:58)
Hors ligne
Jusqu'ici, j'ai bien monté l'existant sur mon système debian.
J'update grub.
Pour finir, j'effectue un initramfs.
La target 'luks-524c1ad6-fabe-4f32-9bb0-c8db1286b262' n'est pas trouvé alors qu'elle est présente dans le fichier /etc/crypttab.
Ou se situe le problème ? C'est le fait de monter les partitions sur le système debian à mettre à jour ?
Si j'installe Debian avec une clé ou un CD et je crypte le système '/', pas de problème la partition luks-XXX est détecté au démarrage.
Lorsque je reprends mon système serveur et que je le copie à la place de celui installé avec le live USB, la partition système luks-XXX n'est pas détecté alors que les luks-XXX du DATA et HOME sont détectées.
Hors ligne
Dernière modification par joffrey575 (08-04-2021 15:58:23)
Hors ligne
Si j'ai bien saisi, il vaut mieux chiffrer le LV si l'on veut par la suite ajouter un disque dur et étendre le LV ?
Ça dépend comment on gère la passphrase.
Si on chiffre les PV d'un VG, en principe il faudra taper la passphrase pour chaque PV. Fastidieux. Sauf
- si tous les PV ont la même passphrase et plymouth est installé et pas désactivé (paramètre nosplash), alors il ne sera demandé qu'une fois
- ou si la passphrase est lue dans un fichier (lui-même dans un volume chiffré ouvert précédemment) alors elle ne sera pas demandée du tout.
En revanche si on chiffre l'unique LV d'un VG et non les PV, alors il n'y a toujours qu'une seul volume chiffré (et une seule passphrase) quel que soit le nombre de PV.
On peut aussi faire un "sandwitch" LVM-LUKS-LVM. Un premier VG avec les PV non chiffrés qui contient un unique LV qui sert de conteneur LUKS dont le volume chiffré sert de PV pour un second VG qui contient un ou plusieurs LV. Ainsi il n'y a toujours qu'un seul volume chiffré quel que soit le nombre de PV et de LV.
update-initramfs: Generating /boot/initrd.img-4.19.0-14-generic
C'est quoi cette version de noyau ? On dirait un noyau Ubuntu. A ma connaissance les noyau Debian ne contiennent pas le suffixe "-generic".
La target 'luks-524c1ad6-fabe-4f32-9bb0-c8db1286b262' n'est pas trouvé alors qu'elle est présente dans le fichier /etc/crypttab.
Vraiment ? On peut voir ? En tout cas elle n'est pas dans le fichier que tu as montré dans ton message #3.
Je me suis arraché les cheveux à comprendre d'où venait cet identifiant "luks-524c1ad6-fabe-4f32-9bb0-c8db1286b262". J'ai charché dans dmsetup, systemd... Mais je soupçonne qu'en fait c'est le gestionnaire de fichiers que tu as dû utiliser pour ouvrir le volume chiffré qui a attribué ce nom au volume dans /dev/mapper. Et forcément, il ne correspond pas au nom défini dans crypttab.
Tu as deux options : soit tu ouvres le volume chiffré avec cryptsetup et avec le même nom que dans crypttab, soit tu ajoutes "initramfs" dans le champ des options de ce volume dans crypttab pour qu'il soit inconditionnellement ouvert par l'initramfs.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne