Re: [gentoo-user] cryptsetup close and device in use when it is not

[Ramon Fischer]

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