Hey guys, if you've noticed by now, systemd is fully now part of the LFS-dev book, and could be part of future builds of the system.

Bruce Dubbs has published a hint of mine to use eudev as a lightweight alternative to systemd which was the original official eudev build and install method. It includes instructions on compiling, plus the gudev portion from BLFS.

If you'd like to use this hint, you can read it here:

http://www.linuxfromscratch.org/hint...v-alt-hint.txt

Thanks for doing this. I will be using it. I also think I will maintain the initscripts myself now. Besides, I always have to edit the ones installed from the book for various reasons.

I don't really approve of the way the devs suddenly decided to handle the SysV-Systemd dichotomy. But I can understand the motivation to maintain one book instead of two. And even though the SysV configuration is the default (for now), its just sort of natural for me to extrapolate the expansion of Systemd to it being not only the default someday but the only way.

I plan to sort of go my own way for a while longer; until Systemd is required to install so much other stuff that I have to use it.

I've been talking to Bruce again about this. One hope I have is seeing if two books might be more relevant. I might even see if he'd be willing to post here and talk with users outside the mailing list. Time will tell though, and this is only the dev book luckily so the future of eudev might still have a chance.

There's sort of an old saying (somewhere) that developers develop for themselves (and not for users). And if users like the result, then fine. If not, they can lump it or fix it. I think that probably is true at least to a large extent. I read the B/LFS mailing list posts every day, and I rarely (never?) read any comments about ordinary users (and what they might want). That's why I think Systemd has made so much headway in LFS lately. I mean, after all, why would someone leave a mainstream distro for LFS and then want to build Systemd? Systemd is the exact and only reason why I left Fedora. I was perfectly happy with Fedora until Systemd took it over. Anyway, hearing from LFS developers out here in the real world would be an interesting thing.

From what I've gathered from talking with Bruce, he's only put it in for educational purposes, but still is deciding on what to do about LFS-7.6 and if systemd will formally be included. He's even said he doesn't use it on his main system anyway, so there is hope.

Oh damn I didn't know that, I am compiling LFS SVN right now using jhalfs
Can I get rid off it later?

No, once systemd is in, you have to scrub the system and start all over from scratch if you want to use eudev. Bruce left a hint on the system page specifically pointing to my hint.

systemd lays down a hard dependency once it's in the system to which everything has to work with it. The talk coming from LFS-Dev mailing list doesn't sound too enthusiastic towards systemd as it literally is a pain to work with and tune correctly as it doesn't rely on standard UNIX scripting techniques.

I suggest manually compiling LFS-Dev until further notice.

Also please read the hint carefully as it will inform you that several packages can be excluded from LFS safely.

Oh damn, LFS will be left to some other time in the near future. Maybe on vacations.

I've already built LFS-Dev with eudev and it works just fine by the way.

It shouldn't take you long to build anyway. Give a good day or two devoted to it and you'll get it all done. BTW... my hint includes the URL and md5 checksum, so if needed you can edit the md5sums file and wget list to include eudev.

Well, thanks for the tips. I might try it in the weekend,

EDIT: I think another option would be build LFS 7.5, it doesn't ship systemd if I am not mistaken.

You can build LFS-Dev just fine, but when you get the Chapter 6, skip ahead to 6.67 systemd-212 and read the Hint and see what can be excluded from the build. The book is still geared to operate off SysVInit by default. My hint just eliminates systemd and a lot of extras dependencies it requires.

You can also skip the last part of 6.64.1 SysVInit regarding the moves, and Chapter 7.1 regarding the system selection process, and any extra systemd specific configurations.

You can also search for ifupdown@.service and remove it if necessary using whereis ifupdown@.service and then cd'ing to that directory and running rm -rf ifupdown@.service

The process of eliminating systemd saves a lot of extra time and disk space that is completely unnecessary for a standard LFS build.

If you need a service manager...

Take your pick of:

Runit http://smarden.org/runit/index.html
s6 http://skarnet.org/software/s6/
perp http://b0llix.net/perp/site.cgi?page=about
daemontools http://cr.yp.to/daemontools.html

Runit and s6 also can serve as init replacements and s6's author has a good piece of advice about systemd usage.

I am still using jhalfs, I've ran it with " make BREAKPOINT=130-texinfo" so it will stop right before the systemd step, from there I will do things on my own.
EDIT: And by the way LFS adopting systemd was a disgusting decision imo

Technically it's not totally adopted yet. Bruce and crew still have their doubts from reading the last entries on the mailing list, so it remains to be seen if it will become the default.

A better solution in my opinion would have been to use Runit or s6 since LFS is a fairly custom OS by design and both of those init and supervision systems require hand-crafted customized scripting anyways.

I hope they don't adopt it. And Reaper, I am still a noob on this LFS world, do you use any script to build it automatically or do you do it by hand? Could you give me any tips?
Thanks

I actually just follow the book. Due to my hint, I've actually successfully built LFS-Dev without systemd by copy and pasting commands.

I do however maintain a script set to hash away at various parts of the build, but certain post-install setup commands have to be avoided and sent to a readme file I keep on hand for post-install. I only maintain one set of auto build scripts and that's for the tools-maintenance system which I keep at the ready for diagnosis purposes created by the LFS user account on the host build system. After that, I have a set of stand-alone build scripts that follow the chapters, but do not run continuously as the others do. I also maintain BLFS build scripts for post-install.

When you're learning LFS just build by hand. JHALFS is okay, but honestly, just craft your own scripts as needed, or stick to the book.