Arch user to Gentoo -- a few questions

[GentooSupplicant0111]

I'm a longtime Arch Linux user trying to move to Gentoo. I've read most
of the Handbook for my architecture, but I have a few questions about
the install.

1. I currently use DM-crypt full-disk encryption, and I'm not entirely
sure how this works in Gentoo. Arch uses mkinitcpio to create initramfs
images necessary to boot an encrypted disk, but I'm not sure how to do
so on Gentoo. Research and all past attempts have failed to allow me to
boot and/or decrypt my disk.

2. I currently use LVM to manage separate /, /var, and /home partitions
(ext4, jfs, and nilfs2, respectively).
I also use an rsync-based script I wrote to do encrypted backups. I'm
looking into using Btrfs instead for my system, but despite reading both
the Arch and Gentoo wiki entries I'm not entirely sure how my old
partition scheme would translate to Btrfs. I separated out /var for
security and FS-optimization reasons, but if I use Btrfs I'll most
likely end up merging it into / and using subvolumes to manage
security/quotas/etc on individual parts of the filesystem. Does anyone
have any information on the use of Btrfs in such a scheme, and in
relation to question 1?

3. I'm optimizing my install for size and speed, as with my original
Arch install. Does anyone have any pointers on this in relation to
questions 1 and 2, and in general?

[The Doctor]

1. No sweat, except the part where you have to write your own initramfs. (sweat may be involved, depending.)

There are numours online sources if you look for "gentoo luks" or similar. Here is what the wiki says.

Basically, all you do is add steps to preparing the disks and make sure you have the tools you need before rebooting.

2. Someone, but not me. It was still too immature when I built my desktop to seriously consider and I think it still is, but your call.

3. Encryption runs against speed. Badly. But anyway, read what the use flags do and turn off what you don't need/want. Apparently, this can be found at /usr/portage/profiles/use.desc as the website now returns a 404.

Also, get the thing to boot before you worry about speed. Booting is more important than speed. Also note tools like smart tools, ntp client, etc. are not included by default so don't expect to see them unless you install them.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

[EmaRsk]

1. I gave up the encryption part (because it doesn't plays nicely with working with audio), but I use LVM.
The easiest initramfs method I found is using https://github.com/slashbeast/better-initramfs.
I tried dracut and genkernel but I didn't like them for some reason.

[KEA0463]

Just a word to you of congradulations leaving
that anal-retentive* Arch crowd and coming to the real
distro, real men and women use Gentoo Linux!!
*footnote: The term anal retentive (also anally retentive), commonly abbreviated to "anal" is used to describe a person who pays such attention to detail that the obsession becomes an annoyance to others, potentially to the detriment of the anal-retentive person. The term derives from Freudian psychoanalysis.
_________________
你們當中有哪個做父親的，兒子要魚，反而拿蛇當做魚給他呢？

[CaptainBlood]

Still Arch wiki & friends can be quite useful when gentoo is dumb on the subject.
Thks 4 ur attention.

[mrbassie]

[GentooSupplicant0111]

So I created a btrfs filesystem on a partition, mounted it to
/mnt/gentoo (from within arch linux) and attempted to extract the stage3
tarball onto it (with subvolumes for /etc, /usr, /home, and /var plus a
mountpoint for boot). This works swimmingly until I chroot into
/mnt/gentoo, at which point it all goes to crap. Running 'ls' or pretty
much any other program returns 'command not found.' looking at the
current dir using double-tab to show the contents direct through the
shell displays a mess of binaries and folders, none of which resemble the
non-chroot view of /mnt/gentoo. From the outside, all is well and in
it's proper place, and the install should proceed smoothly. From the
inside, all is hell and disorder. I've tried just about every trick I
can think of and read (and reread) every article on BTRFS and subvolumes
and such, but no solution. It turns out the same every time, and I am
unable to progress past the stage3-unpack step. Solutions, anyone? This
is patently annoying.

I haven't tried doing the install from a live gentoo
environment, simply because I'm lazy. I'm using my current Arch distro
to install Gentoo to a USB stick so I can test run it and get everything
fine-tuned before wiping my hard drive and starting anew with Gentoo.

[bstaletic]

I'd stay away from btrfs. Since you know Arch community, I'll remind you that some competent users had hadaces related to btrfs (namely Graysky and, I think, Trilby). If you want btrfs like feaures try LVM+ZFS. ZFS on Linux is just a module, so kernel updating can be a bit tricky, you'd have to use appropriate versions of both kernel and zfs. Since you're installing gentoo, you may be interested in FreeBSD kernel, as on BSD zfs is not out of tree module.

[cwr]

Using an ext4 filesytem the first steps at least are pretty simple:

[GentooSupplicant0111]

I don't think you quite understand. I've tried the exact steps in the
handbook, and once I try to chroot into the default environment,
everything gets screwy. It's not btrfs, because I tried this on ext4
with the same results. I've also used multiple different stage3s in the
hope that it's just a bug.

As soon as I chroot into the base environment, nothing works. The ls
command fails, cd somehow still works, and I can use the shell to
directly show the contents of the current dir (the chroot's /). The
result is a mess of files and binaries, none of which seem to work
properly aside from the shell itself. The internal layout looks nothing
like the view from the outside, or even like the layout of any linux /
I've ever seen. It's not an fs issue, though it may be due to installing
from inside of Arch Linux instead of the liveCD. I'm at a total loss for
an answer to this problem, and so far it's tainted my opinion on Gentoo.
Installing Arch by the book was nowhere near as problematic, and nobody
else seems to have encountered this problem during installation. The
only difference is that my / filesystem is on a LUKS-encrypted
partition, but I can't see how that might be causing this problem.

[cwr]

It won't be the stage 3 you are using - if that has the correct checksum it will produce the correct filesystem.

It won't be installing from Arch - I've installed from Ubuntu and Gentoo systems in the past, and I can't recall when
I last installed from a CD or USB.

If the mounted Gentoo filesystem looks correct before the chroot, but screwy afterwards, I suppose it must be some
sort of failure of the chroot; might it be 32/64 bit system mixup? The chroot sequence is trivial and straightforward
(and widely used) so it must be the chroot binary itself.

Will

[bstaletic]

How are you chrooting? Are you using what handbook described, or are you using arch's arch-chroot? If you tried just one of these two you could try the other.

[GentooSupplicant0111]

You are correct, arch-chroot was the problem. The handbook method solved
it.

I now have a btrfs filesystem set up on a LUKS device, and I'm going to
create subvolumes for /etc (for ease of config backup/move), /usr (for
size limitations and optimization reasons), /var (for optimization and
security reasons), and /home (for backup and security reasons). I'm
going to mount each subvolume to a separate mountpoint under /mnt/gentoo
corresponding to the appropriate directories, mount my boot partition to
/boot, and then go forth with the install by the Handbook. Question:

How should I best optimize each subvolume for their contents, and how
should I leverage BTRFS' abilities to optimize my system in general? I'm
aiming for a system that's small and secure. Speed is nice, but since
98% of my apps are command-line, I can afford to use aggressive CPU
scaling without taking a severe hit, even with the encryption thrown in.
The SSD helps, too. I only have a single disk, if that makes any
difference. People keep telling me to use RAID to keep data secure in
the integrity sense, but that seems like it would be overkill on a
single SSD.

And yes, I know to enable discard at the filesystem and encrypted-device
level.

[bstaletic]

RAID can be a nice feature, if data integrity is crusial. You, on the other hand, have no use for it as you have only one drive. Having everything split into 3+ partitions and put in RAID5 doesn't make much sense. The point of RAID5 is that you can have one RAID member fail and data could be rebuilt. In your case you would be using partitions, not drives, as RAID members. If that drive dies at least three raid members fail. To protect from three RAID member failing at the same time you need something like RAIDZ3, though this also means you'll loose drive capacity equal to total size of three RAID members. To conclude, RAID is useless on single drive machines.

Please open a bug report on flyspray regarding arch-chroot.

[GentooSupplicant0111]

Correction: it was not the arch-chroot, it was me forgetting to source
/etc/profile after chrooting. Tested both ways, can confirm. Issue of
human negligence, not developer malpractice.

[bstaletic]

[cwr]

After running chroot I usually run:

[GentooSupplicant0111]

Well, this is a massive headache. You guys were right.

I'm currently trying to bake my own initramfs and it's not working,
mostly because (I think) of my complicated setup and mountpoints.
Genkernel could create an adequate initramfs if my subvolumes were under
/, instead of my current setup. However, if I set it up such that /etc,
/usr, /home, and /var are nested subvolumes instead of my current setup,
how would I take advantage of BTRFS' features per subvolume? From what
I've seen, it looks like you can only enable them through fstab mount
options. Someone tell me I'm wrong.

I'd like to use BTRFS, because it really would be an improvement over my
old setup with LUKS+LVM and it has some speed/management advantages over
my old filesystem scheme. But if I can't turn on the needed options per
subvolume when they are nested (as opposed to my current setup with
mounted subvolumes per each directory), then I'm going to have to throw in the
towel on this one.

[davidm]

I'm not sure if this will help but I figure I'd post just in case it does in some way.

I use a four disk raid1 btrfs array. I have an old default subvolume which used to be with another OS. When I switched to Gentoo I simply erased all the files from that and created a gentoo subvolume. So now I simply mount the gentoo subvolume (and not the default subvolume) and it works fine.

Here's my /etc/fstab, the relevant part:

[GentooSupplicant0111]

Got all of the associated stuff to mount, and it looks like it will work
correctly. I think. Once / is mounted, the bootstrap process should be
able to access /etc/fstab via it's parent subvolume (/), which should
then cause each subvolume to be mounted to itself with the new mount
options enabled. It works when done by hand, so I'm hoping the initramfs
generated by genkernel will work. However, I ran into a caveat:
cryptsetup must be installed, along with genkernel-next, both of which
depend on devel-libs/boost... which fails to install properly. The
package compiles fine, but it repeatedly complains of a series of "bad
file descriptors" when running the install phase of the ebuild and then
fails to install, citing a bit of code in the src_multilib_install_all
function in the ebuild that goes something like this: