[arch-general] Kpartx should be in the repos and archiso for enabling encrypted GPT install
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 Archlinux installation ISO to enable that kind of setup. It would of course first be necessary for an Archlinux Developer or Trusted User to adopt kpartx, so I hope there is somebody willing to do this ...? Note that kpartx is a common utility and in its own package across a lot of distributions; like Debian, Ubuntu, Fedora, OpenSUSE, ... Note: it may be possible to use losetup instead of kpartx so as to make a loop device instead of a device map, but that would come with an overhead? Another alternative setup, perhaps more widely used, is having encrypted LVM. While this does not require kpartx, LVM may be undesireable because of its complexity and requiring multiple userspace daemons beside Udev. Appended is an example PKGBUILD which only installs the kpartx executable and manual page: pkgname=(kpartx) pkgver=0.7.9 pkgrel=1 pkgdesc='Create device mapper maps for partitions in devices or files' arch=(x86_64) url='http://christophe.varoqui.free.fr' license=(LGPL GPL GPL2) depends=(device-mapper) makedepends=(gzip) source=('mpt.tar.gz::https://git.opensvc.com/?p=multipath-tools/.git;a=snapshot;h=5c67a8b5944dd13...') md5sums=() sha512sums=('d4abc9580b6a3e457c99bee96d5aaab29a984ae77f91cbbe52e1b4af16809319a9100c45ce5600242fa52819dd44a9cb77e13305bc4f9651c532906243f2d544') build() { cd multipath-tools-5c67a8b/kpartx gcc -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DLIBDM_API_COOKIE -l devmapper -o kpartx $CPPFLAGS $CFLAGS $LDFLAGS *.c gzip kpartx.8 } package() { cd multipath-tools-5c67a8b/kpartx install -d "$pkgdir/usr/bin" install -m 755 kpartx "$pkgdir/usr/bin" install -d "$pkgdir/usr/share/man/man8" install -m 644 kpartx.8.gz "$pkgdir/usr/share/man/man8" }
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 a dm-crypt decrypted device is). Thus kpartx needs to be on the Archlinux installation ISO to enable that kind of setup.
It would of course first be necessary for an Archlinux Developer or Trusted User to adopt kpartx, so I hope there is somebody willing to do this ...? Note that kpartx is a common utility and in its own package across a lot of distributions; like Debian, Ubuntu, Fedora, OpenSUSE, ...
Note: it may be possible to use losetup instead of kpartx so as to make a loop device instead of a device map, but that would come with an overhead? Another alternative setup, perhaps more widely used, is having encrypted LVM. While this does not require kpartx, LVM may be undesireable because of its complexity and requiring multiple userspace daemons beside Udev.
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. Could you instead describe your actual issue that make you think kpartx is required? Regards, Bruno
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 (the whole disk) should be encrypted in the scenario.
Could you instead describe your actual issue that make you think kpartx is required?
Regards, Bruno
As I said in the first mail, the kernel does not automatically recognize partitions on device maps, unlike on sd devices. Regards, Neven Sajko
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#Pl...
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#Pl...
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
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 filesystem mounted on /.
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-r00t.net/gpg-info
I need one partition for swap and one for the filesystem mounted on /.
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. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
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-r00t.net/gpg-info
I need one partition for swap and one for the filesystem mounted on /.
also worth noting, your system clock is an hour ahead of what it should be -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
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 LVM with the link to the ArchWiki. Basically, I want full disk encryption (thus https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Pl... ), but without LVM. Full disk encryption is "more secure" and the LVM software is too heavy.
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-r00t.net/gpg-info
I need one partition for swap and one for the filesystem mounted on /.
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. If you do need hibernation support, the simple method would be to use a swap file residing on the encrypted / 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. None of this needs kpartx. -- Eli Schwartz Bug Wrangler and Trusted User
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 swap file residing on the encrypted /
Simple as in "already well supported", but not optimal, as swap depends on a filesystem.
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, it is already covered in the Wiki, except that I want FDE without LVM.
None of this needs kpartx.
-- Eli Schwartz Bug Wrangler and Trusted User
Thank you for input, indeed all your suggestions would work, but I am going for the optimal solution here, and kpartx (or an equivalent devmapper program) seems to be a requirement for that. Regards, Neven Sajko
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 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.
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, it is already covered in the Wiki, except that I want FDE without LVM.
None of this needs kpartx. Thank you for input, indeed all your suggestions would work, but I am going for the optimal solution here, and kpartx (or an equivalent devmapper program) seems to be a requirement for that.
OK, I know understand your requirements and indeed something like kpartx is required if you want to be independent from LVM or the filesystem. I’m not sure what adding it in the ISO would require (outside having it in the repo of course), but anyway you can still add it yourself it if you have an internet access during installation. ;) Feel free to enhance the wiki with this example, being quite different from the LVM one it might interest others, and eventually lead to the inclusion of kpartx in the repos (and latter maybe even in the ISO, though again I’m not sure about the criterion here). Regards, Bruno
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 sure what you mean to imply.
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, 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 you mean that it's not really FDE if attackers can read the partition table layout, in which case LVM is not valid as FDE and you'd better buy yourself some proprietary hardware-encrypted solution.
None of this needs kpartx.> Thank you for input, indeed all your suggestions would work, but I am going for the optimal solution here, and kpartx (or an equivalent devmapper program) seems to be a requirement for that.
The optimal solution according to what metric? If you really want kpartx, nothing stops you from going right here and installing it yourself: https://aur.archlinux.org/packages/multipath-tools/ Since you observed that losetup could be used on the ISO, I guess you could install using supported kernel interfaces, then switch to kpartx on your installed system. For bonus points, you could build the kpartx binary on the ISO and use it in the installation process, since it is not critical infrastructure for connecting to the internet. It would be work, but not a lot of work. The software does not seem to have a lot of dependencies... ... But I still do not understand what practical benefits you are seeking that are not solved by having multiple encrypted partitions on an unencrypted partition table. -- Eli Schwartz Bug Wrangler and Trusted User
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 you mean that it's not really FDE if attackers can read the partition table layout, in which case LVM is not valid as FDE and you'd better buy yourself some proprietary hardware-encrypted solution.
... forgot lvm supports installation without a partition table. Still don't see the practical downside of having an unencrypted partition table. -- Eli Schwartz Bug Wrangler and Trusted User
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, 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 you mean that it's not really FDE if attackers can read the partition table layout, in which case LVM is not valid as FDE and you'd better buy yourself some proprietary hardware-encrypted solution.
Readable partition table layout is exactly the issue (and you answered yourself about your LVM mistake).
But I still do not understand what practical benefits you are seeking that are not solved by having multiple encrypted partitions on an unencrypted partition table.
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). They are not a lot of choices for that: you need a plain dm-crypt container on the whole disk, and then being able to partition inside that. Which leaves LVM2 (too big tool for OP), filesystems with such a feature (ZFS, Btfrs; but that is then fs-dependent), or tools like kpartx. So kpartx is the right tool for what he wants. Regards, Bruno
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 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 you mean that it's not really FDE if attackers can read the partition table layout, in which case LVM is not valid as FDE and you'd better buy yourself some proprietary hardware-encrypted solution.
Readable partition table layout is exactly the issue (and you answered yourself about your LVM mistake).
plausible deniability only works if it doesn't look like you're hiding something. given the mention of wanting to encrypt /, i'm assuming this is intended to be a live OS. that means you still need unencrypted boot code in *some* form, even if you use [0] or [1]. sure, you can keep your boot code on a separate USB dongle or what have you, but for UEFI that entry is still going to be in there (unless you're booting to an EFI shell and manually booting every time). hence my "increasing headache tenfold" comment earlier.
But I still do not understand what practical benefits you are seeking that are not solved by having multiple encrypted partitions on an unencrypted partition table.
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).
see above. FDE, even "full" FDE, is not a magic bullet. if your threat model is so serious that you're worried about people *knowing* you have an encrypted disk, OpSec is going to save you more than encryption. otherwise, FDE's just one *part* of a robust security protocol. generally speaking, when your threat model is that of the above, it's *far* better to: - have a "normal-looking" OS installed on the computer with some (fake) photos of "family", some fake documents here and there, some fake browsing history, etc. on... - an unencrypted system partition - and use a separate easily physically hidden (encrypted) actual OS on a thumbdrive - with *access* to a remote resource that has your real data, not the real data on the thumbdrive itself and then throw that entire kit away after whatever operation you've done is complete and you're back in a safe zone and never use it again. that's a lot less suspicious (and a lot less likely to attract attention to yourself - the very LAST thing you want if you truly believe and are a valuable target) than walking around with a device that's obviously being used yet has a disk full of what looks like random data. however, if you're just trying to prevent against joe blow getting your ssh keys in case your laptop gets stolen or lost, encrypting the partition table gains you nothing except unnecessary work. ROI. [0] https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#En...) [1] https://github.com/xmikos/cryptboot -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
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 there whether it's on the partition or the whole disk. you're in no way obligated to reveal that information in the GPT's partition type with 7FFEC5C9-2D00-49B7-8941-3EA10A5586B7 identifier. linux doesn't care what the partition type is labeled as, functionally, except to determine auto-raid, unused partitions, and LVM partitions. OP said they're using plain dm-crypt, however, which *doesn't have* LUKS headers. no matter if it's whole-disk or partition. the only way you can get around that is with a luksHeaderBackup to a separate source and then a luksHeaderRestore when you want to use it. but don't take my word for it. https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-se... section 5.2. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
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 labelled partitions with LUKS headers).
also, the LUKS header is still there whether it's on the partition or the whole disk. you're in no way obligated to reveal that information in the GPT's partition type with 7FFEC5C9-2D00-49B7-8941-3EA10A5586B7 identifier. linux doesn't care what the partition type is labeled as, functionally, except to determine auto-raid, unused partitions, and LVM partitions.
OP said they're using plain dm-crypt, however, which *doesn't have* LUKS headers. no matter if it's whole-disk or partition.
the only way you can get around that is with a luksHeaderBackup to a separate source and then a luksHeaderRestore when you want to use it.
but don't take my word for it.
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-se...
section 5.2.
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, only look like random data across the entire drive. You could then put LVM on the LUKS container for "partitioning." I use a setup like that, though I'm not sure how bootable that setup could be; especially on UEFI systems which require an unencrypted system partition.
On 1/13/19 10:38 PM, yaro@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, only look like random data across the entire drive. You could then put LVM on the LUKS container for "partitioning."
hey, cool! cheers, i wonder when they added that!
I use a setup like that, though I'm not sure how bootable that setup could be; especially on UEFI systems which require an unencrypted system partition.
once the bootloader loads your initrd, the initrd would be able to re-assemble it provided the data source for the header was available. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
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.
I just prefer a swap partition to a swap file.
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, 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 you mean that it's not really FDE if attackers can read the partition table layout, in which case LVM is not valid as FDE and you'd better buy yourself some proprietary hardware-encrypted solution.
No, it is not Full Disk Encryption if the disk is not fully encrypted. Also, I think you misunderstood something about that example of FDE with LVM, as in that case the LVM header is, in fact, encrypted (along with the rest of the disk), and a hypothetical attacker can not read it. What do you mean by "proprietary hardware-encrypted solution"?
None of this needs kpartx.> Thank you for input, indeed all your suggestions would work, but I am going for the optimal solution here, and kpartx (or an equivalent devmapper program) seems to be a requirement for that.
The optimal solution according to what metric? If you really want kpartx, nothing stops you from going right ... ... ...
Yes, but I am sure you can see it would be preferable to have the kpartx executable on the iso, as less work is better. Regards, Neven Sajko
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-crypt decrypted device is). Thus kpartx needs to be on the Archlinux installation ISO to enable that kind of setup.
It would of course first be necessary for an Archlinux Developer or Trusted User to adopt kpartx, so I hope there is somebody willing to do this ...? Note that kpartx is a common utility and in its own package across a lot of distributions; like Debian, Ubuntu, Fedora, OpenSUSE, ...
It's your lucky day! I just pushed it to [community] as multipath-tools, please test it.
Appended is an example PKGBUILD which only installs the kpartx executable and manual page:
That's terrible, why bother splitting it up from the rest of the project? -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
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 for partitions on device mapper maps, which is what a dm-crypt decrypted device is). Thus kpartx needs to be on the Archlinux installation ISO to enable that kind of setup.
It would of course first be necessary for an Archlinux Developer or Trusted User to adopt kpartx, so I hope there is somebody willing to do this ...? Note that kpartx is a common utility and in its own package across a lot of distributions; like Debian, Ubuntu, Fedora, OpenSUSE, ...
I just pushed it to [community] as multipath-tools, please test it.
Also, we'd appreaciate it if you'd add details about this setup to the wiki. -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
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 Sajko
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 making a feature request for the archiso package ...
Documenting its use on the wiki, for starters. :p Then submit a feature request with rationale for inclusion at https://bugs.archlinux.org/index.php?project=6 -- Eli Schwartz Bug Wrangler and Trusted User
On Sun, 13 Jan 2019 08:56:55 -0800 (PST) Neven Sajko via arch-general <arch-general@archlinux.org> 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-crypt decrypted device is). Thus kpartx needs to be on the Archlinux installation ISO to enable that kind of setup.
Hi, I'm not sure this is applicable to your setup (I'm tired right now but skimmed the hole thread), but I'm using a root GPT inside a LUKS container. To make the kernel aware of the partitions at boot, I run partprobe (part of parted) on the opened LUKS mapping device: $ cat /etc/initcpio/install/partprobe #!/bin/bash build() { add_binary partprobe add_runscript } help() { cat <<HELPEOF This custom hook scans a mapped LUKS container for GPT partitions and informs the OS kernel about them. HELPEOF } $ cat /etc/initcpio/hooks/partprobe #!/usr/bin/ash run_hook() { partprobe /dev/mapper/matrix_vol } Works fine for me. Sorry if I'm missing the point here. Kind Regards, Merlin
It would of course first be necessary for an Archlinux Developer or Trusted User to adopt kpartx, so I hope there is somebody willing to do this ...? Note that kpartx is a common utility and in its own package across a lot of distributions; like Debian, Ubuntu, Fedora, OpenSUSE, ...
Note: it may be possible to use losetup instead of kpartx so as to make a loop device instead of a device map, but that would come with an overhead? Another alternative setup, perhaps more widely used, is having encrypted LVM. While this does not require kpartx, LVM may be undesireable because of its complexity and requiring multiple userspace daemons beside Udev.
Appended is an example PKGBUILD which only installs the kpartx executable and manual page:
pkgname=(kpartx) pkgver=0.7.9 pkgrel=1 pkgdesc='Create device mapper maps for partitions in devices or files' arch=(x86_64) url='http://christophe.varoqui.free.fr' license=(LGPL GPL GPL2) depends=(device-mapper) makedepends=(gzip) source=('mpt.tar.gz::https://git.opensvc.com/?p=multipath-tools/.git;a=snapshot;h=5c67a8b5944dd13...') md5sums=() sha512sums=('d4abc9580b6a3e457c99bee96d5aaab29a984ae77f91cbbe52e1b4af16809319a9100c45ce5600242fa52819dd44a9cb77e13305bc4f9651c532906243f2d544')
build() { cd multipath-tools-5c67a8b/kpartx gcc -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DLIBDM_API_COOKIE -l devmapper -o kpartx $CPPFLAGS $CFLAGS $LDFLAGS *.c gzip kpartx.8 }
package() { cd multipath-tools-5c67a8b/kpartx install -d "$pkgdir/usr/bin" install -m 755 kpartx "$pkgdir/usr/bin" install -d "$pkgdir/usr/share/man/man8" install -m 644 kpartx.8.gz "$pkgdir/usr/share/man/man8" }
-- Merlin Büge
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 <arch-general@archlinux.org> 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-crypt decrypted device is). Thus kpartx needs to be on the Archlinux installation ISO to enable that kind of setup. Hi,
I'm not sure this is applicable to your setup (I'm tired right now but skimmed the hole thread), but I'm using a root GPT inside a LUKS container. To make the kernel aware of the partitions at boot, I run partprobe (part of parted) on the opened LUKS mapping device:
$ cat /etc/initcpio/install/partprobe #!/bin/bash
build() { add_binary partprobe add_runscript }
help() { cat <<HELPEOF This custom hook scans a mapped LUKS container for GPT partitions and informs the OS kernel about them. HELPEOF }
$ cat /etc/initcpio/hooks/partprobe #!/usr/bin/ash
run_hook() { partprobe /dev/mapper/matrix_vol }
Works fine for me. Sorry if I'm missing the point here.
Kind Regards, Merlin
This is interesting, partprobe seems to be an even lighter alternative. Once again, the wiki is eager for more scenarios. ;) Regards, Bruno
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 upstreamed): https://git.devuan.org/CenturionDan/util-linux/commit/c64061c9b306f2db49ba97... * Some relevant Archlinux BBS threads, one commenter there even recommends kpartx over partprobe for some reason: https://bbs.archlinux.org/viewtopic.php?id=189537 https://bbs.archlinux.org/viewtopic.php?id=190672
participants (8)
-
brent s.
-
Bruno Pagani
-
Eli Schwartz
-
Merlin Büge
-
Neven Sajko
-
nsajko＠gmail.com
-
Robin Broda
-
yaro＠marupa.net