Bug#916649: [pkg-cryptsetup-devel] Bug#916649: crytpsetup:
On Thu, 20 Dec 2018 at 05:38:50 -0800, r...@riseup.net wrote: > On 2018-12-19 22:14, Guilhem Moulin wrote: >> On Wed, 19 Dec 2018 at 12:13:25 -0800, r...@riseup.net wrote: >>> I see. What would you suggest as a proper solution to this situation? >> >> How about what's now the title of this bug? :-) > > I'm sorry. I don't follow. How would I do it exactly? Our initramfs hook has code to determine which dm-crypt device(s) are holding a given mountpoint, which could be factored in and used in do_stop(). https://salsa.debian.org/cryptsetup-team/cryptsetup/blob/master/debian/initramfs/hooks/cryptroot#L60 I'm afraid I don't have time for further mentoring here. That said, it's not because you filed this bug that you need to fix it. We package maintainers will probably implement the fix ourselves, unless another affected user chimes in before. -- Guilhem. signature.asc Description: PGP signature
Bug#916649: [pkg-cryptsetup-devel] Bug#916649: crytpsetup:
On 2018-12-19 22:14, Guilhem Moulin wrote: > On Wed, 19 Dec 2018 at 12:13:25 -0800, r...@riseup.net wrote: >> I see. What would you suggest as a proper solution to this situation? > > How about what's now the title of this bug? :-) I'm sorry. I don't follow. How would I do it exactly? Regards, Rodrigo
Bug#916649: [pkg-cryptsetup-devel] Bug#916649: crytpsetup:
On Wed, 19 Dec 2018 at 12:13:25 -0800, r...@riseup.net wrote: > I see. What would you suggest as a proper solution to this situation? How about what's now the title of this bug? :-) -- Guilhem. signature.asc Description: PGP signature
Bug#916649: [pkg-cryptsetup-devel] Bug#916649: crytpsetup:
On 2018-12-19 12:13, Guilhem Moulin wrote: > On Wed, 19 Dec 2018 at 04:59:47 -0800, r...@riseup.net wrote: >> When I manually applied the patch from #5, my shutdown sequence worked >> just fine (without hanging). > > Dunno what Devuan ships, but that patch simply doesn't apply to the > debian/cryptdisks.functions from cryptsetup 2:1.7.3-4: I apllied it manually. > https://sources.debian.org/src/cryptsetup/2:1.7.3-4/debian/cryptdisks.functions/#L764 > > What does cryptdisks.functions:do_stop() looks like after your > modifications? FWIW, I see two issues with the proposed patch from > #792552's 5th message: > > 1. The inner loop is run in a sub-shell, so changing the value of the > ‘ITERATE’ variable there has no effect in the outer loop. > > 2. Both our /etc/init.d/cryptdisks and /etc/init.d/cryptdisks-early > scripts are run with `set -e`, so if handle_crypttab_line_stop()'s > return code is not 0 then the script errors out immediately. > > I believe that's why your system doesn't hang anymore. The device > that's holding the root file system is busy (regardless of LVM, / and > /usr are still mounted) hence can't be closed, making the init script > error out instead of retrying and/or closing other devices defined in > /etc/crypttab. It shortens the shutdown sequence by 30s or so, but it > also breaks the intended semantics, namely closing all dm-crypt devices > that can be closed. > >>> /etc/init.d/lvm2 no longer deactivates LVs on shutdown since lvm2 >>> ≥2.02.84-3. But I don't see which doing so should be the job of >>> /etc/init.d/cryptsetup instead. >> >> I understand your reasoning. So this should be changed from a cryptsetup >> bug to a lvm one? > > Perhaps /etc/init.d/lvm2 should deactivate LVs that are not required > further down the shutdown sequence (such as those holding / or /usr), > but it won't be able to deactivate everything either. The dm type > (dm-crypt, linear, etc.) is irrelevant, if the mapped device is holding > / or /usr then it should be preserved. > >>> Regardless, we won't be able to lock devices holding / or /usr. AFAICT >>> that's where `/etc/init.d/cryptdisks stop` is choking with the repeated >>> “… is busy” messages. For these devices the script might as well return >>> failure immediately and not try again. >> >> That sounds like a rather _brute_ solution but it might just as well >> work. > > How so? With the patch from #792552's 5th message *all* busy dm-crypt > devices (more generally *all* devices that can't be closed on first > try), are left open as well. > > /etc/init.d/cryptdisks and /etc/init.d/cryptdisks-early are *not* run > last in the shutdown sequence, so at this stage the root file system > (and /usr) still needs to be present. Hence there no way we can > reliably close underlying dm-crypt and/or linear (LVM2) devices. We can > close devices holding other file systems though, since they should be > unmounted at that point. I see. What would you suggest as a proper solution to this situation? Rodrigo
Bug#916649: [pkg-cryptsetup-devel] Bug#916649: crytpsetup:
On Wed, 19 Dec 2018 at 04:59:47 -0800, r...@riseup.net wrote: > When I manually applied the patch from #5, my shutdown sequence worked > just fine (without hanging). Dunno what Devuan ships, but that patch simply doesn't apply to the debian/cryptdisks.functions from cryptsetup 2:1.7.3-4: https://sources.debian.org/src/cryptsetup/2:1.7.3-4/debian/cryptdisks.functions/#L764 What does cryptdisks.functions:do_stop() looks like after your modifications? FWIW, I see two issues with the proposed patch from #792552's 5th message: 1. The inner loop is run in a sub-shell, so changing the value of the ‘ITERATE’ variable there has no effect in the outer loop. 2. Both our /etc/init.d/cryptdisks and /etc/init.d/cryptdisks-early scripts are run with `set -e`, so if handle_crypttab_line_stop()'s return code is not 0 then the script errors out immediately. I believe that's why your system doesn't hang anymore. The device that's holding the root file system is busy (regardless of LVM, / and /usr are still mounted) hence can't be closed, making the init script error out instead of retrying and/or closing other devices defined in /etc/crypttab. It shortens the shutdown sequence by 30s or so, but it also breaks the intended semantics, namely closing all dm-crypt devices that can be closed. >> /etc/init.d/lvm2 no longer deactivates LVs on shutdown since lvm2 >> ≥2.02.84-3. But I don't see which doing so should be the job of >> /etc/init.d/cryptsetup instead. > > I understand your reasoning. So this should be changed from a cryptsetup > bug to a lvm one? Perhaps /etc/init.d/lvm2 should deactivate LVs that are not required further down the shutdown sequence (such as those holding / or /usr), but it won't be able to deactivate everything either. The dm type (dm-crypt, linear, etc.) is irrelevant, if the mapped device is holding / or /usr then it should be preserved. >> Regardless, we won't be able to lock devices holding / or /usr. AFAICT >> that's where `/etc/init.d/cryptdisks stop` is choking with the repeated >> “… is busy” messages. For these devices the script might as well return >> failure immediately and not try again. > > That sounds like a rather _brute_ solution but it might just as well > work. How so? With the patch from #792552's 5th message *all* busy dm-crypt devices (more generally *all* devices that can't be closed on first try), are left open as well. /etc/init.d/cryptdisks and /etc/init.d/cryptdisks-early are *not* run last in the shutdown sequence, so at this stage the root file system (and /usr) still needs to be present. Hence there no way we can reliably close underlying dm-crypt and/or linear (LVM2) devices. We can close devices holding other file systems though, since they should be unmounted at that point. -- Guilhem. signature.asc Description: PGP signature
Bug#916649: [pkg-cryptsetup-devel] Bug#916649: crytpsetup:
On 2018-12-16 23:43, Guilhem Moulin wrote: > Control: retitle -1 `/etc/init.d/cryptdisks stop` should ignore > devices holding / and /usr > Control: severity -1 wishlist > > Hi, > > On Sun, 16 Dec 2018 at 13:28:37 -0800, r...@riseup.net wrote: >> When shuting down my Devuan LVM + LUKS install, it hangs just at the end >> of the shutdown sequence presenting messages like "sda5_crypt is busy" >> and "sdb_crypt is busy". Only after 30 seconds or so pass, it acatully >> shuts down. > > https://tracker.debian.org/news/181876/accepted-lvm2-20284-3-source-amd64/ > >> Aplying one the patchs available at >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792552#5 or > > Which patch? something equivalent to #5 is already present in 2:1.7.3-4 When I manually applied the patch from #5, my shutdown sequence worked just fine (without hanging). > Or do you mean `dmsetup remove_all` from #24? Didn't try that. I can't say if it would work. > Like for > >> https://bugs.devuan.org//cgi/bugreport.cgi?bug=237 fixes the problems >> just fine for me. The patch available here also solved this issue for me. Just to be clear, either one of the patches, apllied separately, solved this issue for me. > /etc/init.d/lvm2 no longer deactivates LVs on shutdown since lvm2 > ≥2.02.84-3. But I don't see which doing so should be the job of > /etc/init.d/cryptsetup instead. I understand your reasoning. So this should be changed from a cryptsetup bug to a lvm one? > Regardless, we won't be able to lock devices holding / or /usr. AFAICT > that's where `/etc/init.d/cryptdisks stop` is choking with the repeated > “… is busy” messages. For these devices the script might as well return > failure immediately and not try again. That sounds like a rather _brute_ solution but it might just as well work. Regards, Rodrigo
Bug#916649: [pkg-cryptsetup-devel] Bug#916649: crytpsetup:
Control: retitle -1 `/etc/init.d/cryptdisks stop` should ignore devices holding / and /usr Control: severity -1 wishlist Hi, On Sun, 16 Dec 2018 at 13:28:37 -0800, r...@riseup.net wrote: > When shuting down my Devuan LVM + LUKS install, it hangs just at the end > of the shutdown sequence presenting messages like "sda5_crypt is busy" > and "sdb_crypt is busy". Only after 30 seconds or so pass, it acatully > shuts down. https://tracker.debian.org/news/181876/accepted-lvm2-20284-3-source-amd64/ > Aplying one the patchs available at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792552#5 or Which patch? something equivalent to #5 is already present in 2:1.7.3-4 https://sources.debian.org/src/cryptsetup/2:1.7.3-4/debian/cryptdisks.functions/#L765 Or do you mean `dmsetup remove_all` from #24? Like for > https://bugs.devuan.org//cgi/bugreport.cgi?bug=237 fixes the problems > just fine for me. /etc/init.d/lvm2 no longer deactivates LVs on shutdown since lvm2 ≥2.02.84-3. But I don't see which doing so should be the job of /etc/init.d/cryptsetup instead. Regardless, we won't be able to lock devices holding / or /usr. AFAICT that's where `/etc/init.d/cryptdisks stop` is choking with the repeated “… is busy” messages. For these devices the script might as well return failure immediately and not try again. Cheers, -- Guilhem. signature.asc Description: PGP signature
