[lfs-dev] kernel options after removing systemd
bruce.dubbs at gmail.com
Thu May 15 12:31:35 PDT 2014
Ken Moffat wrote:
> On Thu, May 15, 2014 at 11:08:41AM -0500, Bruce Dubbs wrote:
>> Ken Moffat wrote:
>>> I'm just catching up on the details of what has changed. In
>>> section 8.3 the rationale entries for all mentioned options are now
>>> present - so far, so good.
>>> Unfortunately, automounter version 4 support is still shown as an
>>> item to be selected. It was certainly recommended for systemd, but
>>> the last part of the rationale "this is needed to work around a bug
>>> with network filesystems which are to be mounted on boot" ONLY
>>> applied to systemd.
>>> IMHO we should not include the kernel automounter in LFS. BLFS
>>> already has that setting on its autofs page.
>> I left that in as a shortcut for those who need the kernel automounter so a
>> kernel rebuild is not needed. Does it hurt something? Do we just specify
>> the minimum?
> We used to!
>> I know that there are lots of other places in BLFS that also have kernel
>> options, but this seemed relatively innocuous to me.
> I call it bloat. Never used it until I was building for systemd.
> At http://wiki.linuxfromscratch.org/lfs we say :
> | Building LFS produces a very compact Linux system
> | When you install a regular distribution, you often end up
> |installing a lot of programs that you would probably never use.
> |They're just sitting there taking up (precious) disk space. It's not
> |hard to get an LFS system installed under 100 MB. Does that still
> |sound like a lot? A few of us have been working on creating a very
> |small embedded LFS system. We installed a system that was just
> |enough to run the Apache web server; total disk space usage was
> |approximately 8 MB. With further stripping, that can be brought down
> |to 5 MB or less. Try that with a regular distribution.
> You seem to be moving further and further away from that.
Well the best definition of bloat I can find is 'unwarranted or
excessive growth or enlargement'. What's been done lately is not
excessive in my mind. Some may call it unwarranted, but I feel there
are valid reasons.
I do agree that we should guard against a lot of extras. For instance,
I don't think glib is appropriate. You could make a case that openssl,
openssh, sudo, which, wget, etc should be in LFS, but that really
becomes a preference. I left in some systemd requirements to harmonize
with a separate systemd book *and* because they were used in a lot of
> In any case, the text about the workaround only applies to systemd
> (or even "some systemd installations" - one of my builds needs it,
> another machine with an almost identical build but different
> hardware appeared as if it didn't [ no obvious error messages on
> that one ]. We don't mention systemd in the book any more, so we
> are implying a fault in something.
>> I suppose instead a link to
>> might be appropriate.
OK, I'll do that.
More information about the lfs-dev