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
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
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 PasswordAgent
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=diskname 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-distributions.
I
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
On 2013-06-25 17:47, Michael Biebl wrote:
Am 25.06.2013 13:13, schrieb Harald Jenny:
Dear Michael Biebl,
following the systemd survey and discussion I think these mails might
be
of interest to you concerning possible ways to solve the current issue
(not only in Debian but also SuSE/upstream
