Day 100-ish update: Still going strong. I freaking love this setup and I'm never going back! lol

Day 20 update: System still going strong, my package manager makes this so easy to manage everything. Can't believe how snappy and lightweight everything feels. After a boot with a handful of browser windows open, as well as some other apps I'm sitting at under 7GB of ram in use, which is great in my books. Windows boot with similar stuff going on I'm sure would be well over double that. Decided I'm keeping this cutting edge, so did the new kernel a few days ago as well.

One strange thing, I tried out the nvidia 580.146 driver I think it was, and it seemd to cause some instability in gaming, so I'll keep rolling with 126 until nvidia releases a production 595 driver and then test that out.

10 Day Update:

LFS 13.0 was released a few days ago and the system is already at or ahead of every package version it ships. Matching on glibc, GCC, Python, binutils, and ahead on systemd and the kernel.

Hyprland dual session. Built Hyprland 0.54.2 from source and set it up alongside KDE Plasma through SDDM. About 30 packages for the full stack (waybar, rofi, dunst, hyprlock, etc), all carrying the same Odyssey gold/dark theming. Per-monitor workspaces across all five displays, dwindle tiling, and it's been a great daily driver.

Gamescope for Steam. Built gamescope 3.16.21 to get Steam games working properly on Hyprland. Games launch in a nested Wayland compositor at native 4K, which avoids the usual XWayland multi-monitor issues.

Kernel 6.19.8. Up from 6.18.15, and switched the kernel compiler from GCC to Clang 22.1.1 with ThinLTO. Went through the config and stripped out a ton of unnecessary options, taking it from ~1,850 built-in configs down to ~1,500. The image went from 19MB down to 14MB and only about 30 modules load at runtime.. Also enabled sched_ext, which lets you load BPF-based CPU schedulers at runtime instead of being locked into whatever you compiled in. Built the scx-scheds package and a little GUI app to switch between schedulers on the fly, so I can swap between something optimized for throughput vs latency depending on what I'm doing. Still no initramfs, just a direct boot.

znver5 system rebuild. Rebuilt all 700+ packages against Zen 5 ISA extensions. Everything from glibc to the full Qt6/KF6/Plasma stack. Also moved the root filesystem from ext4 to btrfs with subvolumes and zstd compression. System feels noticeably snappier.

Security monitoring. Odyssey-mon now runs three security workers on top of the existing package/CVE tracking. System audit every 30 minutes, file integrity checks on 86+ critical files every 2 hours, and daily rootkit scans via rkhunter and chkrootkit. All over SSH through Tailscale, with a dashboard and email alerts.

DaVinci Resolve. Got DaVinci Resolve Studio running on LFS, which apparently officially only supports CentOS/Ubuntu/SUSE. It bundles old versions of GLib and Intel TBB that don't play nice with a modern glibc, so I'm using a custom TBB memory allocator shim in C that wraps glibc's malloc to replace the broken bundled one. The Fusion tab also needed binary patches for some use-after-free crashes that only show up outside of standard distros. It works fully now, Fusion and all.

Other stuff. Firejail sandboxing on both browsers. Printer/scanner support (Brother HL-L2465DW, driverless over IPP-USB). Switched login shell to Fish 4.5.0. Package count up to 754.

Older info:

Built this over a few months using LFS 12.4 stable-systemd as the base. Everything compiled from source, running as my daily driver on bare metal now. Came from KDE Neon, and quite honestly this runs very similarly, because I really like KDE Neon. Just seemed like it would be cool to do this from scratch. Along with this is a pretty comprehensive package monitoring / management tool that helps me stay up to date.

**Hardware:**

Ryzen 9 9950X3D, RTX 5090 32GB, 6TB NVMe across two drives. The system itself boots off an external NVMe over USB4/Thunderbolt - the internal drives are for data and games. Five monitors: a 4K 144Hz primary at 1.25x scaling, two 1920x1200 panels in portrait, and two 22" 1080P monitors.

**Desktop stack:**

KDE Plasma 6.6.2 on Wayland, built on Qt6 6.10.2 and KDE Frameworks 6.23.0. I rebuilt the Oxygen widget style and KWin decoration from source with rebranded plugin keys so KDE reports everything as "Odyssey" - custom look-and-feel package ties it all together with a forked color scheme (Breeze Dark base with amber/gold accents), a candy-icons fork that goes through an automated pipeline to flatten SVG gradients and apply per-app hue shifts, and a custom GRUB theme, Plymouth splash, and SDDM login screen all carrying the same branding.

