Mailing List Archive

cryptsetup close and device in use when it is not
Howdy,

As some may recall, I use external drives as backups.  They are
encrypted and I use cryptsetup to open and close them.  Open works fine
but close gives me trouble at times.  It doesn't always do this but it
does it more often than not.  It's getting annoying. 

Drive one.  It's a 6TB drive and when it gave this error a few minutes
ago, I restarted udev-trigger to correct it.  When I try to close it, it
says it is in use.  But restarting udev-trigger reset it so I could
close it. 

Drive two, when I tried to close it, it gives me this:


root@fireball / # cryptsetup close 8tb
Device 8tb is still in use.
root@fireball / # mount | grep 8tb
root@fireball / #


As you can tell, it is not mounted.  When I mount, I do it manually from
a fstab entry.  I just do mount /mnt/8tb and it mounts it.  I use umount
to unmount it.  Old school but it works.  Thing is, for some reason it
shows it is in use even tho it is not mounted.  Even restarting
udev-trigger didn't work this time.  I can't figure out what is doing it
exactly and think it is something besides cryptsetup having a problem. 
I'm actually thinking udev for this reason.  I do my backups while I'm
updating the OS.  When I do my updates, all my firefox profiles are
closed and I'm not downloading new files.  So that is when I do my
backups.  Last time it did this, I went to boot runlevel and restarted
udev itself.  That reset it so I could close the drive and cut it off. 
Thing is, I'd like a proper fix for this or a good sound way to reset it
without having to do all that.  Sometimes all I need is to logout and
back in after updates.  Restarting udev and such shouldn't be required.

If it matters, both drives are in identical enclosures and use the same
cable and power source.  One is a SMR and the other a CMR.  One is 6TB
and one is 8TB.  Both are encrypted the same way.  Both use eSATA, not
USB.  I used USB before and it may have been the enclosure but it ruined
drives.  I could never depend on it so I switched to eSATA. 

So, anyone else run into this and have a solution for it?  Do I have
something set up wrong or is this a bug in some package somewhere?  I've
googled and seen where others have the problem but their solutions don't
seem to work and most are very old posts. 

Need some ideas and thoughts here.

Thanks.

Dale

:-)  :-) 

P. S.  I took some meds so I hope the above makes sense.  The meds are
working well right now but I need to close the drive so I can put it
back in the safe.  :/
Re: cryptsetup close and device in use when it is not [ In reply to ]
Hello Dale,

this also happens to me sometimes and the culprit was an open process
still accessing the hard drive. Maybe you can solve it like this:

$ lsof /mnt/8tb
zsh       8390 root  cwd    DIR  253,2      4096 27787265 /mnt/8tb
$ kill 8390
$ lsof /mnt/8tb

After that, you should be able to close the drive via "cryptsetup".

-Ramon

On 14/06/2021 06:50, Dale wrote:
> root@fireball / # cryptsetup close 8tb
> Device 8tb is still in use.
> root@fireball / # mount | grep 8tb
> root@fireball / #

--
GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF
Re: cryptsetup close and device in use when it is not [ In reply to ]
Ramon Fischer wrote:
> Hello Dale,
>
> this also happens to me sometimes and the culprit was an open process
> still accessing the hard drive. Maybe you can solve it like this:
>
>    $ lsof /mnt/8tb
>    zsh       8390 root  cwd    DIR  253,2      4096 27787265 /mnt/8tb
>    $ kill 8390
>    $ lsof /mnt/8tb
>
> After that, you should be able to close the drive via "cryptsetup".
>
> -Ramon
>
> On 14/06/2021 06:50, Dale wrote:
>> root@fireball / # cryptsetup close 8tb
>> Device 8tb is still in use.
>> root@fireball / # mount | grep 8tb
>> root@fireball / #
>


I've tried lsof before, for both mount point and device, it shows
nothing open.  It's weird. 

When this happened last night, just before I posted, I let the drive sit
there while I was doing updates.  Later on, I tried to close it again
and it closed just fine.  I hadn't done anything except let it sit
there.  While I was glad it closed, I wonder why it did it.  Did udev
finally catch up to the state of the drive?  Did some other device
update and allow it to close? 

This is weird.  Everything says it is ready to be closed but it thinks
something is open.  I'm not sure what to point too for the problem.  Yet
anyway. 

Thanks for the tip.  It was worth mentioning.

Dale

:-)  :-)
Re: cryptsetup close and device in use when it is not [ In reply to ]
On 6/15/21 10:21 AM, Dale wrote:
> Ramon Fischer wrote:
>> Hello Dale,
>>
>> this also happens to me sometimes and the culprit was an open process
>> still accessing the hard drive. Maybe you can solve it like this:
>>
>>    $ lsof /mnt/8tb
>>    zsh       8390 root  cwd    DIR  253,2      4096 27787265 /mnt/8tb
>>    $ kill 8390
>>    $ lsof /mnt/8tb
>>
>> After that, you should be able to close the drive via "cryptsetup".
>>
>> -Ramon
>>
>> On 14/06/2021 06:50, Dale wrote:
>>> root@fireball / # cryptsetup close 8tb
>>> Device 8tb is still in use.
>>> root@fireball / # mount | grep 8tb
>>> root@fireball / #
> I've tried lsof before, for both mount point and device, it shows
> nothing open.  It's weird.
>
> When this happened last night, just before I posted, I let the drive sit
> there while I was doing updates.  Later on, I tried to close it again
> and it closed just fine.  I hadn't done anything except let it sit
> there.  While I was glad it closed, I wonder why it did it.  Did udev
> finally catch up to the state of the drive?  Did some other device
> update and allow it to close?
>
> This is weird.  Everything says it is ready to be closed but it thinks
> something is open.  I'm not sure what to point too for the problem.  Yet
> anyway.
>
> Thanks for the tip.  It was worth mentioning.
>
> Dale

Is it possible it was still syncing cache out to the physical drive?  I
wonder if iotop would show any activity for that drive if that's the case?

Jack
Re: cryptsetup close and device in use when it is not [ In reply to ]
Jack wrote:
> On 6/15/21 10:21 AM, Dale wrote:
>> Ramon Fischer wrote:
>>> Hello Dale,
>>>
>>> this also happens to me sometimes and the culprit was an open process
>>> still accessing the hard drive. Maybe you can solve it like this:
>>>
>>>     $ lsof /mnt/8tb
>>>     zsh       8390 root  cwd    DIR  253,2      4096 27787265 /mnt/8tb
>>>     $ kill 8390
>>>     $ lsof /mnt/8tb
>>>
>>> After that, you should be able to close the drive via "cryptsetup".
>>>
>>> -Ramon
>>>
>>> On 14/06/2021 06:50, Dale wrote:
>>>> root@fireball / # cryptsetup close 8tb
>>>> Device 8tb is still in use.
>>>> root@fireball / # mount | grep 8tb
>>>> root@fireball / #
>> I've tried lsof before, for both mount point and device, it shows
>> nothing open.  It's weird.
>>
>> When this happened last night, just before I posted, I let the drive sit
>> there while I was doing updates.  Later on, I tried to close it again
>> and it closed just fine.  I hadn't done anything except let it sit
>> there.  While I was glad it closed, I wonder why it did it.  Did udev
>> finally catch up to the state of the drive?  Did some other device
>> update and allow it to close?
>>
>> This is weird.  Everything says it is ready to be closed but it thinks
>> something is open.  I'm not sure what to point too for the problem.  Yet
>> anyway.
>>
>> Thanks for the tip.  It was worth mentioning.
>>
>> Dale
>
> Is it possible it was still syncing cache out to the physical drive? 
> I wonder if iotop would show any activity for that drive if that's the
> case?
>
> Jack
>
>
>


I may try that next time but the light had stopped blinking for several
minutes.  Since it is a SMR drive, I always leave it running until I
can't feel the heads bumping around.  I don't think it would be that
but, it's worth a try. It may lead to something. 

Will update when it does it again. 

Thanks.

Dale

:-)  :-) 
Re: cryptsetup close and device in use when it is not [ In reply to ]
Dale wrote on 15/06/2021 16:21:
> Ramon Fischer wrote:
>> Hello Dale,
>>
>> this also happens to me sometimes and the culprit was an open process
>> still accessing the hard drive. Maybe you can solve it like this:
>>
>>    $ lsof /mnt/8tb
>>    zsh       8390 root  cwd    DIR  253,2      4096 27787265 /mnt/8tb
>>    $ kill 8390
>>    $ lsof /mnt/8tb
>>
>> After that, you should be able to close the drive via "cryptsetup".
>>
>> -Ramon
>>
>
> I've tried lsof before, for both mount point and device, it shows
> nothing open.  It's weird.

When this happens here, it's because I accessed the drive over NFS. The NFS server sometimes
keeps mount points active, and they don't show up in the output of lsof probably because the NFS
server is in-kernel, so there are no processes associated with it. Restarting the NFS server
allows unmounting.

-- Remy
Re: cryptsetup close and device in use when it is not [ In reply to ]
If the "umount" command seems to be hanging next time, it is most likely
due to cache writebacks. You can monitor this like so:

$ watch "grep 'Dirty\|Writeback' /proc/meminfo"

-Ramon

On 15/06/2021 17:26, Dale wrote:
> Jack wrote:
>> On 6/15/21 10:21 AM, Dale wrote:
>>> Ramon Fischer wrote:
>>>> Hello Dale,
>>>>
>>>> this also happens to me sometimes and the culprit was an open process
>>>> still accessing the hard drive. Maybe you can solve it like this:
>>>>
>>>>     $ lsof /mnt/8tb
>>>>     zsh       8390 root  cwd    DIR  253,2      4096 27787265 /mnt/8tb
>>>>     $ kill 8390
>>>>     $ lsof /mnt/8tb
>>>>
>>>> After that, you should be able to close the drive via "cryptsetup".
>>>>
>>>> -Ramon
>>>>
>>>> On 14/06/2021 06:50, Dale wrote:
>>>>> root@fireball / # cryptsetup close 8tb
>>>>> Device 8tb is still in use.
>>>>> root@fireball / # mount | grep 8tb
>>>>> root@fireball / #
>>> I've tried lsof before, for both mount point and device, it shows
>>> nothing open.  It's weird.
>>>
>>> When this happened last night, just before I posted, I let the drive sit
>>> there while I was doing updates.  Later on, I tried to close it again
>>> and it closed just fine.  I hadn't done anything except let it sit
>>> there.  While I was glad it closed, I wonder why it did it.  Did udev
>>> finally catch up to the state of the drive?  Did some other device
>>> update and allow it to close?
>>>
>>> This is weird.  Everything says it is ready to be closed but it thinks
>>> something is open.  I'm not sure what to point too for the problem.  Yet
>>> anyway.
>>>
>>> Thanks for the tip.  It was worth mentioning.
>>>
>>> Dale
>> Is it possible it was still syncing cache out to the physical drive?
>> I wonder if iotop would show any activity for that drive if that's the
>> case?
>>
>> Jack
>>
>>
>>
>
> I may try that next time but the light had stopped blinking for several
> minutes.  Since it is a SMR drive, I always leave it running until I
> can't feel the heads bumping around.  I don't think it would be that
> but, it's worth a try. It may lead to something.
>
> Will update when it does it again.
>
> Thanks.
>
> Dale
>
> :-)  :-)
>

--
GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF
Re: cryptsetup close and device in use when it is not [ In reply to ]
Dale wrote:
> Jack wrote:
>>
>> Is it possible it was still syncing cache out to the physical drive? 
>> I wonder if iotop would show any activity for that drive if that's the
>> case?
>>
>> Jack
>>
>>
>>
>
> I may try that next time but the light had stopped blinking for several
> minutes.  Since it is a SMR drive, I always leave it running until I
> can't feel the heads bumping around.  I don't think it would be that
> but, it's worth a try. It may lead to something. 
>
> Will update when it does it again. 
>
> Thanks.
>
> Dale
>
> :-)  :-) 
>


I had to wait until I was doing backups again to try anything.  The 6TB
drive did fine.  The 8TB drive is giving the in use error.  The drive is
unmounted but iotop didn't show anything and the light isn't blinking
either.  I'd think if it was flushing cache the light would flash and it
would not umount. 

I tried the udev-trigger trick but it didn't work.  I don't know how
long it will stay 'in use' so if anyone has ideas, think and type fast. 
If not, may have to wait until next time to try again.

Dale

:-)  :-) 
Re: cryptsetup close and device in use when it is not [ In reply to ]
Dale wrote:
> Dale wrote:
>> Jack wrote:
>>> Is it possible it was still syncing cache out to the physical drive? 
>>> I wonder if iotop would show any activity for that drive if that's the
>>> case?
>>>
>>> Jack
>>>
>>>
>>>
>> I may try that next time but the light had stopped blinking for several
>> minutes.  Since it is a SMR drive, I always leave it running until I
>> can't feel the heads bumping around.  I don't think it would be that
>> but, it's worth a try. It may lead to something. 
>>
>> Will update when it does it again. 
>>
>> Thanks.
>>
>> Dale
>>
>> :-)  :-) 
>>
>
> I had to wait until I was doing backups again to try anything.  The 6TB
> drive did fine.  The 8TB drive is giving the in use error.  The drive is
> unmounted but iotop didn't show anything and the light isn't blinking
> either.  I'd think if it was flushing cache the light would flash and it
> would not umount. 
>
> I tried the udev-trigger trick but it didn't work.  I don't know how
> long it will stay 'in use' so if anyone has ideas, think and type fast. 
> If not, may have to wait until next time to try again.
>
> Dale
>
> :-)  :-) 
>


Some more info:


root@fireball / # lvs
  LV     VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log
Cpy%Sync Convert
  Home2  Home2  -wi-ao----
<12.74t                                                   
  swap   OS     -wi-ao---- 
12.00g                                                   
  usr    OS     -wi-ao---- 
35.00g                                                   
  var    OS     -wi-ao---- 
52.00g                                                   
  backup backup -wi-ao----
698.63g                                                   
root@fireball / # vgs
  VG     #PV #LV #SN Attr   VSize    VFree 
  Home2    2   1   0 wz--n-  <12.74t      0
  OS       1   3   0 wz--n- <124.46g <25.46g
  backup   1   1   0 wz--n-  698.63g      0
root@fireball / # pvs
  PV         VG     Fmt  Attr PSize    PFree 
  /dev/sda7  OS     lvm2 a--  <124.46g <25.46g
  /dev/sdb1  Home2  lvm2 a--    <5.46t      0
  /dev/sdc1  Home2  lvm2 a--    <7.28t      0
  /dev/sdd1  backup lvm2 a--   698.63g      0
root@fireball / # cryptsetup close 8tb
Device 8tb is still in use.
root@fireball / #


As you can see, lvm doesn't even show the device but it is still under
/dev as tho it is available.  Weird. 

I found this but at the end, the command doesn't help me.  I'm not sure
why.  It does talk about using LUKS on top of LVM causing this problem. 
Since the fix doesn't work, is this a different problem??


https://linux-blog.anracom.com/tag/device-still-in-use/


I've tried every command I can find and it still shows busy.  I even
restarted udev and lvm.  Still busy. 

Ideas?

Dale

