On 2015-05-26 00:05, Alberto Bertogli wrote:
I hit this issue after upgrading a system that used keyscript to
Jessie,
and it would no longer boot with systemd [1].
That led me to look into adding a password agent for my use case,
and/or
creating a generic one that would invoke keyscripts as a
I hit this issue after upgrading a system that used keyscript to Jessie,
and it would no longer boot with systemd [1].
That led me to look into adding a password agent for my use case, and/or
creating a generic one that would invoke keyscripts as a workaround...
On Wed, Feb 05, 2014 at 12:16:00
On Sat, 08.02.14 21:07, David Härdeman (da...@hardeman.nu) wrote:
>
> On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:
> >On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote:
> >> This issue is fixable with minor upstream changes, e.g. by extending
> >> the Passwor
On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:
>On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote:
>> This issue is fixable with minor upstream changes, e.g. by extending
>> the PasswordAgent protocol to add "Subsystem=cryptsetup" and
>> "Target=" entries to the
]] Lennart Poettering
> > a) the cryptsetup package
> >
> > b) as part of the Debian systemd package
> >
> > c) upstream systemd
>
> I'd prefer to keep this tool in a Debian-specific package. I am not
> convinced that the key script thing is something we should standardize
> on cross-distribut
On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote:
> a) getting the name of the cryptdev that the password request
> corresponds to currently involves parsing the prompt message
> ("Please enter passphrase for disk %s!") which is obviously not a
> real solution...
>
> This issue is
6 matches
Mail list logo