[pkg-cryptsetup-devel] new cryptsetup version breaks local setups

[Guilhem Moulin]

Hi Marc,

On Tue, 19 Jun 2018 at 13:10:29 +0200, Marc Haber wrote:
> However, after upgrading from 2.0.2 to 2.0.3, I found my system unable
> to boot. I use a local script to unlock the root file system, which
> sources /lib/cryptsetup/cryptsetup.functions and uses the
> handle_crypttab_line_start function to do it work. Since this function
> is gone, the system doesn't boot. Going back to cryptsetup 2.0.2 fixed
> the issue for me.
> 
> I am aware that I am using an internal interface, hence not a bug report
> but this message. I just want you to be aware that there are people
> using those internal interfaces that went away with this update which
> only touched a third-level version number.
> 
> I will have to adapt my scheme and hope that I can cope with that. And
> sadly, I do not have a solution to avoid those things in the future. Do
> you plan doing similiarly invasive changes in the near future or can I
> start my adaption work right now?

I'm about to upload 2:2.0.3-5, and would like to try to stabilize a
public interface some time after that.  But just so you know,
setup_mapping() doesn't take any argument anymore, instead it uses
hardcorded variable names CRYPTTAB_{NAME,SOURCE,KEY,OPTIONS}.  FWIW this
change follows the recent refactoring of the crypttab(5) parsing logic:

    https://salsa.debian.org/cryptsetup-team/cryptsetup/commit/cb5985935713deb6bd4fd45c77d1f54cc28b204b

Using hardcoded CRYPTTAB_* names is also consistent with what the option
parsing logic does, namely setting CRYPTTAB_OPTION_<option> variables
that can be accessed further down the execution path.

Cheers,
-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20180707/8b87dc93/attachment.sig>