[pkg-cryptsetup-devel] Bug#916649: Bug#916649: crytpsetup:

[rsev at riseup.net]

On 2018-12-19 12:13, Guilhem Moulin wrote:
> On Wed, 19 Dec 2018 at 04:59:47 -0800, rsev at 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