Échange ne fonctionne pas sur une installation propre 14.04 à l’aide d’une maison cryptée

Question

Mise à jour 3:

J'ai décidé de réinstaller le système à partir de zéro afin de supprimer tout élément obsolète qui traînait depuis que je rencontrais d'autres problèmes après la mise à niveau. Cependant, ce problème a persisté.

Lors d'une nouvelle installation, le choix d'installer à l'aide de "home crypté" conduit à une configuration d'échange cryptée cassée.

Mise à jour 2:

J'ai corrigé l'ordre de partitionnement dont se plaint cfdisk, mais le problème persiste. Le swap est maintenant sur/dev/sda6, et je peux le faire fonctionner comme suit:

~$ Sudo mkswap /dev/sda6 Setting up swapspace version 1, size = 7998460 KiB no label, UUID=18881d0f-d9ec-43be-a23f-0cbd78ea6d22 $Sudo nano /etc/crypttab # Update crypttad with new UUID $ Sudo /etc/init.d/cryptdisks reload * Stopping remaining crypto disks... * cryptswap1 (stopped)... [ OK ] * Starting remaining crypto disks... * cryptswap1 (starting).. * cryptswap1 (started)... [ OK ] $ Sudo swapon -a $ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 10 May 11 09:04 08b07f88-6da5-4b40-b062-42b3bb1c5f00 -> ../../sda3 lrwxrwxrwx 1 root root 10 May 11 09:08 18881d0f-d9ec-43be-a23f-0cbd78ea6d22 -> ../../sda6 lrwxrwxrwx 1 root root 10 May 11 09:04 19aa372c-05c8-4226-8f09-c54e5566e816 -> ../../sda5 lrwxrwxrwx 1 root root 10 May 11 09:04 A800B16E00B143DA -> ../../sda1 lrwxrwxrwx 1 root root 10 May 11 09:04 D28230E68230D129 -> ../../sda2 lrwxrwxrwx 1 root root 10 May 11 09:08 fcc8c419-8fec-4d4d-b55e-9e4c3b04d21d -> ../../dm-0

Mais après un redémarrage, l'échange ne parvient pas à s'activer et ressemble encore à ceci:

$ ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 10 May 11 09:12 08b07f88-6da5-4b40-b062-42b3bb1c5f00 -> ../../sda3 lrwxrwxrwx 1 root root 10 May 11 09:12 19aa372c-05c8-4226-8f09-c54e5566e816 -> ../../sda5 lrwxrwxrwx 1 root root 10 May 11 09:12 A800B16E00B143DA -> ../../sda1 lrwxrwxrwx 1 root root 10 May 11 09:12 D28230E68230D129 -> ../../sda2

Je suppose que pour le moment, lors de la configuration du disque en tant que système crypté, Linux ne reconnaît plus le type de partition et ne le charge donc pas correctement. Mais je ne sais pas comment le réparer ..

Question mise à jour:

Des tests supplémentaires ont révélé que je pouvais obtenir le swap en exécutant $ mkswap/dev/sda5

puis en mettant à jour/etc/crypttab avec le bon UUID et en suivant les étapes décrites ici: Comment configurer un fichier d'échange crypté?

Le problème persiste cependant lorsque je redémarre l’ordinateur, le fichier/dev/sda5 n’apparaît pas à l’exécution.

$ ls -l /dev/disk/by-uuid/

Si je fais:

$ cfdisk /dev/sda

Je reçois l'erreur suivante:

FATAL ERROR: Bad logical partition 6: enlarged logical partitions overlap Press any key to exit cfdisk

L'utilitaire graphique "Disks" ne se plaint d'aucune erreur lors de l'ouverture du disque.

$ Sudo fdisk -l Disk /dev/sda: 256.1 GB, 256060514304 bytes 255 heads, 63 sectors/track, 31130 cylinders, total 500118192 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x619aebf1 Device Boot Start End Blocks Id System /dev/sda1 * 2048 206847 102400 7 HPFS/NTFS/exFAT /dev/sda2 206848 100870143 50331648 7 HPFS/NTFS/exFAT /dev/sda3 191397888 192397311 499712 83 Linux /dev/sda4 192399358 500117503 153859073 5 Extended /dev/sda5 484118528 500117503 7999488 82 Linux swap / Solaris /dev/sda6 192399360 484118527 145859584 83 Linux Partition table entries are not in disk order

Question originale:

Après la mise à niveau de la version 14.04 (à partir de la version 13.04), mon ordinateur a connu de graves ralentissements. Lors de l'exécution de top, j'ai remarqué que kswap0 prenait beaucoup de temps CPU. J'ai aussi remarqué que je n'avais pas d'espace d'échange!

$ Sudo swapon -a swapon: /dev/mapper/cryptswap1: stat failed: No such file or directory

Il semble y avoir un problème avec ma configuration de swap crypté (je ne savais même pas que j'en avais un)

$ cat /etc/crypttab cryptswap1 UUID=abe3c568-c8fd-4dfb-b8e9-0520d442dd61 /dev/urandom swap,cipher=aes-cbc-essiv:sha256 $ ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 10 May 6 11:00 08b07f88-6da5-4b40-b062-42b3bb1c5f00 -> ../../sda3 lrwxrwxrwx 1 root root 10 May 6 11:00 19aa372c-05c8-4226-8f09-c54e5566e816 -> ../../sda6 lrwxrwxrwx 1 root root 10 May 6 11:00 A800B16E00B143DA -> ../../sda1 lrwxrwxrwx 1 root root 10 May 6 11:00 D28230E68230D129 -> ../../sda2

Et en regardant mon fstab

$ cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda6 during installation UUID=19aa372c-05c8-4226-8f09-c54e5566e816 / ext4 errors=remount-ro 0 1 # /boot was on /dev/sda3 during installation UUID=08b07f88-6da5-4b40-b062-42b3bb1c5f00 /boot ext2 defaults 0 2 # swap was on /dev/sda5 during installation #UUID=abe3c568-c8fd-4dfb-b8e9-0520d442dd61 none swap sw 0 0 /dev/mapper/cryptswap1 none swap sw 0 0

À mon avis, il y a quelque chose qui cloche dans la configuration de sda5, mais je ne sais pas comment la réparer car elle est configurée pour être cryptée. J'apprécierais de l'aide pour savoir comment procéder.

Redsandro · Accepted Answer

Bug connu

Il existe un bogue (voir ci-dessous) qui écrase UUID pour la partition dès que des données y sont écrites. Par conséquent, vous ne pouvez pas utiliser UUID pour référencer la partition à utiliser pour le swap chiffré.

De nos jours, l'espace d'échange n'est presque jamais utilisé. Sur ma machine, swap n'est utilisé que lorsque j'ouvre mon 40ème onglet. En l'absence d'échange, mon ordinateur commence soudainement à prendre du retard et le navigateur se ferme. Ou, dans le cas du navigateur Chromium, de nombreux onglets vont "mourir" soudainement.
Pour cette raison, référencer /dev/disk/by-uuid/ dans votre /etc/crypttab pourrait sembler fonctionner pendant un certain temps, mais dès que votre espace d'échange est réellement utilisé, il remplace le UUID car toute la partition est utilisée pour le stockage de données cryptées.

Facile Fix

La solution de facilité consiste à référencer la partition de swap par périphérique dans votre /etc/crypttab, par exemple:

cryptswap1 /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

Attention: c'est probablement en sécurité sur un ordinateur portable (je l'utilise comme ça), mais si vous sont sur un ordinateur de bureau avec des lecteurs permutables ou ont d'autres raisons de changer la disposition des lecteurs/partitions, vous ne voulez pas le faire, car une partition de stockage normale pourrait soudainement être utilisée pour le swap.

Remarque: Vous devez redémarrer pour que cette modification soit prise en compte, car ce n'est qu'au démarrage que /dev/mapper/cryptswap1 sera créé.

Correct correct

Pour résoudre ce problème, la meilleure solution consiste à s'assurer que la partie de la partition brute qui stocke UUID n'est pas écrasée par les données d'échange cryptées. Elle sera donc toujours disponible au redémarrage. Cependant, je ne suis pas sûr où est écrit le UUID et combien d'octets il prend. Vous pouvez, à vos risques et périls, le tester comme suit:

cryptswap1 UUID=abe3c568-c8fd-4dfb-b8e9-0520d442dd61 /dev/urandom swap,offset=36,cipher=aes-cbc-essiv:sha256

Notez le offset=36.

S'il vous plaît, si vous avez un compte Ubuntu One , connectez-vous et allez à Bogue n ° 1310058 sur le Launchpad et choisissez (ou cliquez ici). : "Ce bogue m'affecte aussi" donc le bogue gagnera en "popularité" et sera plus sujet aux corrections.

