<oriansj>and I probably should add steps for downloading and verifying the gentoo install iso as well <oriansj>that way there is a standard test procedure in qemu as well <oriansj>probably should add a gpg verification for the stage3 download as well <oriansj>the one bit that needs to be absolute correct is the grub configuration (and the initramfs having cryptsetup) because otherwise I'll have to restart from step 1 and that'll take a chunk of time (just to do another test) <oriansj>as I can just copy the disc to a new file and use copies of it for the rest of the testing. <oriansj>[Although if I was more proper, I would be doing separate /boot / partitions with / as luks2 and /boot as luks1] <oriansj>and testing out the keyfile bit is probably best left until after a reboot so that we will no longer using the install media <oriansj>oh my, the gentoo install image doesn't include any gpg keys <oriansj>sam_: does no one validate stage3 downloads? <oriansj>or is there a gpg public key file in the default install I need to import? <oriansj>wait there is something in /mnt/livecd/usr/share/gnupg/distsigkey.gpg <sam_>oh right, on the live cd <sam_>might be something in /usr/share/openpgp-keys too. if there isn't I can see about fixing that <oriansj>none of the keys in /mnt/livecd/usr/share/gnupg/distsigkey.gpg seem to be valid for the .asc for stage3 <oriansj>just gpg --import /usr/share/openpgp-keys/gentoo-release.asc before the gpg --verify stage3-*.asc <oriansj>so the default gentoo install handbook is missing a step as it just says gpg --verify stage3-amd64-<release>-<init>.tar.?(bz2|xz){.DIGESTS.asc,} <oriansj>and the key simply isn't in the default keyring for root <oriansj>why does everyone (except guix [thank you]) include nano by default? vi/nvi and mg/zile are smaller <oriansj>AwesomeAdam54321: well that is an interesting thought I haven't considered <oriansj>(and if there is some functionality not listed but probably a good idea) <sam_>I feel like I've seen a page for that before <oriansj>(please forgive me for being very green with gentoo) <oriansj>I am guessing eselect profile would probably cover the error about sys-kernel/linux-firmware being masked but I feel I am missing something <sam_>you can drop gentoo-sources & genkernel from line 126; linux-firmware is interesting because it's to do with licensing <sam_>yeah, I think the guides on the wiki about FDE are spotty <sam_>the steps are all there somewhere, but it's not super coherent <sam_>i'm happy to make changes to docs etc from your findings but i'll be honest, for that particular thing, it might be better if you did it (or told me exactly what to change at least) <sam_>just because I haven't used FDE-via-cryptsetup/LUKS in years <oriansj>good point and I'm just learning gentoo <sam_>that's kind of why this is great <sam_>you can tell me the things which are papercuts <stikonas>I have FDE via cryptsetup/LUKS working on gentoo with dracut... <stikonas>with hook to avoid typing passphrase twice (install_items="/boot/crypto_keyfile.bin") <sam_>while I remember, let me do the pgp keyring thing <sam_>sorry, I forgot to say thanks in the edit reason <oriansj>I am guessing /etc/portage/package.use used to be a file and now it is a folder for holding varies files with the previous contents. And if so is there a good naming convention for them? <sam_>it can be a folder or a file (same for almost all /etc/portage/* things) <oriansj>sam_: well right now the default appears to be a folder <sam_>I normally do something like /etc/portage/package.use/misc if I don't know what to call the contents <sam_>the nice thing about folders is it makes it easier to give someone a script to add a snippet <sam_>(as in, if you had two files package.use/{a,b}, b is applied second. but in the files themselves, later takes precedence) <sam_>ah, so line 1 is wrong, because it's got a package, but no USE flag you want to apply to it, and line 4 has the opposite issue because it lists flags, but no packages to apply it to. <sam_>for the latter, you can do */* static kernel if you wanted <sam_>or put them in make.conf's USE instead <sam_>and 3 has sys-kernel/dracut there as a USE flag but it isn't one <sam_>yes, sorry! but you can do glob-ish if you want to apply to many packages instead (like sys-kernel/*, or */*) <sam_>you can also negate with -flag <oriansj>so those just define what is needed by emerge when it builds the programs <oriansj>although I probably should combine related packages that need configuration for the use of a package that I actually care about <oriansj>hmmm need to think more of good organization <oriansj>possibly might be a good idea just to download the package.use/$files to minimize the amount of typing the user would need to do <oriansj>so I am going to call it a night and hopefully figure out the correct answer tomorrow <aggi>i consider both linux kernel dm-crypt and userspace cryptsetup components problematic <aggi>hence, i reverted to ancient linux-2.4 style loopdev crypto transform for this <aggi>it's much simpler, both the kernel-internal implementation for this, and the util-linux userspace support for losetup <aggi>sadly, due to a regression in loopdev (without any transform applied too), loopdev is slower than the device-mapper <aggi>don't know, why util-linux losetup removed support <aggi>anyway, good news: the userspace of ~600 builds compiled with tcc-toolchain for ARCH=armv6... it booted successfully! <oriansj>aggi: good to hear about your progress <oriansj>but yeah, broken documentation is worrying on something as senstive as encrypting/decrypting of one's data. Where mistakes are not ever forgiven. <aggi>digged into the sources of both, kernel dm-crypt and cryptsetup userspace utilities... i wouldn't want to rely on this <aggi>the missing portability of luks/2 towards any other OS than linux is one hint, of what's wrong with it ***Noisytoot_ is now known as Noisytoot
<oriansj>aggi: completely fair. I treat luks the same way I treat every other program. It is a tool that can be used in certain situations and not in others but be sure to document the issues which they limit workflows and any potential work arounds. <aggi>well, again booted an aarch32-test.img compiled with tcc-toolchain <aggi>seems most of the ~600builds (except musl-libc) in userspace are working <aggi>however, i do notice, binaries compiled with tcc are notably slower, such as ssh key-exchange requires some seconds now, instead of a short moment before <aggi>haven't got conclusive benchmark data yet, not important yet either <aggi>and i'll have to rethink the tcc-toolchain package set anyway <aggi>and some minor bug in ncurses linking remaing (missing symbol), which i'll repair <doras>So... I'm terrible with autotools, and my re-generation of aclocal.m4 for binutils ends up with not enough `m4_include(...)` lines. Any clue what I may be doing wrong? <aggi>then next... mes-libc and toybox-userspace linked against it <doras>For example, a bunch of "m4_include([../bfd/acinclude.m4])" and "m4_include([../config/po.m4])" lines are missing. <oriansj>doras: it is OK, autotools is a bad solution to a worse problem that generally doesn't exist for most developers anymore <doras>(the same goes for other directories in the source tree) <doras>Which I think causes a failure when `libtoolize` is then executed. <aggi>doras: no clue if this is helpful, i always call `autoreconf -if` due to various side-effects <oriansj>The most ironic bit is if C library paths and the functionality provided was standardized, then there would have been no need for autotools <doras>aggi: I'm trying this now... I just went according to the example in the existing version of binutils in live-bootstrap... <aggi>fyi, in 90minutes (16:00UTC) Artemis 1 rocket launch is broadcasted on TV <oriansj>I'm more excited about getting a working minimal gentoo install at this point <sam_>oriansj: I've not long got up but I'll read over backlog and be around to help in a bit <sam_>just got very wet walking the dog :) <oriansj>sam_: I didn't see any written but are there minimal system reuirements? <oriansj>as I am starting to think 1GB of RAM might not be enough to build grub <oriansj>and swapon doesn't seem to be working with swapfiles <oriansj>as it looks like boost-1.79.0 with -j2 needs more than 1GB to build otherwise it does seem to hit Oom manager and break the build for grub;2 <oriansj>blockhead: technically for building the boost library needed by the bootloader <sam_>for C++ stuff you often need ~2GB/job <sam_>you can set lower jobs per package if you wish <oriansj>(and -j2 technically doubles the memory requirements) <oriansj>sam_: how would you set just 1 job per c++ but 2 jobs per c? <sam_>there isn't an out of the box way to do it purely for C++ vs C packages, just overriding MAKEOPTS per named packages, however, we have /etc/portage/bashrc which could, for example, grep the workdir for *.[cc|cxx|cpp] and adjust MAKEOPTS accordingly <sam_>I can try hack something up for bashrc <oriansj>and I am guessing 8GB per job for Rust and Haskell programs <sam_>we could make it halve makeopts with some effort if you wanted <stikonas[m]>oriansj: by the way, I have gentoo overlay for bootstrapping some packages if you want to do that <stikonas[m]>Also accessible as gentoo-bootstrap via layman or eselect-repo <oriansj>stikonas: nice; I don't know how to do gentoo overlays yet but it looks like something I should document <stikonas>(and more testing fot this bootstrap stuff is appreciated since it's not something I run often) <stikonas>since those bootstrap chains tend to be only used once and then you self-host <stikonas>longer term it would also be nice if we could eliminate need for stage3 <stikonas>and get Gentoo directly from live-bootstrap <oriansj>sam_: trying it out and it looks like it works well <oriansj>stikonas: indeed, the more bootstrappable distros the better. ^_^ <oriansj>and I do sanity test my install procedures every couple of months to see if anything broke or needs a tweak