|
|
Log in / Subscribe / Register

Linux from Scratch to drop System V versions

[Posted February 6, 2026 by jzb]

The Linux From Scratch (LFS) project provides step-by-step instructions on building a customized Linux system entirely from source. Historically, the project has provided separate System V and systemd editions, which gave users a choice of init systems. Bruce Dubbs has announced the project will no longer produce the System V version:

There are two reasons for this decision. The first reason is workload. No one working on LFS is paid. We rely completely on volunteers. In LFS there are 88 packages. In BLFS there are over 1000. The volume of changes from upstream is overwhelming the editors. In this release cycle that started on the 1st of September until now, there have been 70 commits to LFS and 1155 commits to BLFS (and counting). When making package updates, many packages need to be checked for both System V and systemd. When preparing for release, all packages need to be checked for each init system.

The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd that are not in System V. This could potentially be worked around with another init system like OpenRC, but beyond the transition process it still does not address the ongoing workload problem.

[...] As a personal note, I do not like this decision. To me LFS is about learning how a system works. Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files. Yes, systemd provides a lot of capabilities, but we will be losing some things I consider important.

The next version, 13.0, is expected in March and will only focus on systemd.


to post comments

sad, yet understandable

Posted Feb 9, 2026 9:17 UTC (Mon) by CodeAsm (guest, #101413) [Link]

Im kinda sad it goes, but also using systemd in my lfs build, as so many documentation for current gen hard or software assumes systemd. And well, ive basically grown up with systemd.

Yet, having alternatives would be cool. Maybe i volunteer my laptop and time.

Isn't LFS for learning?

Posted Feb 9, 2026 10:17 UTC (Mon) by taladar (subscriber, #68407) [Link] (13 responses)

I don't really see the point of providing a sysvinit version of LFS if it is meant to teach how the actual system works.

Not only because most actual systems use systemd but also because while sysvinit might be a lot fewer source files the amount of assumptions and emergent effects that aren't explicitly stated in the source files are astronomical.

Those bash scripts might look simple at first glance but just keep in mind how many things each process inherits from the environment that calls it, that alone could probably fill more than 22 files and all has to be implicitly considered somehow (environment variables, capabilities, process groups, sessions, effective uid/gid, audit information, cgroups, namespaces,...) and likely isn't because half of those are newer mechanisms from a time when sysvinit was already no longer keeping up with the development of Linux.

Isn't LFS for learning?

Posted Feb 9, 2026 12:31 UTC (Mon) by pizza (subscriber, #46) [Link]

> Those bash scripts might look simple at first glance but just keep in mind how many things each process inherits from the environment that calls it, that alone could probably fill more than 22 files and all has to be implicitly considered somehow

Missing from those "22 files" are the the various tools/utilities that those shell scripts invoke or otherwise directly rely on to function -- notably including the actual shell itself -- but there's also ancillary things like at/cron and inetd (ie other tools that the system uses to "launch things asynchronously in the background") that should also be included.

Isn't LFS for learning?

Posted Feb 10, 2026 10:36 UTC (Tue) by epa (subscriber, #39769) [Link] (10 responses)

Slackware uses BSD style init (although it now provides compatibility for SysV style init scripts). That might be the best choice for a simple learning environment.

Isn't LFS for learning?

Posted Feb 10, 2026 11:59 UTC (Tue) by taladar (subscriber, #68407) [Link] (9 responses)

What exactly would be the point in learning how a system works that virtually nobody uses?

Isn't LFS for learning?

Posted Feb 10, 2026 13:07 UTC (Tue) by Wol (subscriber, #4433) [Link] (4 responses)

Actually, A LOT.

Have you ever heard of "groupthink"? Where someone comes up with a stupid idea that becomes the consensus because no-one argues? I despise relational databases because I think that's exactly what happened there - it got into universities and nobody nowadays knows any different!

You NEED to be exposed to different ways of thinking. I speak four languages (to varying degrees of ability). That's massively broadened my thinking. One only has to look at how insular and isolated most Americans are to see how that's a bad thing. Us Brits aren't that much better, but at least pretty much all of us only live a couple hundred miles at least from an international border.

And then you look at Europe, where most people are exposed to multiple different ways of thinking as a matter of course!

Do you want to be a sheeple, or do you want to be in control of your own mind? Who cares if you never use BSD outside of playing with Slackware. The fact that you have EXPERIENCE of different ways of doing things will broaden your mind. Who cares if BSD is ancient? Knowing what people did in the past is important - "those who do not learn history are condemned to repeat it" - you could come up with some brilliant "new" idea, and only after a lot of work discover that it's an old idea from Slackware that was abandoned because it didn't, in reality, work!

Cheers,
Wol

Isn't LFS for learning?

Posted Feb 10, 2026 13:15 UTC (Tue) by amacater (subscriber, #790) [Link] (1 responses)

Wol: Slackware != BSD. Slackware is the first mainstream Linux distribution that still survives - a couple of months ahead of Debian and a further month ahead of Red Hat.

Isn't LFS for learning?

Posted Feb 10, 2026 14:27 UTC (Tue) by Wol (subscriber, #4433) [Link]

> > > Slackware uses BSD style init

I know Slackware is not BSD. But as the above quote says, it uses the BSD init (unless that quote is wrong).

Slackware is still my goto "emergency boot" distro ...

Cheers,
Wol

Isn't LFS for learning?

Posted Feb 10, 2026 14:36 UTC (Tue) by kleptog (subscriber, #1183) [Link]

> You NEED to be exposed to different ways of thinking.

Sure, but I'm not convinced sysvinit is worth it. If there was some underlying architecture behind sysvinit, some structure that could be learned from and applied in other situations, maybe. But sysvinit is essentially the result of lots of different people scratching their own itch over decades with no plan, just throwing stuff together and calling it done when the system boots. Different tools written in different languages in different styles with different config formats.

But sure, if your goal is: how to boot a system using only tools written 30+ years ago, then sysvinit is perfect. It will teach you all the powers and limitations of those 30 year old tools. That has to be worth something.

systemd is by no means perfect. I thought the summary here[1] did a good job of the history and summerising some of its bigger design flaws. There are some lessons there for an eventual successor to systemd, but those lessons are not really relevant to people actually using systemd.

In the end it comes down to: what are you actually expecting to learn from LFS. About modern computer architecture, about 30 year old tools, or about how to sysadmin a system?

[1] https://blog.darknedgy.net/technology/2020/05/02/0/ (systemd, 10 years later: a historical and technical retrospective)

Isn't LFS for learning?

Posted Feb 10, 2026 16:31 UTC (Tue) by denials (subscriber, #3413) [Link]

Do you want to be sheeple, or do you want to control your own mind?
By insulting the people you want to convert to your cause, you lose them before you can even pitch your argument.

Isn't LFS for learning?

Posted Feb 10, 2026 16:26 UTC (Tue) by epa (subscriber, #39769) [Link]

I think it's the "from scratch" part. With BSD init (and with Slackware in general) the system runs on a narrower base of basic tools. If package installation is essentially 'tar x', then having learned about tar you don't need to also learn rpm or dpkg. If the bootup sequence is a series of shell scripts, then as long as you already know the Unix shell there is not much additional code on top. (For the sake of argument I am assuming that you'd have to know about tar and shell scripting *anyway*.)

There is also value in building a systemd-based Linux distribution from scratch; that will also teach you a lot and perhaps it would be more relevant to contemporary Linux systems.

Isn't LFS for learning?

Posted Feb 10, 2026 17:56 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] (2 responses)

I think the idea is to learn the basics of how a system works by looking at something that's simple enough to wrap your head around. SysV init is definitely simpler than systemd, at least in the sense that it does a lot less. It's simple-minded and requires the users to do a lot of thinking for it, like figuring out what order the services should start. That's bad if the goal is to get work done, but it might be helpful if the goal is to make you learn everything the system is doing behind the scenes.

Isn't LFS for learning?

Posted Feb 11, 2026 1:05 UTC (Wed) by anselm (subscriber, #2796) [Link] (1 responses)

SysV init is definitely simpler than systemd, at least in the sense that it does a lot less.

It does a lot less, but in multiple chaotic ways, no two of which are remotely similar to one another or support the same features. Not exactly what I would call “simple”.

One of the main advantages of systemd is that it unifies the way processes are started across what used to be init (with /etc/inittab and init scripts), inetd, cron, at etc. This on its own is a major win already.

Isn't LFS for learning?

Posted Feb 11, 2026 7:29 UTC (Wed) by taladar (subscriber, #68407) [Link]

Agreed, complex as its code base might be in comparison, wrapping your head around systemd is a lot easier than doing so with even a single sysvinit script, especially without a lot of hand-holding and pointing out what you did wrong in your script.

Isn't LFS for learning?

Posted Feb 16, 2026 19:13 UTC (Mon) by davylin (guest, #182390) [Link]

Comtos Linux is a SysV init operating system developed based on LFS (Linux From Scratch).
Mainly targeting the fields of servers and embedded systems.

Comtos Linux 9 uses LFS (Linux From Scratch) 11.1 process and CentOS Stream 9 source code.
Comtos Linux 9 is a SysV init system that does not involve desktop environments and does not use systemd and D-Bus.

Learning tool?

Posted Feb 9, 2026 21:26 UTC (Mon) by xtifr (guest, #143) [Link] (1 responses)

For an introductory learning tool, I would think Minix would be a much better system to use! Simple code designed for teaching without the countless confusing special-case optimizations found in the kernel alone!

I've never used LFS, but I always assumed it was more of a roll-your-own type of thing than a learning tool. But as a learning tool, I would think it would be more useful as an advanced one, showing how complex real-world systems can get. "When you have to deal with actual cows, you can no longer assume they're spherical!"

Just replacing systemd with sysv-init is not going to make your Linux system simple or easy to understand! It will barely make it simpler! :)

Learning tool?

Posted Feb 10, 2026 15:02 UTC (Tue) by rschroev (subscriber, #4164) [Link]

Minix is for learning Unix-like kernels: how they work, what the code looks like.

LFS is for studying what it takes to get a full working system from all its different parts. Not from a kernel developer's standpoint, but more an integrator's perspective. You can use it to create a fully custom system, but mostly the purpose is educative.

Good riddance

Posted Feb 10, 2026 16:23 UTC (Tue) by iq-0 (subscriber, #36655) [Link] (4 responses)

System V init only real merrit is that it's something that people had to learn at one point, much like a rite of passage. There is nothing logical, elegant or intuitive about the whole thing. Really it's an init process (you know the thing that does the inittab and basic runlevel tracking) and some other toolchain "rc" that decided "this is annoying and limiting, let's workaround it with this whole bunch of scripts". Basically we had a basic super process that does things like starting, stopping and restarting services and because it didn't fit some use case it was basically thrown out of the window and some procedural mess that was in place is what has people singing praises of that init system.

Not saying LFS should or shouldn't do systemd instead. That depends on perspective. If it is:
- to show how a modern Linux system works from the ground up, then, since systemd is the thing that makes most Linux servers and workstations tick today, show that
- to show how to manage a system consisting of multiple services, then almost any other system than sysv init would do: systemd, upstart, runit, s6, ..
- to show how little is needed to get a functional system, then skip the whole init system stuff and show them 1 script that does the basics and calls rc.local to do any other stuff (including run-parts on an /etc/rcX.d directory if that is what you want) or use some other init-stub, because you're clearly not doing any real service management, just forking some processes.

A the end of the day almost anything other than the thing that most people think about as the "Sytem V init" system is better. But what do I know, I have a bucket-list item to dive into System V and confirm that is what they actually used, because I have some suspicions about that.

Good riddance

Posted Feb 10, 2026 16:28 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

The irony is that at least 2 System V derived Unixes use proper service managers to launch services. AIX had a number of service managers, a long long time ago (some kind of 'service-type' specific, I don't know AIX well enough to know if it had a general service manager). Solaris transitioned to one for Solaris 10 (SMF).

Good riddance

Posted Feb 12, 2026 10:15 UTC (Thu) by philh (subscriber, #14797) [Link]

The bit of AIX that sticks in my head from when I occasionally had to port stuff to it in the 90's was that I liked smit (System Management Interface Tool) for two reasons:
  • when doing things for you, it would show you the shell command that would have let you do the same thing from the CLI
  • when using the X UI for `smit`, there was an icon of a little person standing in the corner of the window frame. When you clicked on something that would run a command, it animated as running, and if that command returned an error, it would fall flat on its face -- that made me laugh out loud the first time I saw it :-)

Good riddance

Posted Feb 11, 2026 7:27 UTC (Wed) by taladar (subscriber, #68407) [Link]

More importantly, if you do want to teach sysvinit or BSD init merely for historical context you don't have to maintain a system with current packages of everything, a VM of a frozen set of packages will do and save a lot of effort.

Good riddance

Posted Feb 15, 2026 18:08 UTC (Sun) by iq-0 (subscriber, #36655) [Link]

Okay, that's one less item on the bucket list. I just looked into a filesystem from System V R1 for the PDP-11 and AT&T SYSVr4v21.

Regarding the init system, it was pretty much what I expected to find. The basic "init" command has stayed roughly the same and uses the /etc/inittab to determine what to run for each runlevel. Nothing unexpected or exciting here.

In R1 this basically amounted to starting stuff in the /etc/rc shellscript for most runlevels.
In R4v2.1 we have the /etc/rc[0-6].d like we know nowadays.

So basically have /etc/inittab which was meant to be a concrete mechanism to run different operating system modes, depending on their runlevel. But really this was mainly used to go from boot to single user or one of the generic runlevels for the system and finally to reboot or shutdown modes. From the start it is already capable of running specific commands once or to respawn them when they exit. And it has the logic to determine which of it's respawn commands it needs to stop when switching to a runlevel where they're no longer needed. It's basically everything one would need for keeping a couple of essential background services running and to allow for some one-time setup when switch runlevels.

This works, but was also a bit simplistic. There is no ordering around the background services being spawned. The whole configuration being one inittab basically meant it was harder to manage changes around software installation and if there was an error it might mean a non-functional system (until it was fixed). So I suspect many sysadms chose to add their startup logic to the /etc/rc file instead, which is more forgiving.

But a big script to start everything became tedious and sysadms probably expected daemons they pkgadd'ed to be started automatically, so this single script was extended to provide a directory where each package could put their own startup files. And in order to sort of handle dependencies they used basic lexical ordering to give some semblance of order. And to handle shutdowns (which init doesn't handle for non-respawn processes) they added the logic of calling all daemon stops that shouldn't be running logic.

All in all we now have gotten to the "let's try to do service management using shell scripts" logic that people associate with System V init system. Which is actually a workaround to make try to make a single shell script more manageable. And effectively has almost nothing to do with the real init system, which was mostly under-utilized (though mostly due to missing amenities).

Or to put it simply, what most people consider to be the System V init, is in systemd parlance 1 oneshot service that calls a script. And instead of making the init system suit their needs, they extended that one script to basically become a scripting framework to do some semblance of system initialisation. So, for all the people that yearn for the good old System V init system: Just call all your scripts in lexical order based from one oneshot service in systemd and you've basically done to systemd what was done with the System V init system.

SVR1: https://www.tuhs.org/cgi-bin/utree.pl?file=pdp11v
SVR4v2.1: https://github.com/NeoTorino/Unix_System_V

I can sort of see the evolution...

Posted Feb 14, 2026 16:13 UTC (Sat) by bferrell (subscriber, #624) [Link] (1 responses)

For BLFS (Beyond LFS)...
LFS has always been a stepwise thing; Get the basics, and then evolve.

I HATE systemd... Yes, it's kewl and shiney (and crufty too). I detest how deeply it crawls into everything, but I've learned to deal with it.

THAT is a part of learning the evolution too.

I can sort of see the evolution...

Posted Feb 16, 2026 9:34 UTC (Mon) by taladar (subscriber, #68407) [Link]

I am curious, what is the alternative to systemd that you don't hate? Because from my experience init scripts certainly weren't a well loved part of the Linux stack in the time before systemd.

Comtos Linux is an LFS (Linux From Scratch)-based distribution targeting server and embedded systems. Comtos Linux is a SysV init system.

Posted Feb 16, 2026 19:14 UTC (Mon) by davylin (guest, #182390) [Link]

Comtos Linux 9 (Vermilion Bird) officially released
Release location: Shenzhen, China
Release date: December 1, 2025

Comtos Linux: The Transparent Enterprise Linux - Build, Audit, Customize.
Comtos Linux is an LFS (Linux From Scratch)-based distribution targeting server and embedded systems.

Note: Comtos Linux is an open-source operating system created by Chinese developer Lin Zhongxin on January 1, 2024, in Shenzhen, Guangdong Province, China. Developed based on LFS (Linux From Scratch), it is suitable for servers and embedded devices.

[System Overview]
Comtos Linux is a SysV init operating system developed based on LFS (Linux From Scratch).
Mainly targeting the fields of servers and embedded systems.

System name: Comtos Linux (Community Operating System Linux)
English code name: Vermilion Bird
Chinese code: 朱雀 (Zhuque)
English abbreviation: Comtos (pronounced as ['kʌmtəʊs])
Chinese abbreviation: 朱雀系统 (Zhuque System)

[Development background of Comtos Linux]
Created and maintained by engineer Lin Zhongxin from Shenzhen, Guangdong Province, China on January 1, 2024.
System positioning: Positioned as a transparent enterprise level Linux distribution with customized build, audit, and other functional features.

[Technology and Disclaimer]
Comtos Linux 9 (Vermilion Bird ) uses LFS (Linux From Scratch) 11.1 process and CentOS Stream 9 source code.
Comtos Linux 9 (Vermilion Bird) is a SysV init system that does not involve desktop environments and does not use systemd and D-Bus.

Comtos Linux
Based on Linux From Scratch (LFS)

Comtos Linux official website: https://www.comtoslinux.cn

Comtos Linux source code hosting website:
Source Code Hosting Homepage： https://comtoslinux.sourceforge.io

Comtos Linux Gitee Homepage: https://gitee.com/comtos-linux

LFS isn't a book??

Posted Feb 23, 2026 20:24 UTC (Mon) by Hi-Angel (guest, #110915) [Link] (1 responses)

Oh… I always thought LFS is the book that describes how to build your own system from scratch, up to choosing a package manager on your own. Didn't know they provide repos with packages 🤔

LFS isn't a book??

Posted Feb 23, 2026 20:53 UTC (Mon) by daroc (editor, #160859) [Link]

They use upstream release tarballs, but they have a separate mirror for them so that people can download all the tarballs referenced in the book from one place. There's no automatic package building or support scripts (in the main LFS book, anyway), so it's less "a package repository" and more "this one directory that contains release tarballs that you can download".


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds