I gave LFS a go earlier this year. I learned a lot through the process - but I definitely went outside the guardrails. I use NixOS as my daily driver and found myself curious of whether I could complete LFS using a "Nix" approach. I was only a basic Nix user at that time and that choice made a difficult process much more difficult. However, the declarative nature of Nix meant that I had clear notes of every step of my process - and if something didn't work, I could backtrack and troubleshoot to find the root of the cause. The end result is here [0].
My understanding of Linux, of bootstrapping, cross-compilation, and Nix has grown tremendously as a result of the time I took on this project - and I still go back and reference the work from time to time. When I get some time to revisit the Nix-based LFS project, there are quite a few things I would like to clean-up, including setting kernel configs and handling post-build permissions.
Nix-complexities aside, I highly recommend LFS if you like to understand how things work and don't mind a little suffering along the way.
I really like the idea, really tried following the process several times. But each time it just turned into a copy-incomprehensible-commands-into-the-terminal exercise at some point, and I lost motivation. Did anyone experience the same?
It feels to me like you have approached this with a wrong mindset, like you focused too much on finishing the whole process.
With LFS you must put substantial amount of value into the journey itself. It's not about copy-pasting commands, it's about trying to actually understand what and, more importantly, why your are doing each step. My recollection is that LFS docs were good in helping with that. Or maybe it was coming from reading docs of the actual components as I went along? I don't remember, probably some mix of both.
I did set LFS system up once, I think it was 2001 or 2002. I specifically remember that it took many days (due to compilation times), was very interesting, and at the end I was putting final touches to my mutt and slrn configs. With a vague memory that I had some TODO for mutt that I didn't finish, still lingering in my mind, apparently! :)
All in all, great and satisfying learning experience.
I would not use such system as a daily driver, though. I think it's good only if you have time and want to learn. I'm curious if someone here is brave enough to have different approach.
I built my LFS around 20 years ago. While I followed instructions most of the time, I built some components myself. I remember that I wrote by own init scripts and I think I wrote my own initramfs (not completely sure about it, but I definitely remember tinkering with it and it probably was LFS).
I also wanted to implement an isolated build system and my own package manager (basically tar wrapper with file database to be able to uninstall, no fancy dependency stuff), but containers were not invented back then and my skills were not good enough to properly utilize fakeroot, so it never was implemented, although I spent some time experimenting. Today I would do it with docker, exciting time.
Wanting to (and doing it) make my own package manager because of LFS and minimalism in general, good times.
When I was in highschool I had a bunch of free time outside of school days. I used a YouTube guide to install Arch. I failed many many times. But in doing so I almost kind of learnt what each command was doing.
I had the same experience when I installed Gentoo. In both cases at first I was copy/pasting commands, but through failure I ended up understanding a lot of what the commands did.
And what someone else said below is true as well, actually try and force yourself to understand what you're typing. Even briefly just scanning a man page helps a lot.
I wonder if the wiki would have been an easier start, than YouTube. YouTube is nice for learning things with a visual component, but installing Linux is all text, all the time. The ability to easily hop around and re-read sections on the wiki where necessary (I mean, jumping around is possible on YouTube of course, but it is really easy on the wiki) seem like it would be a big help.
Last time I tried (probably well over 10 years ago) I struggled more with how long stuff took to compile. The main learning I remember from it was the chroot concept, which then later helped me grasp containerization easier
I grabbed a random page from the manual:
https://www.linuxfromscratch.org/lfs/view/stable-systemd/cha...
Every step is explained and every used parameter is documented.
Yes this and endlessly unzipping things. I gave up after many many hours. I doubt I learned much from it.
Same for me. I tried it about 20 years ago. I didn't fell like I was learning anything, just copy paste like you say. I haven't retried since, but I think it would be much better if they explain what you are doing and why.
I haven't tried this but I have used https://github.com/MichielDerhaeg/build-linux during my trainings and all my students quite enjoyed the experience. It basically builds a Kernel, libc, busybox, init etc. and gets the whole thing running inside qemu.
I found it quite educational and worth the little time I spent on it.
Haven't tried it, but I guess if you were doing this again today, ChatGPT would help a lot.
> Did anyone experience the same?
I tried several times, and tried again just recently. I share your sentiment. It perhaps gave me a renewed appreciation of the huge benefits Linux ditributions and package managers give us.
Yep, basically. At some point you realise you could do it, but do you really want to go through it all... It's a slog.
It is a fun experience though!
> It's a slog. It is a fun experience though!
Aren't those two opposites?
Type 2 fun
it's better if you try to work out what the commands and options are doing. I did this a long time ago, and 15 years later, I realise that it gave me a big advantage over my colleagues who haven't done something like that. "missing xxxxx.so" - they don't even know what that means, whereas I'm already trying to find the so and putting it in ld_library_path to see if it helps.
In my experience, whenever a .so was missing it was either due to a missing package on the os package manager level, or a completely broken gcc or llvm setup. I never needed to explicitly add single .so files to a path. (Besides the use case where I specifically wanted to override a malloc implementation.)
In which cases did/do you need to add individual files?
In my case, when I was a Slackware user before Slackbuilds was created, sometimes I wanted to try out programs for which there was no package. Usually they required a .so file that was not installed and a workaround was to put it manually from a package of another distribution compiled for the same architecture. When the .so file was there, but on another path, a symbolic link was sufficient. The ldd command was a good friend.
Of course that was not the best and cleanest solution, having things outside the package management system bothered, but it was enough to experiment programs and I kept track of the changes so I could have the prior state of things. Later on, the Slackbuilds project eased the work and I contributed by writing code to automate the creation of a few packages. I learned a lot from these issues.
In my case, I work with proprietary EDA tools. Vendors love messing with LD_LIBRARY_PATH. Chaos ensues when they override a system library or two versions require mutually incompatible versions.
I agree with the comment you are replying to. Having broken my home Linux installs too many times has taught me how to diagnose and fix this sort of issues.
in this case it's an in-house monstrosity that's got a lot of various languages and build systems involved, and the moment you update a compiler or build system, everything jumps into a new location for no good reasons. it was just an example though - same issue with .h not found during compilation, or using a different compiler from the system wide one.
Nope. I never execute commands without understanding its meaning. Maybe you expect to complete a LFS installation in very little time. Which cannot be the case in general and in this very case in particular
This has been around for ages. I only read the contents briefly to know what the minimum components of Linux is, that too years ago. When you install any distro (even Debian) so much gets installed which newbies wouldn't even know exists or use.
You could argue that running through the woods doesn't teach you about trees, but it's really effective when you bring a book along.
Linux From Scratch is a fun way to explore what parts make up a Linux distribution. I did this a few time long ago before switching to Gentoo and it really helped with appreciating the freedom to pick and choose details of your operating system without actually writing it from scratch.
What's the fun in this? I once looked into it briefly and it's what I guessed: mostly about building and installing the required software individually. That's boring, I guess the fun would be in building an actual usable distro "from scratch".
The first run isn't much fun. There are useful skills in just knowing how to build stuff, and knowing all the constituent parts of a running system. But overall I suspect you'd learn more in a year of using Arch.
But on subsequent play-throughs, you get to be creative! Want to ignore the FHS and try putting your apps somewhere weird? Want to use a different libc or init system? Build everything around an esoteric shell? Go for maximum optimisation? It's the replayability that makes Linux from Scratch fun, and yes, totally worth working out what your own distro might look like.
You would start with LFS to build a base and then add your own package manager to make a “true” distro.
If you want to just build an existing distro from scratch then they all have ways of doing that as they need to rebuild packages regularly. Eg: It’s a lot simpler to build a fedora image from scratch by using Koji/OSBuild vs LFS as Koji/OSBuild basically automate the whole LFS process.
Additionally in order to have fun with LFS you don’t really need to do the whole book. You can make your own little Linux “distro” from scratch with the kernel and statically linked busybox. Busybox comes with all the minimal utilities so you can pick and choose what you want to write and what you want to reuse.
I wonder if some sort of “BSD from scratch” would be a more fruitful exercise. Since they include more of the overall system, you’d end up with something approximating a regular BSD install pretty well at the end.
I think it depends on one's true goals and the way it's approached. Compare with http://www.greenfly.org/mes.html (which affects many Arch users too, I feel)
You can think of a LFS as training before actually tackling an original distribution: distributions are complex, even following the steps of a LFS won't necessarily yield a working system (lots of room for mistakes).
Or, as a base to build a distribution: you can automatize some of the process, slap a pkgsrc on top, etc.
For budding programmers, it's a great exercise: discover software, appreciate dependencies, understand components of a Linux distribution, learn how to build things from source, configure a kernel, etc.
Building an actually usable distro means doing this, but every day for every package that updated, and scripting it for other people to use.
> building an actual usable distro "from scratch".
could you say a few words on how this would avoid building and installing the required software individually? are you thinking of osdev instead?
I assume they were alluding to package managers, automation, and release engineering, which are somewhat covered in the LFS Hints Project (https://www.linuxfromscratch.org/hints/)
I did this, once, on a 386. Did I learn things? Definitely. Will I ever do it again? Definitely not ;)
Heh, I did this back in about 2000 or 2001 with the intent of taking an old 486 I had mounted in a relatively flat case to fit under the seat of my car and turning it into an MP3 player. The process was a lot of fun, I learned a ton, and then... I discovered that I didn't realize I'd done the entire build targeting a Pentium CPU and all of the binaries contained instructions that the 486 couldn't run.
I did not repeat the process :)
I wonder, if you were to script all the commands you ran back in the day, and ran that same script on your old 386 and on a modern system with a top-of-the-line AMD Epyc or Intel Xeon, how much faster would it run?
There is a unit of compilation as part of the LSF book which lets you estimate the who build process. You only need to compile libc or some such.
Especially with the increase in storage performance - going from a hard disk that might have even still been using PIO modes to modern NVMe would be gigantic
The kernel is rather larger today: https://stopbyte.com/t/how-many-lines-of-code-linux-has/455/...
The same is true for all other pieces of software.
Build time will always increase until no one can be bothered to build it any more.
If you're curious, you should try it. It's a great way to learn about all of the little bits and pieces that go into a working OS that you can use, and by the time you're done you'll be more comfy thinking about Linux in general. It may take some time depending on how often you come back to it, but it's definitely worth it.
How up to date is this?
When trying to learn by copy-pasting from the internet, I sometimes get tripped up over older/newer Linuxes using different versions of commands or best practices. (e.g. ipconfig vs. ifconfig, iptables vs. successors)
It was last updated in September 2024. Distrowatch's package list can give you an idea of what version numbers to expect: https://distrowatch.com/table.php?distribution=lfs
Once you get to the BLFS part, you have more choice on whether you're going to innovate or use something that old and in maintenance mode. For example, it has instructions for both Pulseaudio and Pipewire, Xorg and Wayland, SysVinit and systemd. The instructions will rarely be outright incorrect on modern distros unless something is very strange about your environment, since a bulk of the work is done after establishing a more predictable build environment.
For those that want to see full source bootstrapped, deterministic, and container native LFS check out https://codeberg.org/stagex
Related: https://buildroot.org/
This basically allows you to make an OS that’s effectively a single application, right?
It will spit out a rootfs, or even a block image for a disk, which might make it _look_ like a single application. You will probably update your system by flashing that entire rootfs/image to your target device as if it was one application.
However, it is still Linux under the hood, so there is a kernel + whatever other applications you want running on there, all as separate processes.
You may also be thinking of busybox, which bakes an implementation of most of gnu coreutils into one file to save space. Many symlinks are often created to that sesame file, and when invoked the process can check what name it was invoked with to determine its behavior.
No. It creates a root filesystem that follows your choices of what should be included and tries to be as minimal and small as possible by default. Very suitable for embedded devices and lightweight virtual machines. You can have it build a kernel as well. I use the ability to create a cpio archive for an initramfs on the Linux boxes.
I reckon you are already aware of this if you’re using it to generate an initramfs, but for those reading along, you can also use it as a docker image
I went through this over a couple of weeks last year. Very fun, I would recommend it to anyone interested to see the complexity of making a linux distro.
I have gone all the way through this, #21584. What a tremendous resource.
I have used CLFS (Cross-Linux From Scratch) in the past a couple of times to build a Linux system for Sun UltraSPARC and SGI Octane systems.
The things I learned, especially about cross-compiling, were invaluable, but you do have to invest some time understanding everything (even reading patches that you have to apply on top of build tools, for example) to get the most out of it. If you just copy/paste commands, well then there are faster/easier ways to get Linux up and running
Edit: I just noted that CLFS has been dead for a couple of years now, which is sad. I would have loved to try an updated CLFS
to anyone confused why others find this fun or worthwhile, i will quote brak's dad: "you just don't get it, das all"
Ah yes, I remember the year I lost to this and the pain of cross compilation. Reader beware.
I've crossed-compiled things from time-to-time along the years, and it seems to me that support has improved a bit. Some time ago it was "cross..wut?" but now it is fairly commonly supported and tested. I think it's thanks to Raspi and other popular ARM-based things.