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





   $ systemctl



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





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

-Ramon

On 12/07/2021 10:31, Dale wrote:

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: 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: 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.

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

OpenPGP_signature
Description: OpenPGP digital signature