:-)  :-) 
Re: cryptsetup close and device in use when it is not [ In reply to ]
Dale wrote:
> Dale wrote:
>> Dale wrote:
>>> Jack wrote:
>>>> Is it possible it was still syncing cache out to the physical drive? 
>>>> I wonder if iotop would show any activity for that drive if that's the
>>>> case?
>>>>
>>>> Jack
>>>>
>>>>
>>>>
>>> I may try that next time but the light had stopped blinking for several
>>> minutes.  Since it is a SMR drive, I always leave it running until I
>>> can't feel the heads bumping around.  I don't think it would be that
>>> but, it's worth a try. It may lead to something. 
>>>
>>> Will update when it does it again. 
>>>
>>> Thanks.
>>>
>>> Dale
>>>
>>> :-)  :-) 
>>>
>> I had to wait until I was doing backups again to try anything.  The 6TB
>> drive did fine.  The 8TB drive is giving the in use error.  The drive is
>> unmounted but iotop didn't show anything and the light isn't blinking
>> either.  I'd think if it was flushing cache the light would flash and it
>> would not umount. 
>>
>> I tried the udev-trigger trick but it didn't work.  I don't know how
>> long it will stay 'in use' so if anyone has ideas, think and type fast. 
>> If not, may have to wait until next time to try again.
>>
>> Dale
>>
>> :-)  :-) 
>>
>
> Some more info:
>
>
> root@fireball / # lvs
>   LV     VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log
> Cpy%Sync Convert
>   Home2  Home2  -wi-ao----
> <12.74t                                                   
>   swap   OS     -wi-ao---- 
> 12.00g                                                   
>   usr    OS     -wi-ao---- 
> 35.00g                                                   
>   var    OS     -wi-ao---- 
> 52.00g                                                   
>   backup backup -wi-ao----
> 698.63g                                                   
> root@fireball / # vgs
>   VG     #PV #LV #SN Attr   VSize    VFree 
>   Home2    2   1   0 wz--n-  <12.74t      0
>   OS       1   3   0 wz--n- <124.46g <25.46g
>   backup   1   1   0 wz--n-  698.63g      0
> root@fireball / # pvs
>   PV         VG     Fmt  Attr PSize    PFree 
>   /dev/sda7  OS     lvm2 a--  <124.46g <25.46g
>   /dev/sdb1  Home2  lvm2 a--    <5.46t      0
>   /dev/sdc1  Home2  lvm2 a--    <7.28t      0
>   /dev/sdd1  backup lvm2 a--   698.63g      0
> root@fireball / # cryptsetup close 8tb
> Device 8tb is still in use.
> root@fireball / #
>
>
> As you can see, lvm doesn't even show the device but it is still under
> /dev as tho it is available.  Weird. 
>
> I found this but at the end, the command doesn't help me.  I'm not sure
> why.  It does talk about using LUKS on top of LVM causing this problem. 
> Since the fix doesn't work, is this a different problem??
>
>
> https://linux-blog.anracom.com/tag/device-still-in-use/
>
>
> I've tried every command I can find and it still shows busy.  I even
> restarted udev and lvm.  Still busy. 
>
> Ideas?
>
> Dale
>
> :-)  :-) 
>


Found another tidbit of info that may shed some light on this problem. 
I'm not sure what it means tho.



root@fireball / # lsblk
NAME              MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
<<<SNIP>>>
sdj                 8:144  1   7.3T  0 disk 
??sdj1              8:145  1   7.3T  0 part 
  ??8tb           254:5    0   7.3T  0 crypt /mnt/8tb
sr0                11:0    1  1024M  0 rom  
root@fireball / #


So, something called crypt seems to have it open.  Now how do I tell it
to go away?  Hmmmm.  Then I came up with this idea:


root@fireball / # ps aux | grep crypt
root       493  0.0  0.0      0     0 ?        I<   Jun13   0:00 [cryptd]
root     11509  0.0  0.0   7728  2448 pts/2    S+   00:30   0:00 grep
--colour=auto crypt
root     23667  0.0  0.0      0     0 ?        I<   Jun20   0:00
[kcryptd_io/254:]
root     23668  0.0  0.0      0     0 ?        I<   Jun20   0:00
[kcryptd/254:5]
root     23669  0.0  0.0      0     0 ?        S    Jun20   0:00
[dmcrypt_write/2]
root@fireball / #


So kcryptd is the offender it seems since it matches MAJ:MIN info.  I
assume that is kernel related not KDE.  Can I just kill that process? 
Will it do damage if I kill it or is there a better way? 

Dale

:-)  :-) 
Re: cryptsetup close and device in use when it is not [ In reply to ]
Dale wrote:
> Dale wrote:
>> Dale wrote:
>>> Dale wrote:
>>>> Jack wrote:
>>>>> Is it possible it was still syncing cache out to the physical drive? 
>>>>> I wonder if iotop would show any activity for that drive if that's the
>>>>> case?
>>>>>
>>>>> Jack
>>>>>
>>>>>
>>>>>
>>>> I may try that next time but the light had stopped blinking for several
>>>> minutes.  Since it is a SMR drive, I always leave it running until I
>>>> can't feel the heads bumping around.  I don't think it would be that
>>>> but, it's worth a try. It may lead to something. 
>>>>
>>>> Will update when it does it again. 
>>>>
>>>> Thanks.
>>>>
>>>> Dale
>>>>
>>>> :-)  :-) 
>>>>
>>> I had to wait until I was doing backups again to try anything.  The 6TB
>>> drive did fine.  The 8TB drive is giving the in use error.  The drive is
>>> unmounted but iotop didn't show anything and the light isn't blinking
>>> either.  I'd think if it was flushing cache the light would flash and it
>>> would not umount. 
>>>
>>> I tried the udev-trigger trick but it didn't work.  I don't know how
>>> long it will stay 'in use' so if anyone has ideas, think and type fast. 
>>> If not, may have to wait until next time to try again.
>>>
>>> Dale
>>>
>>> :-)  :-) 
>>>
>> Some more info:
>>
>>
>> root@fireball / # lvs
>>   LV     VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log
>> Cpy%Sync Convert
>>   Home2  Home2  -wi-ao----
>> <12.74t                                                   
>>   swap   OS     -wi-ao---- 
>> 12.00g                                                   
>>   usr    OS     -wi-ao---- 
>> 35.00g                                                   
>>   var    OS     -wi-ao---- 
>> 52.00g                                                   
>>   backup backup -wi-ao----
>> 698.63g                                                   
>> root@fireball / # vgs
>>   VG     #PV #LV #SN Attr   VSize    VFree 
>>   Home2    2   1   0 wz--n-  <12.74t      0
>>   OS       1   3   0 wz--n- <124.46g <25.46g
>>   backup   1   1   0 wz--n-  698.63g      0
>> root@fireball / # pvs
>>   PV         VG     Fmt  Attr PSize    PFree 
>>   /dev/sda7  OS     lvm2 a--  <124.46g <25.46g
>>   /dev/sdb1  Home2  lvm2 a--    <5.46t      0
>>   /dev/sdc1  Home2  lvm2 a--    <7.28t      0
>>   /dev/sdd1  backup lvm2 a--   698.63g      0
>> root@fireball / # cryptsetup close 8tb
>> Device 8tb is still in use.
>> root@fireball / #
>>
>>
>> As you can see, lvm doesn't even show the device but it is still under
>> /dev as tho it is available.  Weird. 
>>
>> I found this but at the end, the command doesn't help me.  I'm not sure
>> why.  It does talk about using LUKS on top of LVM causing this problem. 
>> Since the fix doesn't work, is this a different problem??
>>
>>
>> https://linux-blog.anracom.com/tag/device-still-in-use/
>>
>>
>> I've tried every command I can find and it still shows busy.  I even
>> restarted udev and lvm.  Still busy. 
>>
>> Ideas?
>>
>> Dale
>>
>> :-)  :-) 
>>
>
> Found another tidbit of info that may shed some light on this problem. 
> I'm not sure what it means tho.
>
>
>
> root@fireball / # lsblk
> NAME              MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
> <<<SNIP>>>
> sdj                 8:144  1   7.3T  0 disk 
> ??sdj1              8:145  1   7.3T  0 part 
>   ??8tb           254:5    0   7.3T  0 crypt /mnt/8tb
> sr0                11:0    1  1024M  0 rom  
> root@fireball / #
>
>
> So, something called crypt seems to have it open.  Now how do I tell it
> to go away?  Hmmmm.  Then I came up with this idea:
>
>
> root@fireball / # ps aux | grep crypt
> root       493  0.0  0.0      0     0 ?        I<   Jun13   0:00 [cryptd]
> root     11509  0.0  0.0   7728  2448 pts/2    S+   00:30   0:00 grep
> --colour=auto crypt
> root     23667  0.0  0.0      0     0 ?        I<   Jun20   0:00
> [kcryptd_io/254:]
> root     23668  0.0  0.0      0     0 ?        I<   Jun20   0:00
> [kcryptd/254:5]
> root     23669  0.0  0.0      0     0 ?        S    Jun20   0:00
> [dmcrypt_write/2]
> root@fireball / #
>
>
> So kcryptd is the offender it seems since it matches MAJ:MIN info.  I
> assume that is kernel related not KDE.  Can I just kill that process? 
> Will it do damage if I kill it or is there a better way? 
>
> Dale
>
> :-)  :-) 
>


After staring at it a while, it hit me that lsblk is showing it as still
mounted, even tho I umounted already without error.  So, I just ran the
umount command again.  After that, it closed just fine.  So, it seems to
be mounted twice, not once.  I mount using this command 'mount /mnt/8tb'
which uses fstab to mount the correct UUID device to that mount point. 
Surely it only mounts once.  Always has in the past.  So why is it being
mounted twice now?  None of my scripts used for backups includes any
mounting commands.  There's also only one entry in fstab as well. 

Anyone have any idea while it gets mounted twice?  Does the cryptsetup
open command mount it in some way and then I mount it manually as well??
When I opened it just now, it didn't show anything as mounted.  So it
doesn't appear to be the open command.  What else could it be??

Ideas? 

Dale

:-)  :-) 
Re: cryptsetup close and device in use when it is not [ In reply to ]
Dale wrote:
> Dale wrote:
>> Dale wrote:
>>> Dale wrote:
>>>> Dale wrote:
>>>>> Jack wrote:
>>>>>> Is it possible it was still syncing cache out to the physical drive? 
>>>>>> I wonder if iotop would show any activity for that drive if that's the
>>>>>> case?
>>>>>>
>>>>>> Jack
>>>>>>
>>>>>>
>>>>>>
>>>>> I may try that next time but the light had stopped blinking for several
>>>>> minutes.  Since it is a SMR drive, I always leave it running until I
>>>>> can't feel the heads bumping around.  I don't think it would be that
>>>>> but, it's worth a try. It may lead to something. 
>>>>>
>>>>> Will update when it does it again. 
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Dale
>>>>>
>>>>> :-)  :-) 
>>>>>
>>>> I had to wait until I was doing backups again to try anything.  The 6TB
>>>> drive did fine.  The 8TB drive is giving the in use error.  The drive is
>>>> unmounted but iotop didn't show anything and the light isn't blinking
>>>> either.  I'd think if it was flushing cache the light would flash and it
>>>> would not umount. 
>>>>
>>>> I tried the udev-trigger trick but it didn't work.  I don't know how
>>>> long it will stay 'in use' so if anyone has ideas, think and type fast. 
>>>> If not, may have to wait until next time to try again.
>>>>
>>>> Dale
>>>>
>>>> :-)  :-) 
>>>>
>>> Some more info:
>>>
>>>
>>> root@fireball / # lvs
>>>   LV     VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log
>>> Cpy%Sync Convert
>>>   Home2  Home2  -wi-ao----
>>> <12.74t                                                   
>>>   swap   OS     -wi-ao---- 
>>> 12.00g                                                   
>>>   usr    OS     -wi-ao---- 
>>> 35.00g                                                   
>>>   var    OS     -wi-ao---- 
>>> 52.00g                                                   
>>>   backup backup -wi-ao----
>>> 698.63g                                                   
>>> root@fireball / # vgs
>>>   VG     #PV #LV #SN Attr   VSize    VFree 
>>>   Home2    2   1   0 wz--n-  <12.74t      0
>>>   OS       1   3   0 wz--n- <124.46g <25.46g
>>>   backup   1   1   0 wz--n-  698.63g      0
>>> root@fireball / # pvs
>>>   PV         VG     Fmt  Attr PSize    PFree 
>>>   /dev/sda7  OS     lvm2 a--  <124.46g <25.46g
>>>   /dev/sdb1  Home2  lvm2 a--    <5.46t      0
>>>   /dev/sdc1  Home2  lvm2 a--    <7.28t      0
>>>   /dev/sdd1  backup lvm2 a--   698.63g      0
>>> root@fireball / # cryptsetup close 8tb
>>> Device 8tb is still in use.
>>> root@fireball / #
>>>
>>>
>>> As you can see, lvm doesn't even show the device but it is still under
>>> /dev as tho it is available.  Weird. 
>>>
>>> I found this but at the end, the command doesn't help me.  I'm not sure
>>> why.  It does talk about using LUKS on top of LVM causing this problem. 
>>> Since the fix doesn't work, is this a different problem??
>>>
>>>
>>> https://linux-blog.anracom.com/tag/device-still-in-use/
>>>
>>>
>>> I've tried every command I can find and it still shows busy.  I even
>>> restarted udev and lvm.  Still busy. 
>>>
>>> Ideas?
>>>
>>> Dale
>>>
>>> :-)  :-) 
>>>
>> Found another tidbit of info that may shed some light on this problem. 
>> I'm not sure what it means tho.
>>
>>
>>
>> root@fireball / # lsblk
>> NAME              MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
>> <<<SNIP>>>
>> sdj                 8:144  1   7.3T  0 disk 
>> ??sdj1              8:145  1   7.3T  0 part 
>>   ??8tb           254:5    0   7.3T  0 crypt /mnt/8tb
>> sr0                11:0    1  1024M  0 rom  
>> root@fireball / #
>>
>>
>> So, something called crypt seems to have it open.  Now how do I tell it
>> to go away?  Hmmmm.  Then I came up with this idea:
>>
>>
>> root@fireball / # ps aux | grep crypt
>> root       493  0.0  0.0      0     0 ?        I<   Jun13   0:00 [cryptd]
>> root     11509  0.0  0.0   7728  2448 pts/2    S+   00:30   0:00 grep
>> --colour=auto crypt
>> root     23667  0.0  0.0      0     0 ?        I<   Jun20   0:00
>> [kcryptd_io/254:]
>> root     23668  0.0  0.0      0     0 ?        I<   Jun20   0:00
>> [kcryptd/254:5]
>> root     23669  0.0  0.0      0     0 ?        S    Jun20   0:00
>> [dmcrypt_write/2]
>> root@fireball / #
>>
>>
>> So kcryptd is the offender it seems since it matches MAJ:MIN info.  I
>> assume that is kernel related not KDE.  Can I just kill that process? 
>> Will it do damage if I kill it or is there a better way? 
>>
>> Dale
>>
>> :-)  :-) 
>>
>
> After staring at it a while, it hit me that lsblk is showing it as still
> mounted, even tho I umounted already without error.  So, I just ran the
> umount command again.  After that, it closed just fine.  So, it seems to
> be mounted twice, not once.  I mount using this command 'mount /mnt/8tb'
> which uses fstab to mount the correct UUID device to that mount point. 
> Surely it only mounts once.  Always has in the past.  So why is it being
> mounted twice now?  None of my scripts used for backups includes any
> mounting commands.  There's also only one entry in fstab as well. 
>
> Anyone have any idea while it gets mounted twice?  Does the cryptsetup
> open command mount it in some way and then I mount it manually as well??
> When I opened it just now, it didn't show anything as mounted.  So it
> doesn't appear to be the open command.  What else could it be??
>
> Ideas? 
>
> Dale
>
> :-)  :-) 
>


The same drive just did it again.  I had to reboot to get it to reset. 
This is Linux not windoze.  Rebooting to reset something like that is
plain ridiculous.  I also checked, this time it was mounted only once. 
When I tried to umount it again, it said it wasn't mounted.  The thing
that really gets me, nothing can tell me what it is that is using the
device.  It says it is in use but no clue what it is using it. 

To test a theory, I changed fstab to mount by label instead of UUID. 
Maybe that will change something.  I dunno.  I do know, if this doesn't
improve soon, I'm going to erase the drive and either find another
encryption tool or just not encrypt it at all.  I'm not rebooting every
time this thing wants to act ugly.  I'm used to rebooting like every 6
months or so.  Usually when the power fails. 

If anyone has any ideas, please post.  In the meantime, I'm going to try
this mounting by label idea. 

Dale

