device-mapper: suppression d'ioctl sur luks-xxxx a échoué: périphérique ou ressource occupé

28

Pendant que j'étais loin de mon ordinateur, ma clé USB cryptée a été accidentellement démontée d'une manière ou d'une autre (bien qu'elle soit encore physiquement connectée à l'époque). Je n'ai pas pu récupérer (je n'ai pas encore essayé de redémarrer). J'ai maintenant complètement déconnecté le périphérique, mais j'obtiens toujours "Périphérique ou ressource occupé" lorsque j'essaie de supprimer l'entrée pendant dans / dev / mapper. Puis-je reconnecter et monter le disque sans redémarrage?

Voici ce que j'ai essayé (nom long changé en "xxxxx") ...

$ sudo dmsetup ls
luks-xxxxx (252:1)
luks-yyyyy (252:0)

$ sudo umount /dev/mapper/luks-xxxxx
umount: /dev/mapper/luks-xxxxx: not mounted

$ sudo fuser --kill /dev/mapper/luks-xxxxx
$ echo $?
1

$ sudo dmsetup info -c luks-xxxxx
Name       Maj Min Stat Open Targ Event  UUID
luks-xxxxx 252   1 L--w    1    1      0 CRYPT-LUKS1-xxxxx-luks-xxxxx

$ sudo dmsetup remove luks-xxxxx
device-mapper: remove ioctl on luks-xxxx failed: Device or resource busy
Command failed

Après avoir reconnecté l'appareil ...

$ sudo cryptsetup luksOpen "/dev/sde1" "luks-xxxxx"
Device luks-xxxxx already exists.

[MODIFIER] J'ai résolu le problème, cette fois, en fermant un éditeur de texte GUI qui n'avait pas de fichiers ouverts, mais qui avait été lancé à partir d'un dossier sur l'appareil en question. La question devient donc plus précise: comment identifier quelle application maintient l'appareil ouvert?

Gardez à l'esprit que lsofcela ne semble pas constituer une solution facile car, une fois l'appareil déconnecté, les noms associés fournis par lsofn'incluent plus le nom de l'appareil déconnecté.

13.10 luks umount

— nobar
source

Rencontrant le même problème mais sur CentOS. Trouvé ce lien: krenel.org/… mais je ne montre pas l'appareil monté

— Lars Nordin

Semble remarquablement similaire à ce rapport de bogue fermé comme fixe : bugs.debian.org/cgi-bin/bugreport.cgi?bug=574126

— nobar

Avertissement: le montage avec sudo, comme illustré ici, peut vous empêcher d'éjecter normalement à l'aide du gestionnaire de fichiers de l'espace utilisateur.

— nobar

27

Après deux ans de combats avec ça, je pense que je l'ai finalement complètement craqué!

dmsetup ls vous donne les données dont vous avez besoin:

$ sudo dmsetup ls
luks-xxxxx (252:1)

puis

sudo lsof |grep 252,1

Il semble que cela sudopuisse être critique ici - du moins dans certains cas.

Cela devrait vous donner les informations nécessaires pour fermer tous les fichiers ouverts sur l'appareil - y compris les noms des fichiers ouverts et les ID de processus pour les applications incriminées. Vous pouvez peut-être simplement accéder à ces applications et les fermer, mais une approche par force brute pourrait être quelque chose comme:

kill -9 (process ID)

Une fois que vous avez fermé tous les fichiers, certains des outils de ligne de commande présentés dans la question peuvent être nécessaires pour fermer le montage existant avant de le rouvrir normalement.

— nobar
source

4

Remarquez la légère traduction requise: (252:1)devient 252,1.

— nobar

12

Essayez d'arrêter le groupe LVM avant d'arrêter Cypher:

lvchange -a n [LVM_Group_name]

puis

cryptsetup -v luksClose [LUKS_name]

Échantillon:

lvchange -a n My_vg_crypt
cryptsetup -v luksClose My_Crypt

— Anonimo
source

1

Utilisez d' abord la réponse de @ nobar (mais essayez killavant kill -9). Cependant, la solution de @ nobar n'était pas suffisante pour moi - il semble que le noyau lui-même avait le périphérique ouvert à cause des mappages de périphériques LVM - que cette réponse a résolu.

— Tom Hale

+1 Dans mon cas, la réponse acceptée grepn'a trouvé aucune correspondance, mais cela a fonctionné.

— user000001

4

la prochaine fois, essayez un umount paresseux

umount -l /<folder>

Cela fonctionne pour moi la plupart du temps, particulièrement utile avec les lecteurs NFS raccrochés.

— s1mmel
source

J'ai essayé cela, mais je n'ai pas résolu le problème. Je suppose que vous ne pouvez pas réellement utiliser LUKS sur NFS, et que ce n'était qu'une suggestion dans le noir.

— nobar

c'était exactement mon problème, j'ai oublié que je dois d'abord démonter le stockage mappé: D

— holms

2

Voici comment je parviens à résoudre ce problème sur Linux Mint 17.3 (~ Ubuntu Trusty):

supprimer le périphérique du mappeur de périphériques
```
$ sudo dmsetup remove luks-xxyyzz
```

cartographier en arrière

$ sudo cryptsetup open /dev/sdc1 luks-xxyyzz
Enter passphrase for /dev/sdc1:

Maintenant, les appareils sont accessibles.

— Édouard Lopez
source

2

Ce message peut être utile à quelqu'un, mais comme indiqué dans la question - dmsetup removesignale parfois "Échec de la commande".

— nobar

0

J'étais dans une situation similaire, mais je n'ai pas pu résoudre le problème en retirant l' luks-xxxxappareil. Au lieu de cela, j'ai dû retirer ubuntu--vg-root.

Ma situation était:

J'ai accidentellement retiré l'appareil avant qu'il ne soit verrouillé.
Essayer de verrouiller ou de retirer le périphérique luks après l'échec d'un fait avec un occupé message d'erreur .
Le déverrouillage du même appareil a échoué car un appareil du même nom existait déjà.
lsof n'a montré aucune poignée ouverte pour le périphérique.

Ce qui a aidé à débrancher le périphérique physique et à retirer le ubuntu--vg-rootpériphérique avec la commande suivante:

sudo dmsetup remove ubuntu--vg-root

À ce stade, j'ai pu normalement activer et décrypter à nouveau le périphérique externe avec ma configuration habituelle:

udisksctl unlock -b /dev/sda3
sudo lvchange --activate y ubuntu-vg/root

— justfortherec
source