Re: Plus de swap...
François Cerbelle a écrit :
> 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
>
Merci pour les pistes, je vais regarder tout ça aujourd'hui.
Sinon, étant donné que le problème est survenu de façon plus ou moins
spontanée, je me demande justement si le problème n'aurait pas été causé
par la mise à jour d'un paquet, je voudrais regarder de ce coté là avant
de me lancer dans des bidouillages un peu complexe, et je me rends
compte que je ne sais pas comment avoir un historique de mises à jour
effectué sur le serveur (en mode graphique j'utilise en règle général
synaptic).
Une recherche sur google ne donne rien... à ce demander s'il existe
effectivement un historique des manipulations de paquets.
Reply to: