On 1/13/19 10:38 PM, y...@marupa.net wrote:
>
> No need to use the luksHeaderRestore/luksHeaderBackup. You can create
> and use a detached LUKS header with the --header parameter. You can use
> --header, combined with a zero offset on the device and no partition
> table and it should, in theory, o
On Sun, 2019-01-13 at 22:31 -0500, brent s. wrote:
> On 1/13/19 10:19 PM, brent s. wrote:
> > > Well, unencrypted partition table. What he wants is an encrypted
> > > partition table, and more generally no metadata available (so the
> > > disk
> > > just looks like plain garbage, not x nice labelle
On 1/13/19 10:19 PM, brent s. wrote:
>> Well, unencrypted partition table. What he wants is an encrypted
>> partition table, and more generally no metadata available (so the disk
>> just looks like plain garbage, not x nice labelled partitions with LUKS
>> headers).
also, the LUKS header is still
On 1/13/19 5:43 PM, Bruno Pagani via arch-general wrote:
> Le 13/01/2019 à 23:27, Eli Schwartz via arch-general a écrit :
>> The more complex method would be to copy the initramfs encrypt hook and
modify it to support an additional encrypted device with a different
password.
>>> I want fu
> This is interesting, partprobe seems to be an even lighter alternative.
It seems that partprobe indeed also works for device mapper maps.
Relevant links:
* A commit to the (c)fdisk man page that suggests using kpartx or
partprobe when the BLKRRPART ioctl fails (I wonder why that was not
upstrea
Le 14/01/2019 à 00:22, Merlin Büge a écrit :
> On Sun, 13 Jan 2019 08:56:55 -0800 (PST)
> Neven Sajko via arch-general wrote:
>
>> To mount a root GPT partition which resides on an encrypted disk, one
>> needs the kpartx tool to make the mapping for the partition (the
>> kernel does not independen
On Sun, 13 Jan 2019 08:56:55 -0800 (PST)
Neven Sajko via arch-general wrote:
> To mount a root GPT partition which resides on an encrypted disk, one
> needs the kpartx tool to make the mapping for the partition (the
> kernel does not independently make those for partitions on device
> mapper m
On 1/13/19 6:00 PM, Neven Sajko via arch-general wrote:
>> It's your lucky day!
>>
>> I just pushed it to [community] as multipath-tools, please test it.
>
> That is awesome, Robin, thank you!
>
> Does somebody know what is the procedure for getting it in the iso? I
> should probably start by mak
> It's your lucky day!
>
> I just pushed it to [community] as multipath-tools, please test it.
That is awesome, Robin, thank you!
Does somebody know what is the procedure for getting it in the iso? I
should probably start by making a feature request for the archiso
package ...
Regards,
Neven Saj
On 1/13/19 11:50 PM, Robin Broda via arch-general wrote:
> On 1/13/19 5:56 PM, Neven Sajko via arch-general wrote:
>> To mount a root GPT partition which resides on an encrypted disk, one
>> needs the kpartx tool to make the mapping for the partition (the kernel
>> does not independently make those
On 1/13/19 5:56 PM, Neven Sajko via arch-general wrote:
> To mount a root GPT partition which resides on an encrypted disk, one
> needs the kpartx tool to make the mapping for the partition (the kernel
> does not independently make those for partitions on device mapper maps,
> which is what a dm-cr
> >> If you do need hibernation support, the simple method would be to use a
> >> swap file residing on the encrypted /
> >
> > Simple as in "already well supported", but not optimal, as swap
> > depends on a filesystem.
>
> Linux also depends on a filesystem. I'm not sure what you mean to imply.
Le 13/01/2019 à 23:27, Eli Schwartz via arch-general a écrit :
> The more complex method would be to copy the initramfs encrypt hook and
>>> modify it to support an additional encrypted device with a different
>>> password.
>> I want full disk encryption. There is nothing controversial about FDE,
>
On 1/13/19 5:27 PM, Eli Schwartz wrote:
>> I want full disk encryption. There is nothing controversial about FDE,
>> it is already covered in the Wiki, except that I want FDE without LVM.
>
> You can have FDE without LVM today, using the suggestion I just provided
> and you ignored.
>
> Unless yo
On 1/13/19 4:22 PM, Neven Sajko wrote:
>> If you do need hibernation support, the simple method would be to use a
>> swap file residing on the encrypted /
>
> Simple as in "already well supported", but not optimal, as swap
> depends on a filesystem.
Linux also depends on a filesystem. I'm not sur
Le 13/01/2019 à 22:22, Neven Sajko via arch-general a écrit :
>> Do you need the swap to be persistent across reboots in order to support
>> hibernation? If not, it is sufficient to have the swap mounted with a
>> randomized key.
> I would like to be able to resume from hibernation, yes.
>
>> If yo
> Do you need the swap to be persistent across reboots in order to support
> hibernation? If not, it is sufficient to have the swap mounted with a
> randomized key.
I would like to be able to resume from hibernation, yes.
> If you do need hibernation support, the simple method would be to use a
>
On 1/13/19 2:26 PM, Neven Sajko via arch-general wrote:
>> pardon for asking, but why in the heck would you want to partition the
>> encrypted volume? that is going to cause tenfold headache for you down
>> the road.
>>
>> --
>> brent saner
>> https://square-r00t.net/
>> GPG info: https://square-r0
> that... doesn't answer my question. fundamentally, and structurally, why
> do you think you want this instead of GPTing the disk itself and
> applying dm-crypt to the partitions? so, you know, it works with
> bootloaders.
I think I already explained that, if you add up my rationale for not
using
On 1/13/19 2:26 PM, Neven Sajko via arch-general wrote:
>> pardon for asking, but why in the heck would you want to partition the
>> encrypted volume? that is going to cause tenfold headache for you down
>> the road.
>>
>> --
>> brent saner
>> https://square-r00t.net/
>> GPG info: https://square-r0
On 1/13/19 2:26 PM, Neven Sajko via arch-general wrote:
>> pardon for asking, but why in the heck would you want to partition the
>> encrypted volume? that is going to cause tenfold headache for you down
>> the road.
>>
>> --
>> brent saner
>> https://square-r00t.net/
>> GPG info: https://square-r0
> pardon for asking, but why in the heck would you want to partition the
> encrypted volume? that is going to cause tenfold headache for you down
> the road.
>
> --
> brent saner
> https://square-r00t.net/
> GPG info: https://square-r00t.net/gpg-info
I need one partition for swap and one for the f
On 1/13/19 2:03 PM, Neven Sajko via arch-general wrote:
> To clarify, I am talking about something like this, but with GPT instead of
> LVM:
>
> https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt
>
pardon for asking, but why in the heck would you want to pa
To clarify, I am talking about something like this, but with GPT instead of LVM:
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt
> You don’t need kpartx though. Neither losetup or LVM. I did several
> encrypted GPT install without any of them, so I’m pretty confident about
> this.
You are probably thinking about an encrypted GPT partition. What I am
talking about is an encrypted GPT. To clarify, the partition table
itself (
Le 13/01/2019 à 17:56, Neven Sajko via arch-general a écrit :
> To mount a root GPT partition which resides on an encrypted disk, one
> needs the kpartx tool to make the mapping for the partition (the kernel
> does not independently make those for partitions on device mapper maps,
> which is what
To mount a root GPT partition which resides on an encrypted disk, one
needs the kpartx tool to make the mapping for the partition (the kernel
does not independently make those for partitions on device mapper maps,
which is what a dm-crypt decrypted device is). Thus kpartx needs to be
on the Archlin
27 matches
Mail list logo
