Re: [gentoo-dev] Re: rfc: Does OpenRC really need mount-ro

[Rich Freeman]

On Wed, Feb 17, 2016 at 10:11 PM, Richard Yao <ryao@g.o> wrote:
>
> dracut does not assist those who do not want generic kernel
> configurations. Unfortunately, the handbook does not do a good job in
> saying that the initramfs generation and generic kernel configurations
> are optional.
>

No argument that this section of the handbook couldn't be improved.
Generic kernel configs are actually not a bad starting point, though
the reality is that you don't really need a fancy tool to have them.
Just stick some config files on a webpage and tell users to download
them to .config and run make oldconfig.

Heck, you can just zcat /proc/config.gz from the install CD most
likely, though you'll want to edit out the initramfs filename in the
config if you do this or it won't build.

Dracut works fine with just about any kernel configuration.  It
doesn't really have anything to do with configuring the kernel.  You
run it after you've built and installed your kernel.  I didn't want to
split this reply up too much but I'm not sure what you meant in your
other email about it not configuring the bootloader - with grub2 the
bootloader generally configures itself.

>
> There is no default and system boot without an initramfs not only works,
> but is advisable for faster boot unless something fancy is being done
> that needs it.
>

Booting without an initramfs is supported on Gentoo as long as you
don't have /usr on a separate partition.  If you do have /usr on a
separate partition this is considered an unsupported configuration
(unless you're using some other mechanism to get /usr mounted early in
boot).

However, even if it is optional I'd still recommend it.  I'll grant
that it will add a few seconds to the boot process in many cases, but
it is far more robust than booting without one.  In general the kernel
developers have been moving more towards depending more on userspace
for initialization where in the past the kernel did more to autodetect
and configure userspace.  I think there is recognition that putting
this functionality in userspace gives everybody more flexibility in
initializing the system.

One big benefit of using an initramfs is more robust root detection.
They typically support labels and uuids for identifying a root
filesystem, while the kernel itself only supports device names.
Before I was using an initramfs I can't tell you how many times I'd
add a hard drive and have the kernel detect them in a different order,
causing my boot to break.  With just one drive this is of course a
lower risk.

Of course once you start making your environment more complex (RAID,
LUKS, LVM, zfs/btrfs with multiple disks, network filesystems, etc) an
initramfs can easily become required.  I tend to just use them
routinely - it is trivial to do and they rarely cause problems.  I'll
admit that on a VM with one partition they're probably overkill.

I guess one area where they add a bit of complexity is if you're using
UEFI without some kind of intermediate bootloader, since a kernel can
be directly booted with EFI and using an initramfs in this
configuration is a bit of a pain in the rear.  It certainly can be
done but it becomes a bit of a chicken/egg putting it all together
(you want the modules in the initramfs, but the initramfs has to be
built before the final kernel itself).

> Claiming to pick a default between genkernel and dracut when both are
> optional makes no sense, especially since dracut's capabilities
> (initramfs generation) are a subset of genkernel's (initramfs generation
> and kernel builds). dracut could replace genkernel's initramfs
> generation capabilities, but it simply cannot replace genkernel for
> building a generic kernel. It was never intended to do that.

So, again the page could probably be cleaned up in how it presents all
of this.  I'll agree that both should stay optional, but I'd suggest
listing dracut first for initramfs generation.  That is the only sense
that I'd make it a "default."

> By the way, pver the course of time, there have been things genkernel
> did better and things dracut did better.

That doesn't surprise me - dracut is newew, and as something new I'm
sure there was a point in time where it didn't do everything more
established solutions already did.

> It is unlikely one will ever be superior to the other.

This is pretty speculative, and any opinion I offer is only going to
be more speculation.  However, I'm not aware of anything a genkernel
initramfs does that dracut doesn't already handle.  It has the
advantage of being a more generic tool, and thus likely to have a
broader development community.

I guess I'm a fan of cross-distro solutions in general, but it would
be fair to say that the fact that something is broadly used doesn't
automatically make it better.  The reality is that Gentoo's approach
to package management is completely different from how almost
everybody does things but we wouldn't be here if we didn't like it.

> However, some feedback on what genkernel does
> poorly versus dracut and could therefore improve would be helpful.

Honestly, I've never really used genkernel for initramfs generation,
and haven't used it to build kernels in ages.  I started using an
initramfs when dracut was already usable.  This isn't really intended
as a knock on genkernel.  I wasn't actually aware it was still under
active development.  Certainly if I do hear of specific things it
isn't doing well I'll file a bug and encourage others to do the same.

-- 
Rich