Mise à jour 3:
J'ai décidé de réinstaller le système à partir de zéro pour supprimer toute vieille déchirure qui traînait depuis que j'avais également rencontré d'autres problèmes après la mise à niveau. Cependant, ce problème a persisté.
Sur une installation propre, le choix d'installer à l'aide de "la maison cryptée" conduit à une configuration de swap cryptée cassée.
Mise à jour 2:
J'ai corrigé l'ordre de partage dont cfdisk s'est plaint, mais son 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, le swap ne s'active pas et il ressemble à nouveau à 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
Ma conjecture pour le moment est que lors de la configuration du disque comme étant chiffré, Linux ne reconnaît plus le type de partition et ne le charge donc pas correctement, ce qui ne l'enregistre pas pour son UUID et donc cryptswap ne peut pas le trouver à l'origine de l'échec. Mais je ne sais pas comment y remédier ..
Question mise à jour:
Des tests supplémentaires ont révélé que je pouvais obtenir l'échange en cours d'exécution en exécutant $ mkswap / dev / sda5
puis mettre à jour / etc / crypttab avec l'UUID correct et suivre les étapes décrites ici: Comment configurer un fichier d'échange chiffré?
Cependant, le problème persiste lorsque je redémarre l'ordinateur, le / dev / sda5 n'apparaît pas lorsque j'exécute
$ ls -l /dev/disk/by-uuid/
Si je fais:
$ cfdisk /dev/sda
J'obtiens l'erreur suivante:
FATAL ERROR: Bad logical partition 6: enlarged logical partitions overlap
Press any key to exit cfdisk
L'utilitaire graphique "Disques" ne se plaint d'aucune erreur lors de l'ouverture du disque l'utilisant.
$ 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 d'origine:
Après la mise à niveau vers 14.04 (à partir du 13.04), mon ordinateur a connu de graves ralentissements, lorsque j'ai exécuté top, j'ai remarqué que kswap0 prenait beaucoup de temps processeur. J'ai aussi remarqué que je n'avais pas d'espace de swap!
$ 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
Je suppose qu'il y a quelque chose qui ne va pas dans la configuration de sda5, mais je ne sais pas comment le réparer car il est configuré pour être crypté. J'apprécierais un peu d'aide sur la façon de procéder.
Réponses:
Bug connu
Il existe un bogue (voir ci-dessous) qui écrase
UUID
la partition dès que les données y sont écrites. Par conséquent, vous ne pouvez pas utiliser leUUID
pour référencer la partition à utiliser pour l'échange crypté.De nos jours, l'espace d'échange n'est presque jamais utilisé. Sur ma machine, l'échange n'est utilisé que lorsque j'ouvre mon 40e onglet. Quand je n'ai pas d'échange, soudain mon ordinateur commence à traîner et le navigateur se ferme. Ou dans le cas du
Chromium
navigateur, de nombreux onglets vont soudainement «mourir».Pour cette raison, le référencement
/dev/disk/by-uuid/
dans votre/etc/crypttab
peut sembler fonctionner pendant un certain temps, mais dès que votre espace de swap est réellement utilisé, il remplacera leUUID
car la partition entière est utilisée pour le stockage de données cryptées.Easy Fix
La solution simple consiste à référencer la partition de swap par périphérique dans votre
/etc/crypttab
, par exemple:Avertissement: cela est probablement sans danger sur un ordinateur portable (je l'utilise comme ça), mais si vous êtes sur un bureau avec des lecteurs échangeables ou si vous avez d'autres raisons de changer la disposition du lecteur / de la partition, vous ne voulez pas le faire, en tant que une partition de stockage normale peut soudainement être utilisée pour l'échange.
Remarque: Vous devez redémarrer pour que cette modification prenne effet, car uniquement lorsque le démarrage sera
/dev/mapper/cryptswap1
créé.Correctif correct
La bonne façon de résoudre ce problème est de vous assurer que la partie de la partition brute qui stocke le
UUID
n'est pas remplacée par des données d'échange cryptées, de sorte qu'elle sera toujours là au redémarrage. Cependant, je ne sais pas oùUUID
est écrit le et combien d'octets il prend. Vous pouvez, à vos risques et périls, le tester comme ceci:Notez le
offset=36
.S'il vous plaît, si vous avez un compte Ubuntu One , connectez-vous et accédez au bogue # 1310058 sur Launchpad et choisissez (ou cliquez ici): "Ce bogue m'affecte également", de sorte que le bogue gagnera en popularité et sera plus susceptible d'être corrigé.
Mise à jour 2014-10-27
J'ai également trébuché là-dessus. Non vérifié par moi. Cela ressemble à une
offset
astuce avec plus de verbosité et de commentaires sur la reconstruction d'un swap cassé.https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058/comments/22
la source
J'avais le même problème exact dans Ubuntu 14.04 et suis tombé sur ce fil; ce lien fourni par le mutant a bien fonctionné pour moi. J'ai utilisé la
/dev/disk/by-id
référence plutôt que / dev / sdXY, car cette référence ne pointe pas toujours vers la même partition physique. Mon/etc/crypttab
fini comme:la source
Utilisez simplement un échange non chiffré
... et garder / 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 avec un double bug:
Ces pensées sont également reflétées dans les commentaires sur le bogue correspondant déposé sur Launchpad . Cependant, avec le passage imminent d'Upstart à systemd, peu est fait pour résoudre le bogue sur les systèmes LTS actuels.
À ce stade, les pensées suivantes m'ont traversé l'esprit:
\home
partition, rien d'autre.Voici donc ma solution pour restaurer l'échange comme un échange normal et non chiffré sans avoir à réinstaller tout le système d'exploitation.
blkid
:$ sudo apt-get install blkid
/etc/crypttab
et supprimez toute lacryptswap1
ligne:$ sudo nano /etc/crypttab
linux-swap
partition. 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 ces informations. Si vous ne le faites pas, sachez que vous pouvez toujours récupérer le nouvel UUID à partir de la ligne de commande avecblkid
:$ sudo blkid
Maintenant, il est temps de retrouver
/etc/fstab
son ancienne gloire:$ sudo nano /etc/fstab
/dev/mapper/cryptswap1
.swap
ligne en supprimant le hachage#
devantUUID=...
.nano
avec Ctrl+ X.$ sudo swapon -a
la source
Jetez un oeil à cela . J'ai résolu ce problème en remplaçant simplement UUID = ... par / dev / sda3 dans / etc / crypttab.
la source
sudo fdisk -l
était quelque chose que personne racontait. Merci pour cela! :)/dev/sd*
chemins peuvent changer sur un coup de tête et entraîner la destruction de la mauvaise partition par les données d'échange./dev/disk/by-id
est supérieur.J'ai ce problème, tout comme les personnes en question 332625 . Une combinaison de suspension et de redémarrage perd l'UUID de votre partition de swap (comme le dit le commentaire dans votre / etc / fstab , confirmez-le avec
sudo blkd
), donc la ligne dans votre / etc / crypttab pour utiliser cet UUID comme swap crypté échoue.Je n'ai aucune chance de changer / etc / crypttab pour utiliser le
/dev
nom de la partition ( / dev / sda6 dans votre cas) ou ledev/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.
la source