Ubuntu-fr

Arbiel

crypttab semble ne pas être exploité lors du démarrage d'une 16.04

Bonsoir

J'utilise la 14.04, /home est dans une partition différente de /, de même que /usr et /boot. / et /home sont chiffrées.

Je viens d'installer une 16.04 dans de nouvelles partitions, en visant la même organisation des partitions. Cependant, par mesure de précaution, j'ai laissé  /home dans la racine. Je veux maintenant reprendre mon /home réel, mais je n'y parviens pas, et ce, à mon avis, parce que crypttab n'est pas pris en compte au démarrage, du moins la ligne de crypttab relative à mon /home (la partition racine est correctement déchiffrée, mais cela ne tient-il pas à mon initrd.img ?)

J'écris ce message à partir de la 14.04. Voila les lignes significatives de mes fichiers

# /etc/fstab: static file system information.
#
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
#
###########################
# Arborescence standard du système
###########################
/dev/mapper/victor-root /               ext4    errors=remount-ro 0       1
tmpfs /tmp tmpfs defaults,size=512M 0 0
/dev/mapper/victor-home /home ext4 defaults 0 2

victor-root UUID=78576555-f0c2-4c80-af4f-d763cc7ae71d /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.victor-root:1 luks,keyscript=/lib/cryptsetup/scripts/passdev
victor-home UUID=37447a61-f946-4d38-a398-5a886c4e3f22 /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.victor-home:1 luks,keyscript=/lib/cryptsetup/scripts/passdev

Avant d'écrire ce message, j'ai exécuté les instructions ci-dessous dans la 16.04 dans laquelle je n'ai pas modifié le fichier /etc/fstab puisque le démarrage avec mon /home réel ne fonctionne pas.

remi@remi-Vostro-3550:~$ cat /etc/crypttab | grep victor-home
victor-home UUID=37447a61-f946-4d38-a398-5a886c4e3f22 /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.victor-home:1 luks,keyscript=/lib/cryptsetup/scripts/passdev
remi@remi-Vostro-3550:~$ sudo blkid | grep home
/dev/mapper/victor-home_l: UUID="37447a61-f946-4d38-a398-5a886c4e3f22" TYPE="crypto_LUKS"
remi@remi-Vostro-3550:~$ sudo cryptdisks_start victor-home
 * Starting crypto disk...                                                       * victor-home (starting)..
 * victor-home (started)...                                              [ OK ] 
remi@remi-Vostro-3550:~$ sudo blkid | grep home
/dev/mapper/victor-home_l: UUID="37447a61-f946-4d38-a398-5a886c4e3f22" TYPE="crypto_LUKS"
/dev/mapper/victor-home: LABEL="victor-home" UUID="c5faba25-bb99-4afd-84cc-575657c03fa5" TYPE="ext4"
remi@remi-Vostro-3550:~$ 

La ligne relative à mon /home (victor-home) est bien la même dans les deux fichiers.

A mon avis, si le fichier /etc/crypttab de la 16.04 était correctement traité, la commande blkid | grep home devrait lister également victor-home et pas uniquement victor-home_l.

La commande cryptdisks_start exploite le fichier /etc/crypttab, ce qui provoque le déchiffrement de victor-home_l, comme le montre la seconde commande blkid | grep home.

Dois-je faire quelque chose de particulier pour que crypttab soit effectivement pris en compte par la procédure de démarrage ?

Merci d'avance à quiconque pourra me mettre sur la voie.

Arbiel

---

Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04, GNOME 3.36.8
24.04 en cours de tests
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Arbiel

Re : crypttab semble ne pas être exploité lors du démarrage d'une 16.04

Bonsoir

Le problème semble provenir du fait que la partition (sur support amovible) dans laquelle se trouve le fichier contenant la clé de chiffrement de mon volume logique victor-home est montée lorsque le script /etc/init.d/cryptdisks tente de le déchiffrer. Cette partition ayant été montée pour le déchiffrement de la racine victor-root_1604, et n'ayant probablement pas été démontée, cryptdisks_start ne parvient pas à se l'approprier, et n'arrive pas à lire le fichier contenant la clé de chiffrement de victor-home.

Ce problème ne se produit pas dans la 14.04.

Cependant, dans les deux distributions, dès la fin de la procédure de démarrage, la partition amovible est montée sur /media/… mais je ne sais pas si cela a un rapport, car lorsque /etc/init.d/cryptdisks s'exécute, ce répertoire n'a pas lieu d'être le point de montage de ma partition amovible.

