On Sun, May 17, 2015 at 10:35 AM, <cov...@ccs.covici.com> wrote: > > Rich Freeman <ri...@gentoo.org> wrote: > > > 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 <pe...@prh.myzen.co.uk> 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. > > Last time I tried to use dracut with openrc, it failed, I can't remember > exactly what happened, I think udev did hang, but its been a while since > this happened. Dracut uses systemd internally, so maybe this is part of > the problem.
Dracut only uses systemd optionally and (AFAIR) not by default. If you don't specify it, dracut will use its own scripts as init. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
