[lfs-dev] Thoughts about LFS and systemd

Bruce Dubbs bruce.dubbs at gmail.com
Fri Mar 28 10:09:42 PDT 2014


Thomas Trepl wrote:
> Am Dienstag, 25. März 2014, 11:22:38 schrieb Bruce Dubbs:
>> I've been looking at systemd and had a thought that perhaps both could
>> be put into a single LFS build.  Looking at the installed package
>> contents in the books, I see the following name collisions:
>>
>> systemd  sysvinit eudev
>>                     udevd
>> udevadm           udevadm
>> halt     halt
>> init     init
>> poweroff poweroff
>> reboot   reboot
>> runlevel runlevel
>> shutdown shutdown
>> telinit  telinit
>>
>> I don't know if udevd is missing from the systemd page or is really not
>> installed when doing a systemd build, but I suspect it has just been
>> omitted from the page.
>>
>> In any case, this cursory look indicates to me that both could be
>> installed with custom names and a script written to swap the names and
>> reboot to the desired system.  I also suspect a sysV initialization
>> could use the systemd version of udev and eudev would not be necessary.
>>
>> I have not looked at boot scripts or possibly different build options in
>> other programs, but wanted to throw out the idea for comments.
>>
>>     -- Bruce
>
> Hi,
> I personally would dislike that approach to merge this two systems together.
> Having that all installed, it may confuse more than it helps. While I still
> deeply dislike systemd (I cannot argue technically, its more emotional), it is
> quite right to have the systemd-branch as systemd really may become part of
> the future and we shouldn't close the eyes for that.
> But sysv is still valid, clear in its structures (and it does not take ages to
> boot). In my eyes ideal for the educational background LFS has. A boot issue
> can (mostly) easily tracked down to the bootscript which that can be tweaked
> in whatever way for whatever reason. So keeping the "original" alive is also
> valid.
> I'd vote for not merging the two different init systems. I think systemd is
> confusing enough so I'd think that mixing it with the "classic" would add
> unnessessary complexity. The charme of a LFS system is to be crystal clear.
> That would be somehow lost.

If we end up with a combined system, there definitely will be a page 
describing the advantages and disadvantages of both systems and allow 
the user to choose.  The default will be sysV.

The combined version gives the advantage of using the same udev in both 
systems.  One needed package for systemd is dbus.  I really don't like 
adding that.  If you are building a server (e.g. web or database 
server), there is no need for X.  Without X applications, I know of no 
need for dbus.  Actually, for an LFS system, I see no need for systemd 
in any case, but I do feel the need to add it for educational reasons. 
It will also be interesting to compare it on the same system.

> Maybe a if-else in the book would not harm too much if it is only one or two.
> I think something like "if you want to install systemd as boot system goto
> chap X else continue" is understandable for everyone when a section is added
> which describes the differences between sysv and systemd. Thats required to
> give the user background to make her decision. So having both in a clear way
> in one book may work, but I'd never install both on disk.
>
> Btw,  +1  to add those packages like attr, acl and such to the core. The only
> one still missing is cpio. With this one, everything would be available to
> setup a Linux system using a initramfs for booting.

I'm not so sure about cpio.  The only reason to add that (IMO) is to 
support the initrd, and we don't describe that in LFS at all.  In fact, 
one of the advantages of LFS is to show that an initrd is not necessary 
most of the time.

   -- Bruce





More information about the lfs-dev mailing list