Gentoo is about choice and in case security is chosen encrypting the rootfs may provide an important layer thereof. Working with arches for which no official boot media is available or on systems that are not able to boot such media even if it existed, one of the biggest hassles to get an encrypted rootfs up and running always has been obtaining a cryptsetup binary for the respective arch. Cross compilation often is difficult and error prone, and it would be nice not to have to rely on third party distributions otherwise. As I'm currently working on some documentation of installing Gentoo on such arches, I'd really like to see a statically linked cryptsetup binary included in offically provided stage3s (at least for those arches) - it would ease the documentation effort. Is this possible? If not, would it be possible to include a dynamically linked cryptsetup? If yes, what would be the time frame in which this could be realized? Probably affected arches: riscv, arm ,arm64 Reproducible: Always About the documentation I'm working on: I can't say what it will become, initially the intention was to document installing on arm64 while not having to duplicate everything for every board out there but now I think it could be the base for other arches as well. It is by no means finished yet, but if you'd like to take a peek see the link provided. Also, see https://wiki.gentoo.org/index.php?title=User:Zulu_Foxtrott/Parts/Installation/About&oldid=923391#Installation_options_for_Gentoo for more info about the (current) scope of the documentation.
Preliminary overview of the whole WIP documentation: https://wiki.gentoo.org/wiki/User:Zulu_Foxtrott
You can chroot in and emerge it yourself. I see no reason this should be shipped in any of our official stage3s. If you need help using catalyst to build your own custom stage3/stage4 files for your custom project, there are a few support venues that can help you out.
Do I understand you correctly that you propose going the qemu/binfmt/chroot route? This would of course be OK (although still more difficult to do for the person trying to install Gentoo for the first time as well as for me to document), I just was thinking since to me cryptsetup is quite essential, I'd give it a shot and ask for it to be included. If you don't mind I'd also like to ask, is there a specific reason why it is not included in stage3s in the first place? Since I'm also not sure that you understood what I'm trying to do, I'll try to explain once again: I'm currently in the process of attempting to document on the Gentoo wiki how to install Gentoo on arm64 (with a focus on single board computers because that is what is available to me) as there's no arm64 handbook or anything like that. If there's documentation at all, it's usually only platform/SBC/SoC specific, which often involves lots of duplicated information across different boards - that's the problem I'd like to tackle. This is (might become) the step and section about adding cryptsetup to the initramfs: https://wiki.gentoo.org/index.php?title=User:Zulu_Foxtrott/Parts/Installation/Kernel&oldid=923457#Adding_tools_.28applications.29 Some systems only support one storage medium at a time or there is no installation media whatsoever available. Such situations are probably most often encountered in the sphere of embedded devices or bleeding edge architectures. To that end the documentation I'm working on covers installing Gentoo directly to a storage device of choice (like a SD-Card, an eMMC, a USB stick, an external hard drive, etc.) from an arbitrary working Linux command-line environment (not necessarily on a system of the same architecture as the target system). This method should also provide a shortcut in case the target device supports more than one storage medium at a time but no official Gentoo installation media is available for the target arch (usually in that case one would install some third party distribution first and install Gentoo from there).
If you can execute the cryptsetup tools somewhere, you can compile them there. The point of stage3 is to provide a base system to compile the extra tools you need in order to complete the installation. Some people need btrfsprogs, some need zfs, others need cryptsetup. We do not need to bundle these in stage3.
Yeah OK that's totally what a stage3 should be, and on x86 all of this was never an issue, but still it's not totally unimaginable to me that standards that are upheld on desktop/server don't directly translate to embedded. But then in the end it boils down to what is how essential and to whom (end users/corporate/...). So maybe I'll reconsider documenting rootfs encryption directly in the installation instructions - thought it would have been nice to have as kind of a default for the end user. But the approach of using one half of an eMMC for an unencrypted Gentoo install so that the other half then can be used for an encrypted rootfs... I (probably) won't document this (explicitly) ;)
I agree that this would be useful and that building cryptsetup for a new platform when you don't always have a compile environment is difficult, but I also agree with bkohler don't think it belongs in the stage3. It needs to be in whatever boot media is used during initial install (so you can set up the dm-crypt and install the rootfs onto that). Including it in a stage4 would ALSO be good, as part of speeding up new systems. To reframe your request, I feel it would be more helpful to you if Gentoo provided usable boot media for those arches. Then making sure cryptsetup is included in the media. - Load boot media - partition&cryptsetup&mkfs to make rootfs - unpack stage3/4 onto rootfs - install packages & possibly cryptsetup into the rootfs - setup bootloader w/ cryptfs pieces etc - profit
I don't remember the last time I used official Gentoo boot media, so I have to ask: Is cryptsetup not included in current boot media, e.g. on x86? If not, I'd for sure plead in favor of including it on every arch. Of course having official boot media for all arches would be nice, but it is quite unrealistic given the plethora of different arm/arm64 platforms each of which often needs boot media specially tailored towards it. Many have neither the necessary "firmware" to initialize the hardware (infamous RAM training etc.) preinstalled nor a higher level bootloader that's capable of booting a linux kernel. Probably with risc-v and generally on embedded the situation is similar and won't change either. How about officially offering a standalone statically linked cryptsetup binary for each of those platforms in something like a "Tools" subsection in the relevant arch sections on https://www.gentoo.org/downloads/, would that be feasible? What works as a workaround BTW is extracting the binary from media offered by a third party distribution like alpine, IIRC I did this before. But of course I'd hesitate including that in the Gentoo documentation ;)
It's included on a lot of our install media: amd64/livedvd-stage1.spec: sys-fs/cryptsetup amd64/installcd-stage1.spec: sys-fs/cryptsetup amd64/hardened/admincd-stage1-selinux.spec: sys-fs/cryptsetup amd64/hardened/admincd-stage1.spec: sys-fs/cryptsetup amd64/livecd-stage1.spec: sys-fs/cryptsetup hppa/installcd-stage1.spec: sys-fs/cryptsetup alpha/installcd-stage1.spec: sys-fs/cryptsetup ia64/installcd-stage1.spec: sys-fs/cryptsetup sparc/sparc64/installcd-stage1.spec: sys-fs/cryptsetup x86/installcd-stage1.spec: sys-fs/cryptsetup x86/hardened/installcd-stage1.spec: sys-fs/cryptsetup x86/hardened/admincd-stage1.spec: sys-fs/cryptsetup
I do not understand what you are needing from us. If you have unpacked a stage3 somewhere already (such that you could execute its cryptsetup copy), then you can already chroot into that and emerge cryptsetup. Right? The reason it's already installed on our boot media is that you need to use cryptsetup to prepare your disks BEFORE you download and unpack stage3. So how does a bundled copy in stage3 help anything?
I already assumed that it is included in the boot media, but Robin Johnson's comment sounded led me to not be so sure about what I believed to remember. So thanks for the clarification! My request concerns those arches for which there is no official boot media. On those arches the installation process closest to the traditional one essentially involves "installing" Gentoo twice, first creating boot media, then the classic/real installation. This is cumbersome (not impossible) and even more so on hardware that is only able to address one storage device at a time (e.g. an embedded board that has only one SD card slot, no USB, no SATA, nothing else). Being able to obtain a compiled cryptsetup binary on those arches enables an approach to an installation with encrypted rootfs that does not require a second (the classic) installation. The boot media you'd create is the "final" Gentoo installation. It does not necessarily have to involve chrooting into the new installation. See e.g. https://wiki.gentoo.org/wiki/Libre_Computer_Renegade/Installing_Gentoo#Installing_the_Gentoo_base_system In case we are on an amd64 host and want to prepare a SD card that is going serve as the boot "disk" of an arm system: We can extract an arm stage3 onto that SD card, but we only can (chroot into and) run binaries from that new rootfs (in the new rootfs) via emulation (qemu, binfmt or something). Alternatively to chrooting we can inject a root password, prepare /etc/fstab, plug the SD card into the arm system, boot it, bring the network up, prepare portage, emerge -eav @world, etc. In case we don't want or can't run an emulator and we encrypted the root partition on the SD card, one essential thing is missing: we need a cryptsetup binary compiled for the target system before the target system is running, so that we can prepare an initramfs already on the host system. Related: bug #534376
But what I'm getting at is that if you can run the cryptsetup binary at all (via emulation, or natively, or whatever) then it's only trivially more work to compile one yourself already.
I'm not requesting it for me if that's what you think? I'm requesting it for the user who wants to run Gentoo with an encrypted rootfs for example on a raspi4, maybe even a first time user, and who therefore follows the instructions I'm preparing.
I dont see how that matters. Whoever it is that would RUN the preinstalled cryptsetup, can just compile it himself in a few minutes. Exactly like he would do for ANY OTHER tools needed for the new install.
> In case we are on an amd64 host and want to prepare a SD card that is going > serve as the boot "disk" of an arm system: > > We can extract an arm stage3 onto that SD card, but we only can (chroot into > and) run binaries from that new rootfs (in the new rootfs) via emulation > (qemu, binfmt or something). > > Alternatively to chrooting we can inject a root password, prepare > /etc/fstab, plug the SD card into the arm system, boot it, bring the network > up, prepare portage, emerge -eav @world, etc. > In case we don't want or can't run an emulator and we encrypted the root > partition on the SD card, one essential thing is missing: we need a > cryptsetup binary compiled for the target system before the target system is > running, so that we can prepare an initramfs already on the host system. In the above example, we'd run the x86_64 cryptsetup to encrypt the rootfs (then we'd unpack the stage3 to the encrypted partition), but we need an arm cryptsetup for the initramfs so that we can boot the arm system. So if we don't have an arm cryptsetup binary we have to compile it ourselves, which is not trivial: either cross compile (there's nothing else for which we need to do that, except the kernel and u-boot - both of which are trivial because no dependencies and such) or set up some kind of qemu/binfmt/chroot (there's nothing else we need that for).
Sounds like what you really want is a prebuilt initramfs, I don't see why stage3 would need be involved though.
I agree that stage3 does not need to be involved, stage3 is not where it should be, I adjusted the title accordingly. But I'm not requesting a prebuilt initramfs, that would be rather impossible to realize given the many different platform/storage device combinations out there, and I already started to document how to create an initramfs as part of the installation process. Exactly this part would be much easier if there was some (ideally an official) way of obtaining a prebuilt cryptsetup for the target arch.
(In reply to Zulu Foxtrott from comment #16) >that would be rather impossible to realize given the > many different platform/storage device combinations out there Yes and this is exactly why we should not try to bundle these in stage3 either, there is no limit to what "might" be needed by someone. Really that is why our gentoo installation works the way it does, you need to be able to compile tools of your choice during install.
(In reply to Ben Kohler from comment #17) > (In reply to Zulu Foxtrott from comment #16) > >that would be rather impossible to realize given the > > many different platform/storage device combinations out there > > Yes and this is exactly why we should not try to bundle these in stage3 > either, there is no limit to what "might" be needed by someone. Really that > is why our gentoo installation works the way it does, you need to be able to > compile tools of your choice during install. Closing as per this
