Hi all,
I stumbled on this, too but I have a work-around for at least 'decrypt_keyctl'.
systemd uses systemd-cryptsetup -> systemd-ask-password -> linux keyring.
The keyring can be modified by keyctl just as 'decrypt_keyctl' does.
As I wanted to use 'decrypt_keyctl' for unlocking root and data
> > Workaround: add "luks=no" to the kernel command line to disable
> systemd's generator
>
> This worked great... until you try to add another partition to crypttab.
> Since the cryptroot in initrd only does root, but luks=no disables all
> others.
>
> Is there any clean solution that
Package: systemd
Version: 231-4
Followup-For: Bug #618862
Hello,
I also run into this issue while trying to mount 2 disks (LUKS + VeraCrypt)
encrypted with the same passphrase during boot.
Is there any progress on this bug?
Greetings,
Bruno
-- Package-specific info:
***
maybe i should have given more details about my suggested solution.
create your partitions as usual, but create one partition big enough to
store all your encrypted data:
/dev/sda1 -> /boot
/dev/sda2 -> all encrypted data
...
encrypt the desired partition:
cryptsetup ... create
the only clean solution that i have found so far. put the encryption on
the blockdevice and use LVM for partitioning. if you have multiple
disks, use software raid, encryption on the raid blockdevice and LVM for
partitioning. that is only a workaround which prevents the requirement
to define
> Workaround: add "luks=no" to the kernel command line to disable
systemd's generator
This worked great... until you try to add another partition to crypttab.
Since the cryptroot in initrd only does root, but luks=no disables all
others.
E.g. if crypttab looks like
root /dev/sda1
I tested Marcello’s workaround. It works! That’s wonderful! Thank you so
much, Marcello!
Now some further thoughts on the subject…
It’s a workaround for this bug, but, unfortunately it’s just a workaround not a
real fix. In particular, using a “luks=no” kernel command line option disables
>> Does this work for encrypted root as well?
> FTR, systemd isn't involved in unlocking the root file system, that
> already (has to) happen in the initramfs. So this can only affect
> non-root file systems.
With the setup I've detailed above (encrypted LUKS root
unlocked via the passdev
Rick Thomas [2015-10-16 8:40 -0700]:
> Does this work for encrypted root as well?
FTR, systemd isn't involved in unlocking the root file system, that
already (has to) happen in the initramfs. So this can only affect
non-root file systems.
--
Martin Pitt|
> On Sat, 19 Mar 2011 03:40:25 +0100 Mourad De Clerck wrote:
> my root and swap partition are encrypted with cryptsetup; root uses a custom
> keyscript and swap uses the cryptsetup-provided "decrypt_derived" keyscript.
> systemd seems to be unable to work with keyscripts at all
I confirm the same
On Oct 16, 2015, at 3:02 AM, Marcello Barnaba wrote:
>> On Sat, 19 Mar 2011 03:40:25 +0100 Mourad De Clerck wrote:
>> my root and swap partition are encrypted with cryptsetup; root uses a custom
>> keyscript and swap uses the cryptsetup-provided "decrypt_derived" keyscript.
>>
>> Workaround: add "luks=no" to the kernel command line to disable systemd's
>> generator:
>> http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html
> Does this work for encrypted root as well? Or is it only for things like
> swap and /home that can wait until
On Oct 16, 2015, at 9:20 AM, Marcello Barnaba wrote:
>
>>> Workaround: add "luks=no" to the kernel command line to disable systemd's
>>> generator:
>>> http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html
>
>> Does this work for encrypted root
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
Hello,
In case someone else needs it, a workaround for the common
use case of using the `decrypt_derived` keyscript to unlock partitions
is to save the derived key into a file on the encrypted partition that
you would otherwise derive from (make sure only root can access it).
This at least
Hi,
I'm also affected by this problem. Very simple setup, encrypted root
and swap via decrypt_derived so I can suspend to disk:
/etc/crypttab:
sda5_crypt UUID=2fa9feb8-b096-41f7-bf17-41399ccc8004 none luks
sda4_crypt UUID=6d3382e4-58fc-4f10-9346-276bbc127e78 sda5_crypt
On Mon, Mar 30, 2015 at 11:28 AM, Marco d'Itri m...@linux.it wrote:
I should add some code to preinst to abort the installation if the
keyscript directive is used in crypttab.
Would that still leave the system in a broken state though? Is preinst
early enough to avoid breakage due to
On Mar 30, Brainslug brains...@freakmail.de wrote:
Any progress on this? I would think this needs to be fixed before jessie
can be released, otherwise a lot of systems out there will break?
While both we and the upstream maintainers believe that continuing to
support this feature is a good
Am 30.03.2015 um 19:39 schrieb Ivan Jager:
On Mon, Mar 30, 2015 at 11:28 AM, Marco d'Itri m...@linux.it wrote:
I should add some code to preinst to abort the installation if the
keyscript directive is used in crypttab.
Would that still leave the system in a broken state though? Is preinst
Source: systemd
Followup-For: Bug #618862
Is there a solution to this issue?
I'm currently using debian sid + sysvinit because I can't switch to systemd.
This is my setup:
root:~# lsblk -f
NAME FSTYPE LABEL UUID
MOUNTPOINT
sda
├─sda1 ntfs
Hi,
I have the same issue as Evgeni above in a similar set-up and can
provide a bit more information. It seems some alignment is needed
between packages cryptsetup, initramfs-tools and systemd.
In the cryptsetup documentation, there is a README on how to
configure an encrypted
Version: 208-6
On Sat, Mar 19, 2011 at 03:40:25AM +0100, Mourad De Clerck wrote:
my root and swap partition are encrypted with cryptsetup; root uses a custom
keyscript and swap uses the cryptsetup-provided decrypt_derived keyscript.
systemd seems to be unable to work with keyscripts at all,
severity #618862 important
thanks
On Sat, Mar 19, 2011 at 03:40:25AM +0100, Mourad De Clerck wrote:
my root and swap partition are encrypted with cryptsetup; root uses a custom
keyscript and swap uses the cryptsetup-provided decrypt_derived keyscript.
systemd seems to be unable to work with
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
Oh and I forget (but it seems this is already clear as well):
keyscripts may make use of arbitrary other programs... OpenSSL, pcscd,
gpg, etc. pp.
I've just attached my own keyscript to give an example (just the script,
not the initramfs-tools hook or documentation).
The biggest problem is
Hi.
Had a private conversation with Tollef and he pointed me to this bug...
Even though it may be obvious to any developer, let me add the
following:
I had a short glance at
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n54
I guess another crypt_activate_by_?
On Tue, Jun 25, 2013 at 05:47:19PM +0200, 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
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 interest).
http://lists.freedesktop.org/archives/systemd-devel/2012-June/thread.html#5693
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 interest).
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n45
/* Options Debian's crypttab knows we don't:
offset=
skip=
precheck=
check=
checkargs=
noearly=
loud=
keyscript=
*/
--
Why is it that all of the instruments seeking intelligent life
Package: systemd
Version: 19-1
Severity: normal
Hi,
my root and swap partition are encrypted with cryptsetup; root uses a custom
keyscript and swap uses the cryptsetup-provided decrypt_derived keyscript.
systemd seems to be unable to work with keyscripts at all, and requires
password input for
36 matches
Mail list logo