:-)  :-)
Re: cryptsetup close and device in use when it is not [ In reply to ]
Dale wrote:
> Dale wrote:
>>
>> After staring at it a while, it hit me that lsblk is showing it as still
>> mounted, even tho I umounted already without error.  So, I just ran the
>> umount command again.  After that, it closed just fine.  So, it seems to
>> be mounted twice, not once.  I mount using this command 'mount /mnt/8tb'
>> which uses fstab to mount the correct UUID device to that mount point. 
>> Surely it only mounts once.  Always has in the past.  So why is it being
>> mounted twice now?  None of my scripts used for backups includes any
>> mounting commands.  There's also only one entry in fstab as well. 
>>
>> Anyone have any idea while it gets mounted twice?  Does the cryptsetup
>> open command mount it in some way and then I mount it manually as well??
>> When I opened it just now, it didn't show anything as mounted.  So it
>> doesn't appear to be the open command.  What else could it be??
>>
>> Ideas? 
>>
>> Dale
>>
>> :-)  :-) 
>>
>
> The same drive just did it again.  I had to reboot to get it to reset. 
> This is Linux not windoze.  Rebooting to reset something like that is
> plain ridiculous.  I also checked, this time it was mounted only once. 
> When I tried to umount it again, it said it wasn't mounted.  The thing
> that really gets me, nothing can tell me what it is that is using the
> device.  It says it is in use but no clue what it is using it. 
>
> To test a theory, I changed fstab to mount by label instead of UUID. 
> Maybe that will change something.  I dunno.  I do know, if this doesn't
> improve soon, I'm going to erase the drive and either find another
> encryption tool or just not encrypt it at all.  I'm not rebooting every
> time this thing wants to act ugly.  I'm used to rebooting like every 6
> months or so.  Usually when the power fails. 
>
> If anyone has any ideas, please post.  In the meantime, I'm going to try
> this mounting by label idea. 
>
> Dale
>
> :-)  :-)
>


Here's a update.  I'm doing my weekly updates which means I close web
browsers, to conserve memory mostly.  While I'm doing updates, I update
my backups.  As usual, the 6TB drive did fine.  I ran the usual
commands, got the proper response and everything worked fine.  The 8TB
drive did the same.  It ran every command from decrypting it to
unmounting and closing without a single problem.  I even opened it,
mounted it, unmounted it and closed it again.  Still, no problems at all. 

The only thing I changed, I mounted by label instead of UUID.  Can
someone explain to me why that should matter?  It's the same thing being
mounted so one would think it wouldn't matter at all.  Heck, most even
say mounting by UUID is the best way.  Dang near impossible to have two
of anything with the same UUID.  So why does it work fine with labels
but not UUID? 

I'm looking forward to someone having a clue on this.  I'm very
confused, happy it works but confused for sure. This makes no sense. 

Dale

:-)  :-) 
Re: cryptsetup close and device in use when it is not [ In reply to ]
This is just a guess. Maybe you have two devices with the same UUID?

If so, you can change it with:

$ cryptsetup --uuid="<some_uuid>" luksUUID "/dev/sdx1"

-Ramon

On 05/07/2021 05:19, Dale wrote:
> Dale wrote:
>> Dale wrote:
>>> After staring at it a while, it hit me that lsblk is showing it as still
>>> mounted, even tho I umounted already without error.  So, I just ran the
>>> umount command again.  After that, it closed just fine.  So, it seems to
>>> be mounted twice, not once.  I mount using this command 'mount /mnt/8tb'
>>> which uses fstab to mount the correct UUID device to that mount point.
>>> Surely it only mounts once.  Always has in the past.  So why is it being
>>> mounted twice now?  None of my scripts used for backups includes any
>>> mounting commands.  There's also only one entry in fstab as well.
>>>
>>> Anyone have any idea while it gets mounted twice?  Does the cryptsetup
>>> open command mount it in some way and then I mount it manually as well??
>>> When I opened it just now, it didn't show anything as mounted.  So it
>>> doesn't appear to be the open command.  What else could it be??
>>>
>>> Ideas?
>>>
>>> Dale
>>>
>>> :-)  :-)
>>>
>> The same drive just did it again.  I had to reboot to get it to reset.
>> This is Linux not windoze.  Rebooting to reset something like that is
>> plain ridiculous.  I also checked, this time it was mounted only once.
>> When I tried to umount it again, it said it wasn't mounted.  The thing
>> that really gets me, nothing can tell me what it is that is using the
>> device.  It says it is in use but no clue what it is using it.
>>
>> To test a theory, I changed fstab to mount by label instead of UUID.
>> Maybe that will change something.  I dunno.  I do know, if this doesn't
>> improve soon, I'm going to erase the drive and either find another
>> encryption tool or just not encrypt it at all.  I'm not rebooting every
>> time this thing wants to act ugly.  I'm used to rebooting like every 6
>> months or so.  Usually when the power fails.
>>
>> If anyone has any ideas, please post.  In the meantime, I'm going to try
>> this mounting by label idea.
>>
>> Dale
>>
>> :-)  :-)
>>
>
> Here's a update.  I'm doing my weekly updates which means I close web
> browsers, to conserve memory mostly.  While I'm doing updates, I update
> my backups.  As usual, the 6TB drive did fine.  I ran the usual
> commands, got the proper response and everything worked fine.  The 8TB
> drive did the same.  It ran every command from decrypting it to
> unmounting and closing without a single problem.  I even opened it,
> mounted it, unmounted it and closed it again.  Still, no problems at all.
>
> The only thing I changed, I mounted by label instead of UUID.  Can
> someone explain to me why that should matter?  It's the same thing being
> mounted so one would think it wouldn't matter at all.  Heck, most even
> say mounting by UUID is the best way.  Dang near impossible to have two
> of anything with the same UUID.  So why does it work fine with labels
> but not UUID?
>
> I'm looking forward to someone having a clue on this.  I'm very
> confused, happy it works but confused for sure. This makes no sense.
>
> Dale
>
> :-)  :-)
>

--
GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF
Re: cryptsetup close and device in use when it is not [ In reply to ]
Ramon Fischer wrote:
> This is just a guess. Maybe you have two devices with the same UUID?
>
> If so, you can change it with:
>
>    $ cryptsetup --uuid="<some_uuid>" luksUUID "/dev/sdx1"
>
> -Ramon
>

Well, it could make sense I guess.  I'd think it a very rare thing to
happen but during next backup, I'll check that.  Just to be sure. 

Thanks.  I'll update when I find out. 

Dale

:-)  :-) 
Re: cryptsetup close and device in use when it is not [ In reply to ]
Ramon, Dale,

On Tuesday, 2021-07-06 20:40:32 +0200, Ramon Fischer wrote:

> This is just a guess. Maybe you have two devices with the same UUID?
>
> If so, you can change it with:
>
> $ cryptsetup --uuid="<some_uuid>" luksUUID "/dev/sdx1"

Good idea. But to find out whether or not this is the cause of Dale's
problems I would suggest to first run "cryptsetup" without the "--uuid"
option (in order to get the UUID listed) and to then compare this with
the output from "ls /dev/disk/by-uuid".

Sincerely,
Rainer
Re: cryptsetup close and device in use when it is not [ In reply to ]
Dr Rainer Woitok wrote:
> Ramon, Dale,
>
> On Tuesday, 2021-07-06 20:40:32 +0200, Ramon Fischer wrote:
>
>> This is just a guess. Maybe you have two devices with the same UUID?
>>
>> If so, you can change it with:
>>
>> $ cryptsetup --uuid="<some_uuid>" luksUUID "/dev/sdx1"
> Good idea. But to find out whether or not this is the cause of Dale's
> problems I would suggest to first run "cryptsetup" without the "--uuid"
> option (in order to get the UUID listed) and to then compare this with
> the output from "ls /dev/disk/by-uuid".
>
> Sincerely,
> Rainer
>


Well, it's midweek and I wanted to test this theory even tho it is
early.  Plus, it's raining outside so I'm a bit bored.  I pulled the
backup drive from the safe and did a backup.  While it was backing up
new stuff, I ran this:


root@fireball / # blkid | grep dde669
/dev/mapper/8tb: LABEL="8tb-backup"
UUID="0277ff1b-2d7c-451c-ae94-f20f42dde669" BLOCK_SIZE="4096" TYPE="ext4"
root@fireball / # ls /dev/disk/by-uuid | grep dde669
0277ff1b-2d7c-451c-ae94-f20f42dde669
root@fireball / #


I just grepped the last little bit of the UUID to see if anything else
matched.  It didn't.  I tried both methods just in case.  It was
grasping at straws a bit but hey, sometimes that straw solves the
problem.  I might add, I unmounted the drive and cryptsetup closed it
first time with not a single error.  It didn't even burp.  Given I've
done this several times with no problem after doing the UUID way with
consistent errors, I think it is safe to assume that changing from UUID
to labels solves this problem.  The question now is this, why?  It's not
like one mounts something different or anything.  It's the same device,
just using a different link basically. 

This is thoroughly confusing.  It just doesn't make sense at all. 
Either way should work exactly the same. 

