Just a few clarifications below. One thing this discussion is missing is any mention of BIOS / EFI. Most of the discussion below seems most relevant to a legacy BIOS installation. Many specialized Gentoo install docs, like mdadm+lvm, don't really make mention of EFI, or other more recent developments. Now that all the docs are on the wiki I'd strongly encourage anybody with an interest to improve them. Many seasoned Gentoo users barely reference the documentation these days and I think that is part of why they've become a bit dated.
A few of the topics below are somewhat controversial, particularly on this list. I tried to stick to the facts and indicate where there is a difference of opinion. I'd prefer not to rehash all the various debates... On Sun, May 17, 2015 at 9:24 AM, Peter Humphrey <[email protected]> wrote: > On Sunday 17 May 2015 12:48:58 Nuno Magalhães wrote: > >> (Later i want to get rid of systemd-udev and use eudev instead.) > > I use openrc, not systemd. It still works well and has less complication - and > less typing! Most people using openrc are also using systemd-udev (and there is a good chance you do too). The latter was previously named udev and long predates what most people call systemd. Eudev is a fork of udev, which comes from after it came under the systemd umbrella, but before the name change and a number of changes that were controversial. I believe they try to incorporate many of the patches from systemd-udev but some default behaviors are different. In any case, I just wanted to clarify that systemd-udev is not the "systemd" you're probably thinking of. In particular, it doesn't replace openrc or sysvinit. Systemd-udev largely is concerned with populating /dev, and running initialization of hardware when it is detected, based on a configurable set of rules. > >> I intend to use XFS for /. Incidentally, if i later decide to "fork >> out" /usr (or some other subdirectory) into it's own LV, is it "just" >> a mater of copying its contents and updating /etc/fstab? Or should i >> just do it now and expand the LVs if later required (especially if i >> want to use different filesystems)? > > I can't help you with XFS. I know that ext4 in an LV in a VG in a PV on RAID1 > works reliably, even though it does look complex when I write it like that. As far as LVM and xfs themselves go, you can do what you propose. However, Gentoo QA policy is that it is expected that /usr is mounted early in boot. Various tools can break if it is not. Typically this is the responsibility of an initramfs, however you can also use scripts that run early during initialization from / which mount it. If you just stick /usr in fstab and rely on openrc to mount it for you normally, you may or may not have problems. It has been a long time since I actually used such a system in this manner with Gentoo, but the last I saw discussion on it most who used this configuration found it usually worked fine, unless you were using something like a bluetooth keyboard or other key system component that required a lot of userspace tooling to make work. However, as a matter of policy you're on your own if you choose not to mount /usr early during boot in some way. The reason it is not supported is that with the rise of things like bluetooth the list of dependencies possibly required during early boot has grown to the point where we'd end up not even having a /usr before long. My sense is that for the most part most maintainers tend to respect the traditional definition of / and /usr on Gentoo, and thus you can often get away with doing things the traditional way. However, the policy does allow us to end debates over things like udev rules invoking some userspace tool in /usr and such. Some packages more strongly depend on /usr being installed in early boot, and there have been suggestions (but nothing concrete) that Gentoo consider supporting the /usr-move that other distros have embraced (and that would basically get rid of /lib, /bin, and so on). > > Again, legacy grub here. But if you're using an initramfs, from what I've seen > you don't need to specify metadata 0.90. I used to use grub legacy and kernel RAID auto-assembly. As a result I was using metadata 0.90. I found this configuration problematic on rare occasions. There is a reason that mdadm changed the metadata, and why most distros don't do it this way. (more below) > > Damn. I've just checked and something has renamed my /dev/md7 to > /dev/md127. Again. It's just too bad. I shall have to stop it when I get a > quiet moment and reassemble it into /dev/md7. Actually, I know what caused > it but I didn't notice at the time. And this was one of the configuration problems I ran into on rare occasion. Often booting from a rescue CD or such caused something like this to happen. One of the advantages of using an initramfs is that they can be a lot smarter about finding your partitions. You can identify them by UUID or label, and not care as much if mdadm or the kernel renames your device nodes. I'd seriously take a look at dracut, though I don't know if it works with eudev. It certainly should support openrc, and I know that it did back when I was running openrc. It can also mount /usr for you, and in fact it should automatically do so. It also respects your fstab - it uses its internal logic and the kernel boot line to initially find filesystems, but then it reads your /etc/fstab and remounts everything as you define it there just in case something has changed since the last time you built the initramfs/etc. You can define your own modules for it which makes it reasonably easy to get it to do anything at all during early boot, and it doesn't require anything to be built static (it finds required shared objects anywhere on the filesystem and includes them in the initramfs). It can also give you a rescue shell if something goes wrong, and depending on your settings you can make that rescue shell reasonably well-featured (using either dash or bash as you prefer inside, and I imagine you could tell it to install the other on the side). A while ago I needed to run some btrfs tools that aren't in dracut by default and it was trivial to tell dracut to include them, and I forced a shell on next boot which gave me the latest tools and kernel without having to build a rescue CD with them, and a bash shell to run them from. It certainly isn't necessary to use an initramfs to use Gentoo, and I used to be among the more minimalist crowd that avoided them. However, once I took the time to examine dracut it went from being a blob that looked unnecessary to a tool that is often useful. -- Rich