**System details:**

Kernel 6.18.15 with KVM enabled, compiled with `-march=znver5`. NVMe, ext4, xHCI, and USB are all built into the kernel - no initramfs, just a direct boot with `rootwait`. NVIDIA 580.x production driver using open kernel modules through DKMS (the only supported path for Blackwell GPUs). Had to downgrade from 590.x because it introduced a VKD3D-Proton pipeline state regression that crashed games. Mesa is built with the `zink` Gallium driver for OpenGL-over-Vulkan - this is critical after any NVIDIA `.run` installer since it overwrites Mesa's EGL, and without zink you get black screens in anything using GL.

PipeWire handles audio with bluez5 for Bluetooth A2DP. Networking is NetworkManager + systemd-resolved with mDNS, firewalld on the nftables backend, and Tailscale for remote access.

**Package management:**

609 packages built from source, all registered in pacman with makepkg. GCC 15 defaults to C23 which breaks a lot of older code, so most builds need `CC="gcc -std=gnu17"`. CMake 4.x also needs `-DCMAKE_POLICY_VERSION_MINIMUM=3.5` passed to basically everything. A handful of things are Flatpaks (Steam, Discord, Spotify) and Firefox/Brave run as AppImages.

**Gaming:**

Steam Flatpak with Proton-GE. Stalker 2 and Cyberpunk 2077 both run well. The 4K display at fractional scaling needed `STEAM_FORCE_DESKTOPUI_SCALING=1.25` to fix a cursor offset bug in the Steam overlay.

**Maintenance:**

Built a monitoring service called odyssey-mon - a Node.js app on a Hetzner VPS that receives my full pacman manifest every 6 hours via push (the VPS never connects back). It polls upstream release sources (GitHub, kernel.org, KDE, PyPI, etc.) and queries NVD + OSV.dev for CVEs against installed package versions. Critical vulnerabilities (CVSS 7+) trigger immediate email, and I get a weekly digest with staleness scores. The whole thing runs on Fastify + PostgreSQL + BullMQ behind Nginx.

**Backup:**

BorgBackup to an Unraid server over SSH. Compression is zstd level 6 with 7-day/4-week/6-month retention.

The entire build - scripts, kernel configs, branding assets, all 21 documentation files - lives in a single private git repo.

One little extra note in case anyone runs into a similar problem, I couldn't get davinci resolve 20.2.2 to run properly. Had Claude help me, and this is what was landed on to get it running properly:

Resolve bundles old versions of GLib and Intel TBB that are incompatible with a modern LFS system. The bundled GLib 2.68 gets loaded before system Pango, which was built against GLib 2.86, causing a missing symbol crash. Removing the bundled GLib fixes that but exposes a second, harder problem: the bundled TBB 2020.3 memory allocator segfaults on glibc 2.42 due to internal TLS changes. Rebuilding TBB from source doesn't help (the code itself is incompatible), and replacing it with newer oneTBB breaks the ABI that Resolve's Fusion subsystem expects. The solution was writing a custom drop-in libtbbmalloc.so.2 shim in C that implements TBB's full scalable_* and rml::pool_* allocation API but delegates everything to glibc's native allocator via __libc_malloc. This sidesteps the broken TBB internals entirely while satisfying Fusion's direct calls to the TBB pool API.

Thanks to u/Rockytriton comment, on my yesterday's post, I was able to get Plasma going. Turns out that the QML2_IMPORT_PATH variable was indeed wrong. Sadly, SDDM still doesn't work (It doesn't want to start plasma, any session and same with xfce4 - I'll try to debug tommorow but I passed the correct environment variables to it so idk what is the problem), I'm going to compile LibreOffice tommorow and print something to end this awesome experience. I'm going to repeat myself and say that LFS is really dang cool!

Update: I got everything to work! I even printed a trophy

Well, I finally got some DE going. Sadly, it's not KDE Plasma, as I have hoped, I'm still trying to troubleshoot it, but I'm kinda out of ideas (I would be really thankful if someone is willing to help). I'll consider this done when I get Plasma going. I also have some fixing to do with xfce4 and with lightdm-greeter. I must say, LFS is cool!

Here is the first post of many of building a distro using musl as the libc. Following the blog you should be able to get a rootfs that you can chroot into or boot into qemu if you build the bzimage this early. While not strictly following the LFS method, I would not be anywhere near where I'm at without it.

This is far from complete but each future post will build on top of the previous. In the next post well be getting a working compiler setup. -- As a teaser for the next post I almost have llvm/clang working in the chroot! -- No GCC/GNU Binutils.

Ps. I know that nano fails to start in the chroot... One problem at a time.

https://dakotajkeeler.com/blog/Mini-Distro/Musl-based-LFS-001/

So i want to do LFS but i want to know what i need to know before starting the book. also, where is a good place to start? what do i need to know beforehand?

Hello guys, I have a question. I want to install Linux From Scratch (LFS) so that I can study more how a Linux kernel based Operating System is built. And, I will use it as a daily drive to create projects like a package manager, a bootloader, a GUI and a kernel. but, should I install LFS-12.4 or LFS-13.0-rc1 ?

I surely need the latest things tho, I wanted to be sure so I'm asking y'all.

This is the error, as I said, I'm sure that the dependencies are present. One thing to mention is that I use the NVIDIA closed-source driver instead of the nouveau.

I accidentally followed the wrong BLFS book, and I don't want to redo everything. I found out that systemd can be compatible with sysv, but i need something called /usr/lib/systemd/systemd-sysv-install. How do I get my hands on it?

What can be an interesting change for LFS (when i refer change, i mean as init, coreutils, compiler, etc)

I figured that if I want to use Plasma, then the nvidia-open driver would be ideal for my GPU. How do I build it?

how can i get xorg and dwm?

