Re: [gentoo-user] cryptsetup close and device in use when it is not
Ramon Fischer wrote: > Hi Dale, > >> So, something says it is busy but eventually >> releases it if left alone for a while. I'd like to know what it is and >> if it is really in use or not. Thing is, I can't find a way to know >> what it is that is using it. The dmsetup command shows it is in use but >> no way to know what is using it. > I could reproduce this issue by killing my desktop process, unmounting > the home partition and playing some "kill process" bingo. I could > backtrace it to one unkillable process "kcryptd": > > 1. Kill "awesomewm": + Backspace > 2. Kill other processes accessing "/home/" > 3. umount /home > 4. cryptsetup close crypthome > Device crypthome is still in use > 5. dmsetup info /dev/mapper/crypthome > Name: crypthome > State: ACTIVE > Read Ahead: 256 > Tables present: LIVE > Open count: 1 > Event number: 0 > Major, minor: 253, 1 > Number of targets: 1 > UUID: CRYPT-LUKS2--crypthome > 6. Kill any unnecessary process and try "cryptsetup close crypthome" > 7. Search for major, minor: ps aux | grep "253:1" > root 150 0.2 0.0 0 0 ? I 15:21 0:02 > [kworker/u16:5-kcryptd/253:1] > 8. Does not work: kill 150 > 9. Does not work and could be dangerous: kill -9 150 > > So, there was still one "kcryptd" process left, accessing the hard > drive, but I found no way to kill it. > > Maybe this could be helpful? > > -Ramon > Well, it still does it but there is no rhyme or reason to when it says in use and when it closes when asked too. I to saw a process kcryptd but not sure what triggers it. I didn't try to kill it since I'm pretty sure it is a kernel process. I build everything into my kernel, no modules. Sort of scared to mess with it. So, sometimes it works as it should, sometimes not. When it doesn't, if I leave it alone for a while then try again, it works. I also checked to be sure SMART wasn't doing something but if it is, I couldn't see it. Since it is a removable drive, I don't have it set to do anything either. I guess I'll just have to wait on it to finish whatever it is doing to close it when it gets stubborn. Maybe this is a bug, maybe it has a really good reason for not closing. Who knows. :/ Thanks to all for the help. We gave it a good try. Dale :-) :-)
Re: [gentoo-user] cryptsetup close and device in use when it is not
Hi Dale, So, something says it is busy but eventually releases it if left alone for a while. I'd like to know what it is and if it is really in use or not. Thing is, I can't find a way to know what it is that is using it. The dmsetup command shows it is in use but no way to know what is using it. I could reproduce this issue by killing my desktop process, unmounting the home partition and playing some "kill process" bingo. I could backtrace it to one unkillable process "kcryptd": 1. Kill "awesomewm": + Backspace 2. Kill other processes accessing "/home/" 3. umount /home 4. cryptsetup close crypthome Device crypthome is still in use 5. dmsetup info /dev/mapper/crypthome Name: crypthome State: ACTIVE Read Ahead: 256 Tables present: LIVE Open count: 1 Event number: 0 Major, minor: 253, 1 Number of targets: 1 UUID: CRYPT-LUKS2--crypthome 6. Kill any unnecessary process and try "cryptsetup close crypthome" 7. Search for major, minor: ps aux | grep "253:1" root 150 0.2 0.0 0 0 ? I 15:21 0:02 [kworker/u16:5-kcryptd/253:1] 8. Does not work: kill 150 9. Does not work and could be dangerous: kill -9 150 So, there was still one "kcryptd" process left, accessing the hard drive, but I found no way to kill it. Maybe this could be helpful? -Ramon On 02/08/2021 15:33, Dale wrote: Ramon Fischer wrote: OK, if it could be "udev", you might want to try to check the following: $ grep -rF "" /etc/udev/rules.d/ $ grep -rF "" /lib/udev/rules.d/ $ grep -rF "" /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: # # [...] Therefore, the systemd service unit "systemd-cryptsetup@dev-disk-by\x2duuid-# # [...]" - 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 I'm running openrc here. I don't recall making any udev rules recently. This is a list of what I have. root@fireball / # ls -al /etc/udev/rules.d/ total 20 drwxr-xr-x 2 root root 4096 Apr 27 15:07 . drwxr-xr-x 3 root root 4096 Jul 27 03:17 .. -rw-r--r-- 1 root root 2064 Apr 27 15:07 69-libmtp.rules -rw-r--r-- 1 root root 1903 Apr 4 2012 70-persistent-cd.rules -rw-r--r-- 1 root root 814 Jan 1 2008 70-persistent-net.rules -rw-r--r-- 1 root root 0 Mar 22 2015 80-net-name-slot.rules root@fireball / # One is for CD/DVD stuff. I wonder if I can remove that now. Two is for network cards and top one is something to do with my old Motorola cell phone, rest in peace. All this said, it did it again last night. I tried a few things and went to bed while my updates were compiling. When I got up a bit ago, it closed just fine. So, something says it is busy but eventually releases it if left alone for a while. I'd like to know what it is and if it is really in use or not. Thing is, I can't find a way to know what it is that is using it. The dmsetup command shows it is in use but no way to know what is using it. Dale :-) :-) -- GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] cryptsetup close and device in use when it is not
Ramon Fischer wrote: > OK, if it could be "udev", you might want to try to check the following: > > $ grep -rF "" /etc/udev/rules.d/ > $ grep -rF "" /lib/udev/rules.d/ > $ grep -rF "" /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: > > # # [...] > > > > Therefore, the systemd service unit > "systemd-cryptsetup@dev-disk-by\x2duuid-# # > [...]" - 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 I'm running openrc here. I don't recall making any udev rules recently. This is a list of what I have. root@fireball / # ls -al /etc/udev/rules.d/ total 20 drwxr-xr-x 2 root root 4096 Apr 27 15:07 . drwxr-xr-x 3 root root 4096 Jul 27 03:17 .. -rw-r--r-- 1 root root 2064 Apr 27 15:07 69-libmtp.rules -rw-r--r-- 1 root root 1903 Apr 4 2012 70-persistent-cd.rules -rw-r--r-- 1 root root 814 Jan 1 2008 70-persistent-net.rules -rw-r--r-- 1 root root 0 Mar 22 2015 80-net-name-slot.rules root@fireball / # One is for CD/DVD stuff. I wonder if I can remove that now. Two is for network cards and top one is something to do with my old Motorola cell phone, rest in peace. All this said, it did it again last night. I tried a few things and went to bed while my updates were compiling. When I got up a bit ago, it closed just fine. So, something says it is busy but eventually releases it if left alone for a while. I'd like to know what it is and if it is really in use or not. Thing is, I can't find a way to know what it is that is using it. The dmsetup command shows it is in use but no way to know what is using it. Dale :-) :-)
Re: [gentoo-user] cryptsetup close and device in use when it is not
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
Re: [gentoo-user] cryptsetup close and device in use when it is not
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. Ops. :/ Dale :-) :-)
Re: [gentoo-user] cryptsetup close and device in use when it is not
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. signature.asc Description: PGP signature
Re: [gentoo-user] cryptsetup close and device in use when it is not
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 > […] > sdd8: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: [gentoo-user] cryptsetup close and device in use when it is not
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 […] sdd8: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. signature.asc Description: PGP signature
Re: [gentoo-user] cryptsetup close and device in use when it is not
OK, if it could be "udev", you might want to try to check the following: $ grep -rF "" /etc/udev/rules.d/ $ grep -rF "" /lib/udev/rules.d/ $ grep -rF "" /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: # # [...] Therefore, the systemd service unit "systemd-cryptsetup@dev-disk-by\x2duuid-# # [...]" - 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 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] cryptsetup close and device in use when it is not
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: [gentoo-user] cryptsetup close and device in use when it is not
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="" 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 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] cryptsetup close and device in use when it is not
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="" 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: [gentoo-user] cryptsetup close and device in use when it is not
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="" 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: [gentoo-user] cryptsetup close and device in use when it is not
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="" 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: [gentoo-user] cryptsetup close and device in use when it is not
This is just a guess. Maybe you have two devices with the same UUID? If so, you can change it with: $ cryptsetup --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 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] cryptsetup close and device in use when it is not
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: [gentoo-user] cryptsetup close and device in use when it is not
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 >> <<>> >> 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? H. 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. > >
Re: [gentoo-user] cryptsetup close and device in use when it is not
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 > <<>> > 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? H. 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
Re: [gentoo-user] cryptsetup close and device in use when it is not
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 <<>> 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? H. 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: [gentoo-user] cryptsetup close and device in use when it is not
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: [gentoo-user] cryptsetup close and device in use when it is not
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: [gentoo-user] cryptsetup close and device in use when it is not
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 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] cryptsetup close and device in use when it is not
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: [gentoo-user] cryptsetup close and device in use when it is not
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: [gentoo-user] cryptsetup close and device in use when it is not
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: [gentoo-user] cryptsetup close and device in use when it is not
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 OpenPGP_signature Description: OpenPGP digital signature
[gentoo-user] 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. :/