I'm open to ideas on this.  Anybody have one?  I'll test it if I can
even if it is a serious grasp at a small straw.  ;-)

Dale

:-)  :-) 
Re: cryptsetup close and device in use when it is not [ In reply to ]
Interesting.

I have some other ideas, but this is really grasping at straws. Create a
backup of the backup drive before doing any tests, since you have to
move it a lot for this:

1. Connect the hard drive to a different eSATA port
2. Try another eSATA cable
3. Try to mount the hard drive on different devices
4. Try different hard drive cases with different connection types
(Maybe you have a better enclosure with USB or even FireWire, which
does not damage your drive?)
5. Connect it internally via SATA and try to mount it
6. Mirror the hard drive to a second hard drive and try to mount the
second one

I think, this would entirely cover Layer 1 of the OSI Layer Model[1]. :)

-Ramon

[1] https://en.wikipedia.org/wiki/OSI_model

On 07/07/2021 20:08, Dale wrote:
> Dr Rainer Woitok wrote:
>> Ramon, Dale,
>>
>> On Tuesday, 2021-07-06 20:40:32 +0200, Ramon Fischer wrote:
>>
>>> This is just a guess. Maybe you have two devices with the same UUID?
>>>
>>> If so, you can change it with:
>>>
>>> $ cryptsetup --uuid="<some_uuid>" luksUUID "/dev/sdx1"
>> Good idea. But to find out whether or not this is the cause of Dale's
>> problems I would suggest to first run "cryptsetup" without the "--uuid"
>> option (in order to get the UUID listed) and to then compare this with
>> the output from "ls /dev/disk/by-uuid".
>>
>> Sincerely,
>> Rainer
>>
>
> Well, it's midweek and I wanted to test this theory even tho it is
> early.  Plus, it's raining outside so I'm a bit bored.  I pulled the
> backup drive from the safe and did a backup.  While it was backing up
> new stuff, I ran this:
>
>
> root@fireball / # blkid | grep dde669
> /dev/mapper/8tb: LABEL="8tb-backup"
> UUID="0277ff1b-2d7c-451c-ae94-f20f42dde669" BLOCK_SIZE="4096" TYPE="ext4"
> root@fireball / # ls /dev/disk/by-uuid | grep dde669
> 0277ff1b-2d7c-451c-ae94-f20f42dde669
> root@fireball / #
>
>
> I just grepped the last little bit of the UUID to see if anything else
> matched.  It didn't.  I tried both methods just in case.  It was
> grasping at straws a bit but hey, sometimes that straw solves the
> problem.  I might add, I unmounted the drive and cryptsetup closed it
> first time with not a single error.  It didn't even burp.  Given I've
> done this several times with no problem after doing the UUID way with
> consistent errors, I think it is safe to assume that changing from UUID
> to labels solves this problem.  The question now is this, why?  It's not
> like one mounts something different or anything.  It's the same device,
> just using a different link basically.
>
> This is thoroughly confusing.  It just doesn't make sense at all.
> Either way should work exactly the same.
>
> I'm open to ideas on this.  Anybody have one?  I'll test it if I can
> even if it is a serious grasp at a small straw.  ;-)
>
> Dale
>
> :-)  :-)

--
GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF
Re: cryptsetup close and device in use when it is not [ In reply to ]
Ramon Fischer wrote:
> Interesting.
>
> I have some other ideas, but this is really grasping at straws. Create
> a backup of the backup drive before doing any tests, since you have to
> move it a lot for this:
>
>    1. Connect the hard drive to a different eSATA port
>    2. Try another eSATA cable
>    3. Try to mount the hard drive on different devices
>    4. Try different hard drive cases with different connection types
>    (Maybe you have a better enclosure with USB or even FireWire, which
>    does not damage your drive?)
>    5. Connect it internally via SATA and try to mount it
>    6. Mirror the hard drive to a second hard drive and try to mount the
>    second one
>
> I think, this would entirely cover Layer 1 of the OSI Layer Model[1]. :)
>
> -Ramon
>
> [1] https://en.wikipedia.org/wiki/OSI_model
>


That's a lot of effort.  It's annoying it doesn't close like it should
but doing all that would be a tedious task as well.  It would eliminate
a lot of potential causes tho.  Thing is, I think it's a software issue
not hardware. 

To add to this, the 6TB drive just did the same thing.  I had been using
UUID to mount it since it was working.  After getting the same problem
as the other drive, I changed it.  It took some effort to get it to
close but restarting lvm and friends did eventually get it to close.  I
then changed it to mount by label like I been doing with the 8TB drive. 

I think by just continuing to note what it is doing, eventually the
problem will show itself.  Personally, I sort of wonder if it is a udev
problem or lvm.  Thing is, a lot of this software works together so
closely, it's hard to know where one stops and the other starts. 

I finished my backups to the 8TB drive and it worked start to finish
with no errors at all.  I guess we'll see what happens next week with
the 6TB drive.  See if it starts to work again with no problem or still
has issues of some kind.  So far, mounting by label seems to have worked
well for the 8TB drive. 

Will update again as things move along.

Dale

:-)  :-) 
Re: cryptsetup close and device in use when it is not [ In reply to ]
OK, if it could be "udev", you might want to try to check the following:

$ grep -rF "<part_of_uuid>" /etc/udev/rules.d/
$ grep -rF "<part_of_uuid>" /lib/udev/rules.d/
$ grep -rF "<part_of_uuid>" /etc

You could also try to search for the partition device, maybe there will
be some interesting configuration files.

If you are using "systemd", you might want to check every service unit
file as well:

$ systemctl

Recently, I had a similar issue with "cryptsetup" on Raspbian, where the
"/etc/crypttab" was faulty, which may be applicable here. It had the
following entry:

# <accident_paste_with_uuid> # <target name> <source device> [...]
<entry1>
<entry2>

Therefore, the systemd service unit
"systemd-cryptsetup@dev-disk-by\x2duuid-#<accident_paste_with_uuid> #
<target name> <source device> [...]" - if I remember correctly - failed.
It seems, that "systemd-cryptsetup-generator" only searches for matching
UUIDs in "/etc/crypttab", even, if they are commented and creates
service units for each match in "/run/systemd/generator/".
I remember, that I had issues to access the hard drive. Nevertheless, I
was able to mount it normally, due to the other correct entry(?).

By removing the accidentally pasted UUID from "/etc/crypttab" and
rebooting, I was able to use the hard drive without issues again.

Maybe this is something, where you could poke around? :)

-Ramon

On 12/07/2021 10:31, Dale wrote:
> Ramon Fischer wrote:
>> Interesting.
>>
>> I have some other ideas, but this is really grasping at straws. Create
>> a backup of the backup drive before doing any tests, since you have to
>> move it a lot for this:
>>
>>    1. Connect the hard drive to a different eSATA port
>>    2. Try another eSATA cable
>>    3. Try to mount the hard drive on different devices
>>    4. Try different hard drive cases with different connection types
>>    (Maybe you have a better enclosure with USB or even FireWire, which
>>    does not damage your drive?)
>>    5. Connect it internally via SATA and try to mount it
>>    6. Mirror the hard drive to a second hard drive and try to mount the
>>    second one
>>
>> I think, this would entirely cover Layer 1 of the OSI Layer Model[1]. :)
>>
>> -Ramon
>>
>> [1] https://en.wikipedia.org/wiki/OSI_model
>>
>
> That's a lot of effort.  It's annoying it doesn't close like it should
> but doing all that would be a tedious task as well.  It would eliminate
> a lot of potential causes tho.  Thing is, I think it's a software issue
> not hardware.
>
> To add to this, the 6TB drive just did the same thing.  I had been using
> UUID to mount it since it was working.  After getting the same problem
> as the other drive, I changed it.  It took some effort to get it to
> close but restarting lvm and friends did eventually get it to close.  I
> then changed it to mount by label like I been doing with the 8TB drive.
>
> I think by just continuing to note what it is doing, eventually the
> problem will show itself.  Personally, I sort of wonder if it is a udev
> problem or lvm.  Thing is, a lot of this software works together so
> closely, it's hard to know where one stops and the other starts.
>
> I finished my backups to the 8TB drive and it worked start to finish
> with no errors at all.  I guess we'll see what happens next week with
> the 6TB drive.  See if it starts to work again with no problem or still
> has issues of some kind.  So far, mounting by label seems to have worked
> well for the 8TB drive.
>
> Will update again as things move along.
>
> Dale
>
> :-)  :-)

--
GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF
Re: cryptsetup close and device in use when it is not [ In reply to ]
Am Wed, Jul 07, 2021 at 01:08:55PM -0500 schrieb Dale:

> root@fireball / # blkid | grep dde669
> /dev/mapper/8tb: LABEL="8tb-backup"
> UUID="0277ff1b-2d7c-451c-ae94-f20f42dde669" BLOCK_SIZE="4096" TYPE="ext4"
> root@fireball / # ls /dev/disk/by-uuid | grep dde669
> 0277ff1b-2d7c-451c-ae94-f20f42dde669
> root@fireball / #

I followed this thread, and couldn’t remember ever having the same issue.
But today I was bitten: It’s a 3 TB external USB drive from Intenso.

Yesterday I was in the middle of a backup (it’s my main backup drive), but I
had to sleep and so sent the machine into standby. I had to start the PC
again a few minutes later in order to unmount an sshfs of it on another
machine, and sent it right back to sleep.

Just now I switched the PC back on and the drive was gone and off (USB
enclosures tend to spin down the drive when USB disconnects). So I pulled
the USB cable and plugged it back in for the drive to start and be
rediscovered. That worked and I resumed the backup, but this enclosure has
the nasty habit of sometimes intermittently disconnecting on its own.

Its device was not gone (it usually disconnects for a tiny moment and then
comes back, probably a USB issue), so I just tried to open it again in
Dolphin, which gave me:
Error unlocking /dev/sdd1: Failed to activate device: File exists

$ blkid | grep luks
/dev/mapper/luks-6a55a712-773e-4cd8-9776-fc9b6f39a998: LABEL="backup" UUID="50ed9519-cd9c-4d11-b78a-9f057b089362" BLOCK_SIZE="4096" TYPE="ext4"

$ ls -l /dev/disk/by-uuid/6a55a*
lrwxrwxrwx 10 root 2021-07-25 21:34 /dev/disk/by-uuid/6a55a712-773e-4cd8-9776-fc9b6f39a998 -> ../../sdd1

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
[…]
sdd 8:48 0 2,7T 0 disk
??sdd1 8:49 0 2,7T 0 part

$ mount | grep -E 'luks|sdd'
[nothing]

$ cryptsetup luksClose luks-6a55a712-773e-4cd8-9776-fc9b6f39a998
Device luks-6a55a712-773e-4cd8-9776-fc9b6f39a998 is still in use.

I don’t quite like this bad habit of the enclosure, but a 3 TB drive is a 3
TB drive. I just looked at smart to see how old it is, because it has only
350 hours of power-on time, but it must be at least 5 years old. And
smartctl tells me there is a firmware update available! (for Windows, Mac
and—lo and behold—a bootable ISO, let’s hope it works with USB sticks).

Perhaps this fixes the issue. Dale, maybe you should look for the same.

--
Grüße | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

Emacs is a great operating system, which only lacks a good editor.
Re: cryptsetup close and device in use when it is not [ In reply to ]
Frank Steinmetzger wrote:
> Am Wed, Jul 07, 2021 at 01:08:55PM -0500 schrieb Dale:
>
>> root@fireball / # blkid | grep dde669
>> /dev/mapper/8tb: LABEL="8tb-backup"
>> UUID="0277ff1b-2d7c-451c-ae94-f20f42dde669" BLOCK_SIZE="4096" TYPE="ext4"
>> root@fireball / # ls /dev/disk/by-uuid | grep dde669
>> 0277ff1b-2d7c-451c-ae94-f20f42dde669
>> root@fireball / #
> I followed this thread, and couldn’t remember ever having the same issue.
> But today I was bitten: It’s a 3 TB external USB drive from Intenso.
>
> Yesterday I was in the middle of a backup (it’s my main backup drive), but I
> had to sleep and so sent the machine into standby. I had to start the PC
> again a few minutes later in order to unmount an sshfs of it on another
> machine, and sent it right back to sleep.
>
> Just now I switched the PC back on and the drive was gone and off (USB
> enclosures tend to spin down the drive when USB disconnects). So I pulled
> the USB cable and plugged it back in for the drive to start and be
> rediscovered. That worked and I resumed the backup, but this enclosure has
> the nasty habit of sometimes intermittently disconnecting on its own.
>
> Its device was not gone (it usually disconnects for a tiny moment and then
> comes back, probably a USB issue), so I just tried to open it again in
> Dolphin, which gave me:
> Error unlocking /dev/sdd1: Failed to activate device: File exists
>
> $ blkid | grep luks
> /dev/mapper/luks-6a55a712-773e-4cd8-9776-fc9b6f39a998: LABEL="backup" UUID="50ed9519-cd9c-4d11-b78a-9f057b089362" BLOCK_SIZE="4096" TYPE="ext4"
>
> $ ls -l /dev/disk/by-uuid/6a55a*
> lrwxrwxrwx 10 root 2021-07-25 21:34 /dev/disk/by-uuid/6a55a712-773e-4cd8-9776-fc9b6f39a998 -> ../../sdd1
>
> $ lsblk
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
> […]
> sdd 8:48 0 2,7T 0 disk
> ??sdd1 8:49 0 2,7T 0 part
>
> $ mount | grep -E 'luks|sdd'
> [nothing]
>
> $ cryptsetup luksClose luks-6a55a712-773e-4cd8-9776-fc9b6f39a998
> Device luks-6a55a712-773e-4cd8-9776-fc9b6f39a998 is still in use.
>
> I don’t quite like this bad habit of the enclosure, but a 3 TB drive is a 3
> TB drive. I just looked at smart to see how old it is, because it has only
> 350 hours of power-on time, but it must be at least 5 years old. And
> smartctl tells me there is a firmware update available! (for Windows, Mac
> and—lo and behold—a bootable ISO, let’s hope it works with USB sticks).
>
> Perhaps this fixes the issue. Dale, maybe you should look for the same.
>


That's interesting.  I have two different drives, can't recall but may
be the same brand.  While using UUID to mount it, it would either fail
every time or in the case of the smaller drive, fail on occasion but not
every time.  The smaller drive worked most of the time but after a
couple failures, I switched to mounting by label.  Since switching both
drives to mount by labels, neither has had a single issue.  My backups
last time went without a hitch.  I was actually planning to post that
after my next backup if nothing failed.  As it is, I think switching to
labels has fixed it. 

I've tried external drives connected by USB before and hated them.  Slow
when they do work and buggy at that.  I've had more drives go bad when
using USB enclosures than I've ever had on IDE or (e)SATA.  I've had two
drives fail after years of service that were IDE or SATA.  I have three
drives that are bricks and all of them were in USB enclosures and far
young to die.  I paid more for eSATA external enclosures and have had no
problems with drives going dead yet.  All of them have far surpassed the
drives in the USB enclosures.  Heck, this 'in use' problem is the first
issue I recall having.  Fast too.  The SMR drive not so much but the CMR
drive is as fast as what is in my system connected to the mobo itself. 

The thing about this, I have no idea why switching to labels works.  The
UUID, label and such are nothing but links to the real device.  It
should make no difference at all which one is used to mount with.  I'm
no guru or anything but it just shouldn't matter. 

Bad thing is, I don't use anything Microsoft here.  Can a drive's
firmware be updated on Linux?  I think my drives are either Seagate or
WD.  I tend to stick with those two, unless it is a really awesome
deal.  I've never updated the firmware on a drive before.  I have my
mobo and my router but not a drive. 

Dale

:-)  :-)
Re: cryptsetup close and device in use when it is not [ In reply to ]
Am Sun, Jul 25, 2021 at 06:10:19PM -0500 schrieb Dale:

> That's interesting.  I have two different drives, can't recall but may
> be the same brand.

The actual drive in my enclusure is a Seagate, BTW.

> I've tried external drives connected by USB before and hated them.  Slow
> when they do work and buggy at that.

Theoretically, HDDs are not able to saturate USB 3. And from my observation,
I do get their maximum performance – my 2.5? 1 TB WD delivers about 80-90 MB/s
read speed and said Intenso/Seagate 3.5? gives me up to around 140 MB/s tops.
I used dstat to gather those numbers.

> I've had more drives go bad when using USB enclosures than I've ever had
> on IDE or (e)SATA.

Interesting, I can’t really confirm such a correlation from the drives I
have lying around. And I don’t see how USB can cause damage to a drive.
Except for physical impacts owing to the fact that USB drives are easily
moved around.

> I've had two drives fail after years of service that were IDE or SATA.  I
> have three drives that are bricks and all of them were in USB enclosures
> and far young to die.

Perhaps they became too hot during operation. Enclosures don’t usually
account for thermals. Didn’t you mention you lived in a hot area?

> I paid more for eSATA external enclosures and have had no
> problems with drives going dead yet.  All of them have far surpassed the
> drives in the USB enclosures.

Hm... bad (in the sense of cheap) USB controllers on the mobo or the
enclosures? Or bad USB cables? What kind of HDD death are we talking about?
Certainly not bad sectors, right?

> Bad thing is, I don't use anything Microsoft here.  Can a drive's
> firmware be updated on Linux?

Well, that seagate update ISO didn’t work with USB and I think all my CDRW
are now serving as saucers for cups. So I downloaded the EXE and ran it on
my gaming Windows. It actually set up a temporary boot of a tiny linux which
tried the firmware update. Infortunately it didn’t detect the drive and the
text went by too fast. Might give it another try some other time.

> I think my drives are either Seagate or WD.  I tend to stick with those
> two, unless it is a really awesome deal.

Yea. First the SMR fiasco became public and then there was some other PR
stunt they did that I can’t remember right now, and I said “I can’t buy WD
anymore”. But there is no real alternative these days. And CMR drives are
becoming ever rarer, especially in the 2.5? realm. Except for one single
seagate model, there isn’t even a bare SATA drive above 2 TB available on
the market! Everything above that size is external USB stuff. And those
disks don’t come with standard SATA connectors anymore, but have the USB
socket soldered onto their PCB.

> I've never updated the firmware on a drive before.

Me neither. I think I updated an SSD once.

--
Grüße | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

Similar regulations in different post departments are TELECOMpatible.
Re: cryptsetup close and device in use when it is not [ In reply to ]
Frank Steinmetzger wrote:
> Am Sun, Jul 25, 2021 at 06:10:19PM -0500 schrieb Dale:
>
>> I've tried external drives connected by USB before and hated them.  Slow
>> when they do work and buggy at that.
> Theoretically, HDDs are not able to saturate USB 3. And from my observation,
> I do get their maximum performance – my 2.5? 1 TB WD delivers about 80-90 MB/s
> read speed and said Intenso/Seagate 3.5? gives me up to around 140 MB/s tops.
> I used dstat to gather those numbers.

I think all my USB ports are USB2.  It's slower.  What you post above is
about what I get on my external eSATA.  If I were using USB3, things may
be different.  Maybe.  ;-)


>> I've had more drives go bad when using USB enclosures than I've ever had
>> on IDE or (e)SATA.
> Interesting, I can’t really confirm such a correlation from the drives I
> have lying around. And I don’t see how USB can cause damage to a drive.
> Except for physical impacts owing to the fact that USB drives are easily
> moved around.
>

Those particular drives sat on the desk next to my computer.  They
rarely moved.  Heck, I rarely unplugged them.  Just turn them off when
done. 


>> I've had two drives fail after years of service that were IDE or SATA.  I
>> have three drives that are bricks and all of them were in USB enclosures
>> and far young to die.
> Perhaps they became too hot during operation. Enclosures don’t usually
> account for thermals. Didn’t you mention you lived in a hot area?
>

Every enclosure I buy has a fan.  The enclosures were pretty well built
as far as the case goes.


>> I paid more for eSATA external enclosures and have had no
>> problems with drives going dead yet.  All of them have far surpassed the
>> drives in the USB enclosures.
> Hm... bad (in the sense of cheap) USB controllers on the mobo or the
> enclosures? Or bad USB cables? What kind of HDD death are we talking about?
> Certainly not bad sectors, right?
>

After a while I'd start getting errors and it would either remount ro or
just unmount completely.  After a while, the drives wouldn't respond at
all.  They spin up but it's as if they are not connected with the data
cable.  Eventually, I plugged them into my computer as SATA drives. 
They still wouldn't show up.  It was as if they were not there.  They
did spin up tho. 

>> I think my drives are either Seagate or WD.  I tend to stick with those
>> two, unless it is a really awesome deal.
> Yea. First the SMR fiasco became public and then there was some other PR
> stunt they did that I can’t remember right now, and I said “I can’t buy WD
> anymore”. But there is no real alternative these days. And CMR drives are
> becoming ever rarer, especially in the 2.5? realm. Except for one single
> seagate model, there isn’t even a bare SATA drive above 2 TB available on
> the market! Everything above that size is external USB stuff. And those
> disks don’t come with standard SATA connectors anymore, but have the USB
> socket soldered onto their PCB.
>

I bought a SMR before I was aware of the problems with them.  It's just
a backup drive but I still have to wait for it to stop bumping before I
power it off.  Sometimes it only takes a few minutes, sometimes it bumps
for a while.  The CMR I use as a backup drive, different data, is
smaller.  It doesn't do that so I can unhook it right after it finishes. 
>> I've never updated the firmware on a drive before.
> Me neither. I think I updated an SSD once.
>

I've never had a SSD.  Thinking about it tho. 

Hmmm, just realized I didn't do my usual Sunday updates and backups. 
Ooooops.  :/

Dale

:-) :-) 
Re: cryptsetup close and device in use when it is not [ In reply to ]
On 26/07/21 22:00, Frank Steinmetzger wrote:
> Am Sun, Jul 25, 2021 at 06:10:19PM -0500 schrieb Dale:
>


>
>> I've had more drives go bad when using USB enclosures than I've ever had
>> on IDE or (e)SATA.
>
> Interesting, I can’t really confirm such a correlation from the drives I
> have lying around. And I don’t see how USB can cause damage to a drive.
> Except for physical impacts owing to the fact that USB drives are easily
> moved around.
>
>> I've had two drives fail after years of service that were IDE or SATA. I
>> have three drives that are bricks and all of them were in USB enclosures
>> and far young to die.

I've bought "add your own drive" USB enclosures, and ime they kill
drives. The big one killed a 3.5" drive dead, and the little one stunned
a 2.5" (as in, it no longer worked in the enclosure, I managed to revive
it ...)

I've never had any internal drives die on me (although I have rescued
other peoples' dead drives).
>
> Perhaps they became too hot during operation. Enclosures don’t usually
> account for thermals. Didn’t you mention you lived in a hot area?
>
>> I paid more for eSATA external enclosures and have had no
>> problems with drives going dead yet. All of them have far surpassed the
>> drives in the USB enclosures.

I've now bought a dual USB/SATA chassis you can hot-plug the drives
into. I haven't used that enough to form opinions on its reliability.
>


>
>> I think my drives are either Seagate or WD. I tend to stick with those
>> two, unless it is a really awesome deal.
>
> Yea. First the SMR fiasco became public and then there was some other PR
> stunt they did that I can’t remember right now, and I said “I can’t buy WD
> anymore”. But there is no real alternative these days. And CMR drives are
> becoming ever rarer, especially in the 2.5? realm. Except for one single
> seagate model, there isn’t even a bare SATA drive above 2 TB available on
> the market! Everything above that size is external USB stuff. And those
> disks don’t come with standard SATA connectors anymore, but have the USB
> socket soldered onto their PCB.
>
Are you talking 2.5" drives here? There are plenty of 3.5" large CMR
drives. But as far as I can tell there are effectively only three drive
manufacturers left - Seagate, WD and Toshiba.

The SMR stunt was a real cock-up as far as raid was concerned - they
moved their WD Red "ideal for raid and NAS" drives over to SMR and
promptly started killing raid arrays left right and centre as people
replaced drives ... you now need Red Pro so the advice for raid is just
"Avoid WD".

From what I can make out with Seagate, the old Barracuda line is pretty
much all CMR, they had just started making some of them SMR when the
brown stuff hit the rotating blades. So now it seems pretty clear, they
renamed the SMR drives BarraCuda (note the *slight* change), and they
still make CMR drives as FireCuda. Toshiba "I know nuttin'".

Cheers,
Wol

Cheers,
Wol

1 2 3  View All