Mise à jour 2014-10-27

Je suis aussi tombé sur cela. Non vérifié par moi. Cela ressemble à une astuce offset avec plus de verbosité et de commentaires sur la reconstruction d'un échange cassé.

https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058/comments/22

DoubleE · Answer

J'avais exactement le même problème dans Ubuntu 14.04 et je suis tombé sur ce fil; ce lien que le mutant fourni a bien fonctionné pour moi. J'ai utilisé la référence /dev/disk/by-id plutôt que/dev/sdXY, car cette référence ne pointe pas toujours vers la même partition physique. Mon /etc/crypttab a fini comme:

cryptswap1 /dev/disk/by-id/wwn-0x500...-part6 /dev/urandom swap, cipher=aes-cbc-essiv:sha256

Serge Stroobandt · Answer

Il suffit d'utiliser un échange non crypté

... et conservez/home crypté

J'ai essayé quelques autres solutions suggérées ici. Même s'ils ont continué à fonctionner après un redémarrage à chaud, ils ont finalement tous échoué après un arrêt et un redémarrage à froid.

Cela nous dit que nous avons en fait affaire à un double bug:

L’UUID du lecteur de remplacement est remplacé par le système de cryptage et
Il y a un problème de délai d'attente lors du démarrage.

Ces réflexions sont également reflétées dans les commentaires au sujet bogue déposé à Launchpad . Cependant, avec le déplacement en attente d'Opstart vers systemd, peu de choses sont faites pour résoudre le bogue sur les systèmes LTS actuels.

À ce stade, les pensées suivantes me traversèrent l'esprit:

Lors de l'installation du système, j'ai demandé à ne chiffrer que ma partition \home, rien d'autre.
Les risques liés au fait de ne pas avoir de partition d'échange cryptée sont plutôt limités.
Il appartient à Canonical de nettoyer leur acte. Je ne perdrai plus de temps avec ça.

Voici donc ma solution pour restaurer le swap en tant que swap normal et non chiffré sans avoir à réinstaller le système d'exploitation dans son intégralité.

Si vous ne l'avez pas déjà fait, installez blkid: $ Sudo apt-get install blkid
Editez /etc/crypttab et supprimez la ligne entière cryptswap1: $ Sudo nano /etc/crypttab
Démarrez GParted à partir du menu Paramètres du système.
Vous verrez une partition avec un point d'exclamation. Cela devrait être la partition d'échange défectueuse. Sélectionnez-le soigneusement et reformatez-le en une partition linux-swap. Après avoir appliqué cette opération, vous êtes informé du nouvel UUID de la partition de swap normale restaurée. Vous avez la possibilité de sauvegarder cette information. Si ce n'est pas le cas, sachez que vous pouvez toujours extraire le nouvel UUID de la ligne de commande avec blkid: $ Sudo blkid
Maintenant, il est temps de restaurer /etc/fstab dans son ancienne gloire: $ Sudo nano /etc/fstab
- Supprimez la ligne entière contenant une référence à /dev/mapper/cryptswap1.
- Supprimez les commentaires de l'ancienne ligne swap en supprimant le hachage # devant UUID=....
- Maintenant, remplacez l'ancien UUID par le nouveau précédemment obtenu.
- Ecrivez le fichier en tapant Ctrl+O et quittez nano avec Ctrl+X.
Une fois tout cela fait, vous pouvez déjà commencer à utiliser le nouveau swap non chiffré avec: $ Sudo swapon -a
Cette solution survit à la fois aux redémarrages à chaud et à l'arrêt avec un redémarrage à froid.

mutant · Answer

Jetez un oeil à this . J'ai résolu ce problème en remplaçant simplement UUID = ... par/dev/sda3 dans/etc/crypttab.

skierpage · Answer

J'ai ce problème, comme les gens de question 332625 . Une combinaison de suspendre et de redémarrer perd l’UUID de votre partition de swap (comme le dit le commentaire dans votre /etc/fstab , confirmez-le avec Sudo blkd). la ligne dans votre /etc/crypttab pour utiliser cet UUID en tant que swap chiffré échoue.

Je n'ai pas de chance en passant /etc/crypttab à utiliser le nom /dev de la partition (/dev/sda6 dans votre cas) ou dev/disk/by-id/ nom au lieu de l’UUID en voie de disparition.

L'abandon de l'échange crypté est malheureusement la solution la plus simple et la meilleure jusqu'à présent.