Re: Plus de swap...
Goldy a écrit :
[...]
D'ailleurs, pour être précis, en ce qui concerne le chiffrement, deux
volumes logiques sont chiffrés, le home et la swap. Le home se monte
sans difficulté, la passphrase est demandé au boot du système et tout
fonctionne de ce coté là. La swap quand à elle utilise un clé aléatoire
qui est redéfini à chaque boot du système, c'est une option qui est
disponible dans debian installer, je ne connais pas le détail de son
fonctionnement.
Je n'ai jamais utilisé cette option car je n'ai jamais pris le temps de
la décortiquer pour la comprendre avant de dire "oui". Je ne voulais pas
prendre le risque d'une panne que je ne comprenais pas. En plus, une clé
aléatoire générée au démarrage ne me semblait avoir un intérêt que dans
le cas où cette clé est oubliée dès l'activation du swap, et je ne
voyais pas comment j'aurais pu utiliser cette technique avec
l'hibernation...
Je suppose que ton problème vient de cette clé aléatoire. Je pense que
si tu forçais manuellement ce que devraient certainement faire les
scripts de démarrage, ca marcherait :
- Creation d'une cle aleatoire
- Destruction/Reconstruction du chiffrement de
/dev/mapper/lv-swap-chiffre avec "cryptsetup lukscreate" et la clé aléatoire
- Ouverture du nouveau périphérique chiffré créé avec "cryptsetup
luksopen" et la clé aléatoire
- Oubli de la clé aleatoire
- formatage du /dev/mapper/lv-swap-dechiffre avec "mkswap -L swap"
- activation du swap avec "swapon"
Mais, pour être sûr, il faudrait que tu regardes ce qui se passe dans
les scripts de démarrage, mais pas uniquement dans /etc/init.d .
Il est possible que les scripts y soient et sachent bien faire leur
travail quand tu les lances à la main, mais qu'ils ne soient pas mis en
place dans le fichier /boot/initrd à cause d'une option de configuration
erronée dans /etc/defaults/* par exemple.
A ta place, je commencerai par chercher les scripts qui font cette
creation/reinitialisation au démarrage. Je pense que tu peux faire une
recherche recursive de "crypt" dans /etc/. Ce sera un point de départ
pour trouver le script qui s'occupe de cette initialisation. Ensuite, je
chercherais à vérifier ses fichiers de configuration (certainement dans
/etc/default), je chercherais à le faire fonctionner à la main (il
devrait initialiser, creer et monter ton swap), et enfin, voir s'il est
bien embarqué dans le fichier initrd.
Tu peux faire un test rapide, au cas où ton initrd n'aurait pas été
généré correctement : update-initramfs -u. Vérifie dans
/etc/default/initramfs que la configuration garde bien un fichier de
sauvegarde (/boot/initrd.img.bak). Au cas où...
Il semble que quelque chose ait cassé le montage de la partition
chiffré, car le volume logique LVM de la swap est bien monté.
Il n'est pas "monté", il est juste détecté et mis à disposition dans le
répertoire /dev/mapper/, si je comprends bien.
L'espace de swap indiqué dans /etc/fstab correspond il bien à ce que tu
as dans /dev/mapper ?
Dans /dev/mapper, la partition swap chiffré n'apparait justement plus.
J'ai bien le volume logique qui apparait, mais le volume chiffré ne
semble plus se monter avec le système. D'où l'erreur de swapon posté
dans mon premier message.
C'est parce que les scripts de démarrage ne savent pas le déchiffrer
qu'il n'apparait pas. Comme les scripts ne te posent pas de question,
c'est peut être qu'ils ne voient plus le /dev/mapper/lv-swap-chiffré
comme un volume chiffré et qu'il ne cherche pas ni à le déchiffrer, ni à
réinitialiser le chiffrement avec une clé aléatoire.
Il faut que je trouve des informations concrètes sur le fonctionne du
chiffrement spécifique à debian-installer, car pour l'instant, ce que je
trouve, c'est surtout des informations sur comment faire une partition
chiffré manuellement, ce qui ne correspond peut-être pas exactement à ce
que fait debian-intaller.
C'est surtout les scripts de chiffrement avec clé aléatoire qu'il faut
regarder à mon avis, mais ne les ayant pas utilisés, je ne peux pas t'en
dire plus.
Si tu utilises splashy ou un autre splash, essaye de le désactiver en
retirant "splash" de la ligne de commande du noyau et éventuellement
"quiet", pour pouvoir voir la sortie et les erreurs de tous les scripts
de démarrage. Tu pourras aussi consulter tous les messages du noyau avec
la commande dmesg. Ca pourra toujours t'aider, la solution s'y trouve
peut etre.
Fanfan
Reply to: