Partition d'échange non reconnue (le lecteur de disque avec l'UUID = ... n'est pas encore prêt ou n'est pas présent)

Question

Je pense avoir une partition swap chiffrée, car j'ai choisi de chiffrer mon répertoire personnel lors de l'installation. Je crois que c’est la ligne avec /dev/mapper/cryptswap1 ... dans mon /etc/fstab.
J'ai fait quelque chose pour échanger mon échange car au prochain démarrage, j'ai reçu un message (paraphrasé):

Le lecteur de disque pour/dev/mapper/cryptswap1 n'est pas encore prêt ou n'est pas présent. Attendez pour continuer. Appuyez sur S pour ignorer ou sur M pour récupérer manuellement.

(En note de côté, en appuyant sur S ou M semblait ne rien faire d’attente.)
Voici ce que j'ai essayé:
1. Ce tutoriel sur la façon de réparer la partition d'échange non montée. Cependant, dans ce qui précède, la commande mkswap échoue car le périphérique est occupé.
2. J'ai donc démarré à partir d'une clé USB, lancé GParted pour reformater la partition de swap (qui apparaissait comme un type de fs inconnu) et intégré dans le système défectueux pour réessayer ce didacticiel. J'ai également ajusté /etc/initramfs-tools/conf.d/resume et /etc/fstab afin de refléter le nouvel UUID généré par le formatage de la partition en tant que permutation. Cela n'a toujours pas fonctionné. au lieu de /dev/mapper/cryptswap1 non présent, "Le lecteur de disque avec UUID = [UUID de la partition de swap] n'est pas encore prêt ou n'est pas présent ... "
3. J'ai donc décidé de recommencer à zéro, comme si je n'avais jamais créé de partition de swap. Du Live USB, j'ai supprimé la partition de swap (qui, à nouveau, a été identifiée dans GParted sous un type de fs inconnu), puis les entrées swap et cryptswap dans /etc/fstab, ainsi que /etc/initramfs-tools/conf.d/resume et /etc/crypttab. À ce stade, le système principal ne doit pas être considéré comme défectueux, car il n’ya pas de partition swap ni d’instruction pour la monter, n’est-ce pas? Je n'ai pas eu d'erreur au démarrage. J'ai suivi les mêmes instructions pour créer et chiffrer la partition de swap, en commençant par créer une partition pour le swap, bien que je pense que fdisk ait déclaré qu'un redémarrage était nécessaire pour voir les modifications.
J'étais confiant que le troisième processus ci-dessus fonctionnerait, mais le problème persiste encore.

Quelques informations pertinentes (/dev/sda8 est la partition de swap):

Fichier /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> proc /proc proc nodev,noexec,nosuid 0 0 # / was on /dev/sda6 during installation UUID=4c11e82c-5fe9-49d5-92d9-cdaa6865c991 / ext4 errors=remount-ro 0 1 # /boot was on /dev/sda5 during installation UUID=4031413e-e89f-49a9-b54c-e887286bb15e /boot ext4 defaults 0 2 # /home was on /dev/sda7 during installation UUID=d5bbfc6f-482a-464e-9f26-fd213230ae84 /home ext4 defaults 0 2 # swap was on /dev/sda8 during installation UUID=5da2c720-8787-4332-9317-7d96cf1e9b80 none swap sw 0 0 /dev/mapper/cryptswap1 none swap sw 0 0

sortie de Sudo mount:

/dev/sda6 on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/Fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) udev on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755) none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880) none on /run/shm type tmpfs (rw,nosuid,nodev) /dev/sda5 on /boot type ext4 (rw) /dev/sda7 on /home type ext4 (rw) /home/undisclosed/.Private on /home/undisclosed type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=cbae1771abd34009,ecryptfs_fnek_sig=7cefe2f59aab8e58) gvfs-Fuse-daemon on /home/undisclosed/.gvfs type Fuse.gvfs-Fuse-daemon (rw,nosuid,nodev,user=undisclosed)

sortie de Sudo blkid (notez que /dev/sda8 est manquant):

/dev/sda1: LABEL="SYSTEM" UUID="960490E80490CC9D" TYPE="ntfs" /dev/sda2: UUID="D4043140043126C0" TYPE="ntfs" /dev/sda3: LABEL="Shared" UUID="80F613E1F613D5EE" TYPE="ntfs" /dev/sda5: UUID="4031413e-e89f-49a9-b54c-e887286bb15e" TYPE="ext4" /dev/sda6: UUID="4c11e82c-5fe9-49d5-92d9-cdaa6865c991" TYPE="ext4" /dev/sda7: UUID="d5bbfc6f-482a-464e-9f26-fd213230ae84" TYPE="ext4" /dev/mapper/cryptswap1: UUID="41fa147a-3e2c-4e61-b29b-3f240fffbba0" TYPE="swap"

sortie de Sudo fdisk -l:

Disk /dev/mapper/cryptswap1 doesn't contain a valid partition table Disk /dev/sda: 320.1 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders, total 625142448 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: 0xdec3fed2 Device Boot Start End Blocks Id System /dev/sda1 * 2048 409599 203776 7 HPFS/NTFS/exFAT /dev/sda2 409600 210135039 104862720 7 HPFS/NTFS/exFAT /dev/sda3 210135040 415422463 102643712 7 HPFS/NTFS/exFAT /dev/sda4 415424510 625141759 104858625 5 Extended /dev/sda5 415424512 415922175 248832 83 Linux /dev/sda6 415924224 515921919 49998848 83 Linux /dev/sda7 515923968 621389823 52732928 83 Linux /dev/sda8 621391872 625141759 1874944 82 Linux swap / Solaris Disk /dev/mapper/cryptswap1: 1919 MB, 1919942656 bytes 255 heads, 63 sectors/track, 233 cylinders, total 3749888 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: 0xaf5321b5

Fichier /etc/initramfs-tools/conf.d/resume:

RESUME=UUID=5da2c720-8787-4332-9317-7d96cf1e9b80

Fichier /etc/crypttab:

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

sortie de Sudo swapon -as:

Filename Type Size Used Priority /dev/mapper/cryptswap1 partition 1874940 0 -1

sortie de Sudo free -m:

 total used free shared buffers cached Mem: 1476 1296 179 0 35 671 -/+ buffers/cache: 590 886 Swap: 1830 0 1830

Alors, comment cela peut-il être corrigé?

FriendFX · Answer

J'ai eu le même problème lors de l'utilisation d'une partition de swap chiffrée. Ni le message général Swap FAQ , La solution de Puny Geek au message "cryptswap1 n'est pas encore prêt ou n'est pas présent" ni réponse de Braiam à cette question a résolu le problème pour moi - parfois l'échange était disponible, parfois non. Après de nombreux redémarrages et quelques fouilles, je pense avoir trouvé la raison sous-jacente:

Le chemin d'accès à la partition d'échange, tel que /dev/sda3, est parfois différent, par exemple. /dev/sdb3. Étant donné que le fichier /etc/crypttab semble identifier par défaut la partition de swap par ce chemin, il le trouve parfois (si cette partition obtient le même chemin au démarrage) ou non (si la partition reçoit un chemin différent attribué à démarrage).

On dirait que je ne suis pas le seul à avoir ce problème comme décrit ici , une meilleure solution serait de lier la partition de swap via son ID de lecteur au lieu de son chemin /dev/sd*. Cela peut être trouvé en exécutant

ls -l /dev/disk/by-id/

qui répertorie les ID de disque pour toutes les partitions, y compris le swap, qui dans mon cas était

ata-Toshiba_MQ01UBD100_73JATD5GT-part3 -> ../../sdb3

Vérifiez dans un programme comme Utilitaire de disque que la partie -> ../../sdb* de cette ligne est bien la partition que vous avez l'intention d'utiliser pour la permutation, car cela (comme je l'ai dit précédemment) peut parfois changer de nom. Comme toujours, gardez ceci à l'esprit:

Attention: manipuler cryptsetup et les unités de disque est dangereux pour les données et le système d'exploitation. Personnellement, j’ai fait une sauvegarde complète sur un disque séparé, puis je l’aplugged pour m'assurer qu'il ne serait pas impliqué dans un incident.

Puis éditez votre fichier /etc/crypttab en utilisant le lien ID au lieu du chemin "brut", dans mon cas cette ligne est

cryptswap1 /dev/disk/by-id/ata-Toshiba_MQ01UBD100_73JATD5GT-part3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

Je pense que cette méthode devrait être la méthode par défaut pour les nouvelles installations, car on ne peut apparemment jamais être sûr des chemins /dev/sd* ... que je trouve un peu inquiétant car j'ai le sentiment qu'il y a beaucoup plus de scripts et de logiciels sur le marché. qui dépendent toujours de ces chemins (au lieu d’ID, d’étiquettes ou d’UUID) pour rester identiques lors des redémarrages.

TODO:

Je n'ai pas vérifié si la reprise en veille prolongée fonctionnait toujours avec cette configuration, car elle semble s'appuyer sur un UUID (que ma partition de swap n'avait pas), comme indiqué sur cette page: https: // altinukshini .wordpress.com/2012/10/15/devmappercryptswap1-n'est-pas-prêt-encore-ou-pas-présenter /

Mise à jour:

L'hibernation semble bien fonctionner jusqu'à présent. J'espère que cela résoudra ces problèmes pour les autres!

nixahn · Answer

Réponse courte:

Numéro UUID:

Vous devriez avoir ceci dans /etc/crypttab:

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

et cette ligne à la fin de /etc/fstab

/dev/mapper/cryptswap1 none swap sw 0 0

Assurez-vous de ne pas utiliser l'uuid dans le fichier crypttab.

Suspendre le problème:

Utilisons maintenant une astuce pour normaliser le comportement de l’échange juste avant le redémarrage ou l’arrêt:

Créez un script /etc/init.d/cryptswap.sh avec ceci à l'intérieur:

#!/bin/bash /etc/init.d/cryptdisks-early restart

Rendez-le exécutable avec:

Sudo chmod +x /etc/init.d/cryptswap.sh

Pour faire les choses correctement, utilisons des liens et des nombres pour qu’elle s’exécute au bon moment lors du redémarrage ou de l’arrêt:

cd /etc/rc6.d Sudo ln -s ../init.d/cryptswap.sh S10cryptswap.sh cd /etc/rc0.d Sudo ln -s ../init.d/cryptswap.sh S10cryptswap.sh

L’important ici est le chiffre 10 dans le nom car le script doit s’exécuter avant le S40 qui commence à supprimer le swap; même plus tard, un autre script enlèvera les périphériques chiffrés. Le fait est que la séquence d'origine a échoué et nous avons besoin du redémarrage pour que tout se passe bien.

C'est ça!

Remarque: il s’agit d’un hack sale, et il peut arriver que le redémarrage ne soit pas en mesure de réparer ce qui se passe parfois. Quelqu'un parmi les développeurs en charge à la fois du swap et/ou de cryptsetup devrait aller au fond des choses et voir pourquoi, après sa suspension, le swap est laissé dans un état qui fait échouer swapoff /dev/mapper/cryptswap1 et /etc/init.d/cryptdisks-early stop. Si vous exécutez ces commandes, swapoff se plaindra de l'en-tête du fichier d'échange. De plus, vous verrez cryptdisks-early envoyer un "échec" lorsque vous essayez d'arrêter /dev/mapper/cryptswap1.

Redondance/historique:

Au début, je pensais que son problème était lié au comportement du noyau par libblk, probablement un bogue (non prévu). Il semble que le problème est d'avoir une table de partition modifiée par différents "systèmes de fichiers". Le noyau refuse de peupler /dev/disk/by-uuid/ parce qu'il détecte plusieurs signatures de systèmes de fichiers modifiant la table de partitions. Cela semblait important étant donné que le script /usr/bin/ecryptfs-setup-swap utilise UUID pour référencer les entrées qu'il crée pour /etc/crypttab.

Le correctif devrait consister à recréer toutes les partitions du même système de fichiers en démarrant sur un support actif. Voir: http://forums.fedoraforum.org/showthread.php?t=28889

Cependant, cela ne fonctionne pas car ecryptfs/crypttab "reformate" la partition de swap à chaque démarrage; vous ne pouvez pas voir d'uuid pour la partition swap après avoir exécuté ecryptfs-setup-swap et redémarré, car vous n'êtes pas censé le faire. Cela signifie qu'au démarrage, la partition ne sera pas trouvée par crypttab si elle est référencée par uuid, comme indiqué dans l'autre réponse.

Une solution possible consistait à abandonner l’utilisation d’uuids et à simplement les remplacer dans/etc/crypttab par une notation différente: seul/dev/sdXX fonctionne car les autres sont perdus lorsque mkswap est exécuté dans les scripts crypttab. C’est ainsi que les forums suggèrent de résoudre le problème. Cela est nécessaire.

Cela n'a pas fonctionné pleinement cependant. J'ai spéculé qu'il y avait un bug dans crypttab (/etc/rcS.d/S26cryptdisks-early -> /etc/init.d/cryptdisks-early -> /lib/cryptsetup/cryptdisks.functions). Alors je suis allé y creuser et je n'ai rien trouvé. En fait, exécuter /etc/init.d/cryptdisks-early restart fonctionne bien une fois démarré, le lien /dev/mapper/cryptswap1 est généré.

Une solution possible que j'ai vue à ce moment-là consistait à déplacer le swap vers un "fichier" qui occupe tout l'espace de la partition de swap. Ceci est sale, nécessite un point de montage, etc. L'idée est que vous créeriez un fichier de la taille de la partition entière, qui serait monté en tant qu'ext4 normal à/swap, et que vous utiliseriez le fichier crypté en tant que swap. Quelque chose comme ça:

Au format GParted comme ext4; notez que ceci formatera la partition et générera un nouvel UUID; n'utilisez pas Sudo mkswap /dev/sdXX car la partition sera montée automatiquement si elle est marquée comme swap
Sudo mkdir /swap
ls -l /dev/disk/by-uuid/
Sudo gedit /etc/fstab # add UUID=XXXXXXXXXXXXXXXXXXXXXXXXX /swap ext4 defaults 0 2
Sudo mount /dev/sdXX /swap
Sudo dd if=/dev/zero of=/swap/swapfile bs=1024 count=800000
Sudo mkswap /swap/swapfile
Sudo swapon /swap/swapfile
Sudo ecryptfs-setup-swap

Mais je l'ai détesté, donc je ne l'ai pas essayé.

Un autre correctif que j'ai vu consistait à configurer manuellement l'abandon de la génération automatisée de clés aléatoires, comme suit: http://wiki.drewhess.com/wiki/Creating_an_encrypted_filesystem_on_a_partition#External_links

Après avoir un peu exploré la configuration manuelle, j’ai en quelque sorte corrigé les choses en faisant ce que /usr/bin/ecryptfs-setup-swap fait en premier (vérifiez-le pour voir comment cela fonctionne, il ne fait que modifier /etc/crypttab et /etc/fstab), puis manuellement. exécuter le script qui s'exécute au démarrage: /etc/init.d/cryptdisks-early restart; Mais il s'est encore cassé. Repenser le problème de CV, j'ai trouvé le motif. Il se brise au redémarrage qui suit une suspension et reste en panne. Pour le refixer, il faut faire:

Sudo /etc/init.d/cryptdisks-early restart

Après cela, le swap est monté avec succès et sans fil tant que vous ne suspendez pas. C’est de là que vient le script proposé dans la réponse courte.

VanPiro · Answer

J'ai eu le même problème et j'ai trouvé une solution qui a fonctionné pour moi dans ce post .

Fondamentalement:

Fstab ouvert:
```
Sudo gedit /etc/fstab 
```

Changer cette ligne:

/dev/mapper/cryptswap1 none swap sw 0 0

pour ça:

/dev/mapper/cryptswap1 none swap sw,noauto 0 0

Ensuite aller à

Sudo gedit /etc/rc.local

et juste avant

exit 0

ajoutez ces deux lignes:

 sleep 5 swapon /dev/mapper/cryptswap1

Si vous souhaitez ensuite vérifier que votre SWAP est réellement monté et qu'il fonctionne, ouvrez un grand nombre d'applications consommant de la mémoire vive et vérifiez-le via le typage de terminal:

free -m

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é à travailler 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 de ne pas avoir chiffré la partition de swap 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 toute la ligne 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. Sinon, 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 à son ancienne gloire: $ Sudo nano /etc/fstab
- Supprimez la ligne entière contenant une référence à /dev/mapper/cryptswap1.
- Décommentez 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.