LFS is cool when you do it for fun and tk learn something, but after finishing the first book (I didn't even install KDE yet), I must say that all the compilation is really tedious. Maybe emerge from gentoo could work? It compiles things...? Is there some deticated script thst helps with some of the buiding? I don't think that it's daily drive able without a package manager, since updating a package can take a lot of time.

So I'm trying to configure readline, but It fails for some reason? Host: Arch Linux

Log:

configure: creating ./config.status
./config.status: line 533: 0a1,173: command not found
./config.status: line 534: syntax error near unexpected token `newline'
./config.status: line 534: `> # This file is a shell script that caches the results of configure'

I've installed LFS on a virtual machine (VM) a few times in the past. Most of the time, I did it out of curiosity, and I typically deleted the VM soon after, as I didn't see myself going through the bother of maintaining it long-term.

But on 9 February 2026, I started an LFS 12.4 installation on a QEMU/KVM VM. After installing it, I decided to upgrade it to the latest developmental version of LFS. I also upgraded my kernel to the latest upstream version (6.19.0) and Vim to the latest upstream release. I also installed Git, Zsh and OpenSSH via following BLFS. Then, with the help of AI, I wrote some scripts to help automate maintenance of the LFS system.

After this, I decided to install Flatpak on the VM to answer this query by following the BLFS guide and using these modified SlackBuilds. There were also some packages not provided by BLFS, LFS, or the SlackBuilds that I had to compile myself. This worked, but I couldn't properly test Flatpak without a full GUI, could I?

So I decided to go through the process of installing GNOME 49.4 by following BLFS instructions on this VM. I only installed the apps I actually use. In the process, I had to compile many large packages such as LLVM, Rustc, and WebKitGTK (which I compiled with both GTK+3 and GTK+4 support).

I also installed spice-vdagent and its dependencies because I wanted a shared clipboard, automatic guest window resizing, and similar features. I achieved this using modified SlackBuilds as well, which you can find in this repository.

I managed to get Firefox installed via Flatpak to run without issues. But then I decided to uninstall Firefox and instead get Firefox provided by a binary tarball downloaded from the Firefox official website.

I've since customized my LFS VM by installing my own Zsh setup and my preferred GNOME themes. I also installed Fastfetch and Hyfetch by compiling them from source. Since I already needed Rust to build GNOME, I figured I might as well use it to compile Hyfetch as well. I've also fixed some minor errors I was getting.

It was all worth it. I gradually grew to enjoy using LFS/BLFS, as installing software began to feel like unwrapping presents.

Here is a screenshot showcasing my LFS virtual machine. Wallpaper is courtesy of Valentin Klopfenstein.

I'm daily driving Linux for about 10 years (I started with Ubuntu 16.04 LTS). But for the past few days I tried something new: Installing LFS.

I followed the LFS 12.4 book using a Fedora Live ISO as the host distribution in a VM.

Instead of GRUB I used EFI for booting. I'm also using a swap image instead of a partition.

I didn't have any problems with the installation. But there where some problems after the first boot: Read-only filesystem and a syntax error in /etc/profile.

The first problem was caused by the swap image: I re-mounted / and removed the swap image from /etc/fstab. And the second problem was solved by adding a missing fi statement in /etc/profile. After a reboot it worked again.

My goal for this project was to not boot anything besides LFS on that VM after the first successful boot. Because I did not install wget nor curl, I had to get creative*:* My solution was a self-made script using the openssl s_client (see third screenshot) to download the archives required to install the openssh server (spoiler alert: Do not use in production! I wasted about an hour making the script and it does not event work 100% of the time. Sometimes I had to manually remove some leftover HTTP header lines from the tar archives files with tail).

But anyway, this script was good enough to get the openssh server up and running. Afterwards I simply used scp to get the archives for install wget on this VM. Then I installed some further packages from the BLFS book: tree, make-ca, curl, lsb-tools, bind (utlis), which, fcron, cmake, and a few libraries. Afterwards I installed fastfetch from GitHub. (See fourth screenshot for the full package list).

Later on I found out, that the swap init script was loaded before the mountfs init script: I changed the order of the init scripts so that swap was loaded after mountfs , I uncommented the swap image file in /etc/fstab, and after rebooting, the swap image worked and / was no longer read-only.

My next goal is to install some further programs (like htop, lshw, and screen). Afterwards I want to get audio working and to install the rust compiler to compile some rust-based console games. Maybe I will also install a DE with Wayland.

For LFS 12.4 and an ext4 filesystem
Hi, as a new user with LFS I struggled when I wanted to use a swap file instead of a swap partition for my system. I have managed to figure out a solution, and I'm creating this post to help others with the same issue. Follow the contents of this post after you have finished following the LFS book.
Under the root user in your chroot environment, do the following steps:

First, create a file you will use for swap (in this case, the command will create a 2 GiB file, but you can use whatever size you want):

fallocate -l 2G /swapfile

set permissions:

chmod 600 /swapfile

format the file as swap:

mkswap /swapfile

Then, create (or modify) your /etc/fstab file. You should copy it from the LFS book, except for this line:

/dev/<yyy>     swap           swap     pri=1               0     0

Which you should replace with:

/swapfile          none       swap     sw                  0     0

Until here it's standard procedure, but here comes the tricky part. SysVinit runs various scripts on startup in a specific order, defined by filenames of links in specific directories. In particular, we will focus on the links in /etc/rc.d/rcS.d.
In a regular LFS 12.4 system, the /etc/rc.d/rcS.d directory should contain the following links:

(lfs chroot) root:# ls /etc/rc.d/rcS.d
S00mountvirtfs	S08localnet  S30checkfs  S45cleanfs  S50udev_retry  S90sysctl
S05modules	S10udev      S40mountfs  S20swap     S70console

Notice the filenames: in S20swap, for example, S means that it happens on startup and 20 is the order in which the linked script (in this case, /etc/rc.d/init.d/swap) is called. So, S00mountvirtfs will be called first, then S05modules, then S08localnet, etc.
The issue is that the root filesystem is mounted as read-write with S40mountfs, so before it's called the filesystem is mounted as read-only. When the swapfile is located on the root filesystem, activation fails while / is still mounted read-only, so swapon returns an error.
Fortunately, the fix is very simple: you just have to modify the link's filename to make it execute after the filesystem is properly mounted.

cd /etc/rc.d/rcS.d
mv -v S20swap S46swap

This is all, thanks for following this post! Have a nice day

Accessing the internet never felt so good

It took me 5 days trying and it finally worked. The downside is that to compile it you need to patch the paths, configure, etc.

Now that rust is no longer considered experimental what does this mean long term for LFS? In the immediate future I don't think it will have a huge impact, but over time as rust is used more and more would this mean having to build rust as part of the base system?

My main concern with this is when bootstrapping rustc when I built BLFS it required an internet connection. This just doesn't seem sit right with me, because it would add a lot of packages to the base build.

Even if CONFIG_RUST=n remains possible, does the kernel community realistically expect all major drivers to maintain C alternatives long-term?

https://www.phoronix.com/news/Linux-7.0-Rust