On Fri, 24.04.15 13:37, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:
> >> the exact name of the option and semantics to specify it to
> >> initramfs-tools is different from dracut's (but that's typical) but
> >> said equivalent feature does exist in the major other initramfs
> >> implem
On 24 April 2015 at 10:06, Lennart Poettering wrote:
> On Thu, 23.04.15 21:04, Dimitri John Ledkov (dimitri.j.led...@intel.com)
> wrote:
>
>> On 23 April 2015 at 13:08, Lennart Poettering wrote:
>> > On Thu, 23.04.15 19:33, Andrei Borzenkov (arvidj...@gmail.com) wrote:
>> >
>> >> > > > What does
On Fri, 24.04.15 09:05, Jan Synacek (jsyna...@redhat.com) wrote:
> Lennart Poettering writes:
>
> > On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote:
> >
> > Sorry for the late review.
> >
> > What's the precise background of this? Can you elaborate? Is there
> > some feature requ
On Thu, 23.04.15 21:04, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:
> On 23 April 2015 at 13:08, Lennart Poettering wrote:
> > On Thu, 23.04.15 19:33, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> >
> >> > > > What does this actually do? Is the specified key file read from the
> >>
Lennart Poettering writes:
> On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote:
>
> Sorry for the late review.
>
> What's the precise background of this? Can you elaborate? Is there
> some feature request for this?
Hi,
I can see that Andrei already answered most of your questions.
On 23 April 2015 at 13:08, Lennart Poettering wrote:
> On Thu, 23.04.15 19:33, Andrei Borzenkov (arvidj...@gmail.com) wrote:
>
>> > > > What does this actually do? Is the specified key file read from the
>> > > > specified device?
>> > >
>> > > It reads keyfile from filesystem on device identifed
On Thu, 23.04.15 19:33, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> > > > What does this actually do? Is the specified key file read from the
> > > > specified device?
> > >
> > > It reads keyfile from filesystem on device identifed by keyfile_device.
> > >
> > > > The order
В Thu, 23 Apr 2015 16:57:09 +0200
Lennart Poettering пишет:
> On Thu, 23.04.15 06:41, Andrei Borzenkov (arvidj...@gmail.com) wrote:
>
> > В Thu, 23 Apr 2015 00:48:38 +0200
> > Lennart Poettering пишет:
> >
> > > On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote:
> > >
> > > Sorr
On Thu, 23.04.15 06:41, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> В Thu, 23 Apr 2015 00:48:38 +0200
> Lennart Poettering пишет:
>
> > On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote:
> >
> > Sorry for the late review.
> >
> > What's the precise background of this? Can you
В Thu, 23 Apr 2015 00:48:38 +0200
Lennart Poettering пишет:
> On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote:
>
> Sorry for the late review.
>
> What's the precise background of this? Can you elaborate? Is there
> some feature request for this?
>
There are multiple bug report
On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote:
Sorry for the late review.
What's the precise background of this? Can you elaborate? Is there
some feature request for this?
What does this actually do? Is the specified key file read from the
specified device? The order of keyfile
Andrei Borzenkov writes:
> В Fri, 20 Feb 2015 10:56:41 +0100
> Jan Synacek пишет:
>
>> First version of the patch that allows rd.luks.key to be specified almost
>> the same way as dracut can
>> read it.
>>
>
> This sounds like working around dracut bug. Dracut already has code to
> deal with i
Andrei Borzenkov writes:
> В Fri, 20 Feb 2015 10:56:42 +0100
> Jan Synacek пишет:
>
>> To be more consistent with how dracut parses rd.luks.key, it is now
>> allowed to specified it in the format "keyfile[:keyfile_device]".
>>
>> Should keyfile_device be provided, it needs to be in "UUID=uuid-h
В Fri, 20 Feb 2015 10:56:42 +0100
Jan Synacek пишет:
> To be more consistent with how dracut parses rd.luks.key, it is now
> allowed to specified it in the format "keyfile[:keyfile_device]".
>
> Should keyfile_device be provided, it needs to be in "UUID=uuid-here"
> format. Also, keyfile path is
В Fri, 20 Feb 2015 12:20:09 +0100
Przemyslaw Rudy пишет:
> Right, not in the doc. In fedora it is used in:
> /usr/lib/dracut/modules.d/90crypt/parse-crypt.sh
>
It is also upstream.
> Simply a device timeout in seconds.
>
> On 02/20/2015 11:53 AM, Jan Synacek wrote:
> > Przemyslaw Rudy writes
В Fri, 20 Feb 2015 10:56:41 +0100
Jan Synacek пишет:
> First version of the patch that allows rd.luks.key to be specified almost the
> same way as dracut can
> read it.
>
This sounds like working around dracut bug. Dracut already has code to
deal with it, it updates /etc/crypttab and reload sy
On Fri, Feb 20, 2015 at 11:15:36AM +0100, Przemyslaw Rudy wrote:
> Could you use the rd.luks.key.tout= instead of hardcoded
> JobTimeoutSec=30, as the dracut does?
Maybe we could rename it to rd.luks.key.device-timeout= ? tout is not
really descriptive. (Old name should be kept for comptibility, th
Right, not in the doc. In fedora it is used in:
/usr/lib/dracut/modules.d/90crypt/parse-crypt.sh
Simply a device timeout in seconds.
On 02/20/2015 11:53 AM, Jan Synacek wrote:
> Przemyslaw Rudy writes:
>
>> Could you use the rd.luks.key.tout= instead of hardcoded
>> JobTimeoutSec=30, as the dr
Przemyslaw Rudy writes:
> Could you use the rd.luks.key.tout= instead of hardcoded
> JobTimeoutSec=30, as the dracut does?
I didn't know about such parameter. In fact, I don't see it anywhere in
dracut.cmdline(5). If it really exists and just isn't documented, then
yes, it would probably make se
Could you use the rd.luks.key.tout= instead of hardcoded
JobTimeoutSec=30, as the dracut does?
On 02/20/2015 10:56 AM, Jan Synacek wrote:
> To be more consistent with how dracut parses rd.luks.key, it is now
> allowed to specified it in the format "keyfile[:keyfile_device]".
>
> Should keyfile_de
To be more consistent with how dracut parses rd.luks.key, it is now
allowed to specified it in the format "keyfile[:keyfile_device]".
Should keyfile_device be provided, it needs to be in "UUID=uuid-here"
format. Also, keyfile path is then treated relatively to the root of the
keyfile device.
If n
First version of the patch that allows rd.luks.key to be specified almost the
same way as dracut can
read it.
The solution creates a temporary mount unit "mnt.mount" that the generated
cryptsetup service wants.
The partition where the keyfile is then mounted to /mnt and the absolute path
to the
22 matches
Mail list logo