Les versions de cryptsetup sont respectivement 1.6.1 dans la 14.04 et 1.6.6 dans 16.04.

Arbiel

Edit : j'ai recopié le fichier de déchiffrement de victor-home sur un second support amovible. Même résultat (la modification du fichier /etc/crypttab correspondante est correcte - je l'ai testé par une commande cryptdisks_start victor-home qui a parfaitement fonctionné)

Dernière modification par Arbiel (Le 22/07/2016, à 23:35)

---

Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04, GNOME 3.36.8
24.04 en cours de tests
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Arbiel

Re : crypttab semble ne pas être exploité lors du démarrage d'une 16.04

J'ai extrait des journaux d'exploitation les erreurs relatives au déchiffrement lors du démarrage des volumes logiques définis dans le fichier /etc/crypttab

grep -v -e "noauto" /mnt/etc/crypttab | grep -v -e "^#"
victor-root_1604 UUID=22847149-1399-491b-b166-007a50938c5f /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.victor-root_1604:1 luks,keyscript=/lib/cryptsetup/scripts/passdev
victor-home UUID=37447a61-f946-4d38-a398-5a886c4e3f22 /dev/disk/by-uuid/e4fa73a6-92bc-4d1e-98b0-7b6d92661ae4:/.victor-home:1 luks,keyscript=/lib/cryptsetup/scripts/passdev
victor-root_alt UUID=bcc1027f-6078-449f-a26c-99706b5b59b4 /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.victor-root_alt:1 luks,keyscript=/lib/cryptsetup/scripts/passdev

Cela m'a donné les résultats suivants

journalctl -x -p 0..3 | grep -e "dev-disk-by.* a échoué"
-- Subject: L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_1604:1.device a échoué
-- L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_1604:1.device a échoué, avec le résultat timeout.
-- Subject: L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_alt:1.device a échoué
-- L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_alt:1.device a échoué, avec le résultat timeout.
-- Subject: L'unité (unit) dev-disk-by\x2duuid-e4fa73a6\x2d92bc\x2d4d1e\x2d98b0\x2d7b6d92661ae4:-.victor\x2dhome:1.device a échoué
-- L'unité (unit) dev-disk-by\x2duuid-e4fa73a6\x2d92bc\x2d4d1e\x2d98b0\x2d7b6d92661ae4:-.victor\x2dhome:1.device a échoué, avec le résultat timeout.
-- Subject: L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_alt:1.device a échoué
-- L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_alt:1.device a échoué, avec le résultat timeout.
-- Subject: L'unité (unit) dev-disk-by\x2duuid-e4fa73a6\x2d92bc\x2d4d1e\x2d98b0\x2d7b6d92661ae4:-.victor\x2dhome:1.device a échoué
-- L'unité (unit) dev-disk-by\x2duuid-e4fa73a6\x2d92bc\x2d4d1e\x2d98b0\x2d7b6d92661ae4:-.victor\x2dhome:1.device a échoué, avec le résultat timeout.
-- Subject: L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_alt:1.device a échoué
-- L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_alt:1.device a échoué, avec le résultat timeout.
-- Subject: L'unité (unit) dev-disk-by\x2duuid-e4fa73a6\x2d92bc\x2d4d1e\x2d98b0\x2d7b6d92661ae4:-.victor\x2dhome:1.device a échoué
-- L'unité (unit) dev-disk-by\x2duuid-e4fa73a6\x2d92bc\x2d4d1e\x2d98b0\x2d7b6d92661ae4:-.victor\x2dhome:1.device a échoué, avec le résultat timeout.

On peut y voir que le déchiffrement de victor-root_1604 a échoué 1 seule fois, alors que le déchiffrement des deux autres volumes logiques a échoué 3 fois, et que le déchiffrement de ces deux volumes a été essayé dans l'ordre inverse de leur apparition dans le fichier /etc/crypttab.

Il semble donc que le problème ne provienne pas, comme je l'ai supposé précédemment, du montage de la partition amovible qui contient les fichiers clés de chiffrement.

Malheureusement, je n'ai pas su comparer ces informations avec les informations correspondantes de la 14.04, la commande d'inspection des journaux d'exploitation (journalctl) n'étant pas disponible avec la 14.04.

Dernière modification par Arbiel (Le 23/07/2016, à 02:17)

---

Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04, GNOME 3.36.8
24.04 en cours de tests
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.