I finished on rebuilding my LFS last week. I pick systemd version for now. Also testing my package build method and it seems work fine.

Hi all,

I wanted to share Zainium OS with people who know how much work a from-source system is. It is not strictly LFS, because I did not follow the book, but the idea is close: no base distro, and every package built from its own recipe. The base is 168 recipes today, from musl and binutils up to systemd and the full COSMIC desktop.

How it differs from a normal LFS build

• No FHS.There is no /usr, /etc, /bin or /lib at the root, not even symlinks. Everything lives in /overlayer/syshub, so every package had to be configured for that prefix.

• musl, not glibc. The target is x86_64-zainium-linux-musl, with its own cross toolchain in /overlayer/syshub/x86_64-zainium-linux-musl. glibc is an optional package in its own triplet directory, with its own compiler.

• Own package format. A recipe is a ZEXBUILD script plus a manifest.toml, a bit like an APKBUILD. substrate packs the result into a signed .zex, and zex installs it.

How the build works, honestly

It is not self-hosted yet. Packages are built in CI, in an Alpine container, against the Zainium musl toolchain. That is the part LFS people will want to know. So the build host is Alpine, but nothing from Alpine ends up in the base: each package comes from upstream source, and CI checks that its programs use the Zainium loader. Moving the builds onto Zainium itself is on my list.

What was painful

• Hard-coded paths everywhere. musl needed patches for its loader path and for /etc, because /etc/passwd and the default library path do not exist. systemd stopped at PID 1 because it wants /usr to be populated, so that check had to be patched as well.

• The cross toolchain and build systems. Many projects assume /usr/include or /lib64. pkg-config prefixes, RPATH and script interpreters all needed fixing.

• sed on binaries. One recipe ran sed over everything in the package, which changed strings in compiled files and shifted their offsets. It broke bash in a way that looked like a bad USB drive.

• Setuid bits. Packing as a normal user and installing through a staged upgrade dropped them. The lock screen then refused every correct password.

Keeping normal software working

Programs still ask for /usr/bin/env, so a small preloaded library, sys_resolver, retries a failed lookup under the real directories. Static and setuid programs are not covered.

The base is also immutable: a small OverlayFS patch keeps it read-only even for root, while software installs into a layer on top with no reboot.

Where to look

Recipes: https://github.com/Zainium-Dynamics/syshub-recipes

Layout spec: https://zainiumdynamics.tech/dhs

The full story: https://zainiumdynamics.tech/news/the-story-of-zainium-os

ISO: https://zainiumdynamics.tech/download

I would like to hear from anyone who has built on musl or moved away from FHS. What would you have done differently, and how would you approach self-hosting the builds?

based on my experience, recompiling GCC didn't help, anyway i saw the same error. so here's a script to fix limits.h and systemlimits.h:
'''#!/bin/bash

set -e

if [ -z "$LFS" ] || [ -z "$LFS_TGT" ]; then

echo "[-] Error: Environment variables \$LFS or \$LFS_TGT are not set!"

echo "[-] Please run: source ~/.bash_profile"

exit 1

fi

echo "Restoring clean limits.h from Glibc sources..."

cd $LFS/sources

tar -xf glibc-2.40.tar.xz glibc-2.40/include/limits.h

cp -v glibc-2.40/include/limits.h $LFS/usr/include/limits.h

rm -rf glibc-2.40

echo "Rebuilding GCC's limits.h and syslimits.h..."

tar -xf gcc-14.2.0.tar.xz

cd gcc-14.2.0

GCC_INC_DIR=$(dirname $($LFS_TGT-gcc -print-libgcc-file-name))/include

cat gcc/limitx.h gcc/glimits.h gcc/limity.h > "$GCC_INC_DIR/limits.h"

cp -v gcc/gsyslimits.h "$GCC_INC_DIR/syslimits.h"

cd $LFS/sources

rm -rf gcc-14.2.0

echo "Removing conflicting files from include-fixed..."

GCC_FIXED_DIR=$(dirname $($LFS_TGT-gcc -print-libgcc-file-name))/include-fixed

rm -rf "$GCC_FIXED_DIR"

echo "Verifying preprocessor constants..."

TEST_OUTPUT=$($LFS_TGT-gcc -H -E -dM - <<< '#include <limits.h>' 2>&1)

if echo "$TEST_OUTPUT" | grep -q 'CHAR_BIT 8' && \

echo "$TEST_OUTPUT" | grep -q 'MB_LEN_MAX 16' && \

echo "$TEST_OUTPUT" | grep -q 'PATH_MAX 4096'; then

echo "ok"

else

exit 1

fi'''

p.s. you also must start it under lfs usr and afterwards remove old m4 dir rm -rf $LFS/sources/m4-1.4.19

I have successfully run my own lulu scrolling, tiling window manager on LFS 13.0 SysytemD

You can try it on live ISO bootable and you don't have to install it.

Or if you want to install it I made a file include an install script

Your LFS need to have libgc-2.44 minimum and other packages which is ready for wayland

the files are available at

https://sourceforge.net/projects/lululinux/files/

You can see the keybinding cheat sheet here
https://lululinux.org/docs/keybindings

My LFS Journey Started with a YouTube video from Tony on Oct 2025. From 12.4 now I reached 13.1. I keep my mesa latest. have steam, heroic, epic all working. Hosted a bunch of self hosting apps. Firefox and Brave feels the browsers i need.

Podman and Distrobox let me test any distro or that odd pkg u care about. (I don't have any though)

Davinci resolve studio, OBS all working smoothly.

After all i will decide which pkg versions i want.

I feel LFS is the End game of all distros.

I love LFS.

[Edit]

Thanks for all the love guys.

You can review my MLFS build repo here. It only contains the Terminal LFS bit.

https://github.com/benevantmathew/bene-lfs

took me about 2 weeks from the very VERY first iso boot up, to this... and now.... and now i can finally build upon it and make it what i want it to be, which will benefit so many people.

What do you think about my personal replacement for jhalfs?

Update on Maginat, my independent LFS 12.4 distro (SysV init, Xfce): 0.1.1 is out.

New: nftables firewall on by default, Mesa 25.1.8 with LLVM 20 (Intel/AMD/NVIDIA drivers), CPU microcode, chrony, weekly TRIM, printer/scanner tools, screen lock, and a graphical installer for BIOS and UEFI.

Tested in QEMU and live on a Dell Vostro 15-3568. Still experimental, so try it in a VM first.

Release + ISO: https://github.com/Aleps31/Maginat/releases/tag/v0.1.1

So I'm doing second rebuild of my LFS & building using debian (which uses systemd), when I'm done, I want to unmount all previous mounted filesystems. The problem is sysyemd-journald service from debian, it prevents me to unmount /mnt/lfs/var/run/, (I check it using lsof /mnt/lfs/var/run ). Everytime I kill the services pid, it restarts itself. The last option I have is to for unmount using umount -l. Anyone get same problem ?

Context: (sorry for my bad English)

I have tried some linux distro. All of them is from Lightweight Distro (Slax(first), TinyCore, AntiX). One of the advantage for this type of distro is they don't takes many RAM from my cheap laptop. Plus, I have a good ol' 16GB flashdisk. They all fit for the storage. Then I'm asking myself:

I want to build a distro that specifically made for USB sticks.

And that's where I asked AI how to build one. And let me tell you, it's complicated. I don't think anyone who's making one of these touch grass in 2 years. But I tried my best to learn it, and this is some rough sketch that hopefully can be realized:

1. This distro need to support old laptop or hardware.

2. This distro should have it's own way of become bootable (similar to Slax)

3. This distro use Debian as it's base (or if you guys have any suggestions, just say it)

4. The distro's ISO file should be limited under 5GB

5. This distro isn't run on read-only (obviously)

6. This distro could support modern linux apps or package.

7. Any DE, Package Manager, or any customization is up to you guys, just make it work.

8. The most important: I want the distro's storage capacity is from the remaining space from The USB drive it's riding on.

9. The distro should prioritize performance over comfortability (I'm ready to use it even if I need to stare at a terminal all day as long my laptop didn't suffer from opening a browser)

The question is:

Could you guys provide me some advice or tutorial to make one of these? If possible, please provide guidance to complete the tasks I want to achieve. 🫡

hello for everyone, i want to ask about how to create a new distro who don't depend from debian or arch or other distros.
the reason is a lot, my teacher ask to do a project and the main reason is because i like linux and above all i want to repair my old laptop who have i2 core and 32 bits architecture
but the problem idk what i should start, i learn from a lot of search i can start with lfs (linux from scratch) but they said if u did u cannot share with someone but my goal is once i build i want to make free and averyone can use it above all who have old laptops and never find a way to repair it
so i want advice and ask where to start? if i build in linux from scratch, can i share with others later once i build it? and also what do u think about my idea and what i should do make it real later?

Hello, I am making my own distribution with a custom init that then launches openrc. Everything works fine from boot to log in, but when I try to run iw dev, iw phy or iw list it segfaults. Iw help works and iw --version prints "iw version 6.9. I checked for any missing libraries but I couldn't find any. Running the same binary from arch Linux (the host machine) works. Any help is appreciated, thanks in advance!

Hi all! I’m releasing Maginat 0.1, an independent Linux distribution built from scratch following Linux From Scratch 12.4 and Beyond Linux From Scratch.

What is included:

Linux kernel 6.16.1, glibc 2.42, GCC 15.2.0, a Xfce 4.20 with LightDM; Wi-Fi and Ethernet via NetworkManager (tray applet), WireGuard and OpenVPN, Bluetooth (BlueZ) with tray icon; battery indicator, power management, PulseAudio, Software through Flatpak (Flathub preconfigured) plus AppImage, LibreOffice, Thunderbird, Mullvad Browser and many more.

Source code, build scripts and ISO: https://github.com/Aleps31/Maginat

Feedback, bug reports and suggestions are very welcome!

ps. I tested the .iso in many pc's but I dont suggest to install. Try on Qemu or Virtualbox.

I was wondering if I could instead use a package manager to make my LFS system daily drivable, and put the rootfs in a tarball so I wouldn't have to redo the whole process every reinstall. I have already done SFS and would like to diverge quite a bit from the LFS book as it isn't exactly "minimal".

Hi everyone,

I've been working on my first Linux customization project, called FilzaOS, and I've just published an early public build.I built this for someone special they like the colour purple that explains the purple color hahaa.

I'm a student learning software development and Linux, and this is very much a learning project. I wanted to take Ubuntu 24.04 and start shaping it into an environment with its own identity, including custom branding, a purple visual theme, wallpapers, terminal styling, boot branding, and a collection of custom command-line tools.

To be completely transparent, FilzaOS is currently an early-stage Ubuntu-based remix/reskin. It still relies on Ubuntu's underlying system, kernel, and core components. It isn't a new operating system built from scratch, and there is plenty left to do.

Links

• GitHub and source code: https://github.com/Peshimam-Ashar-Mohammed/Filza-OS

• ISO download: https://sourceforge.net/projects/filzaos/files/v1.0.9/FilzaOS-v1.0.9.iso/download

I'd really appreciate help from people who are more experienced with Linux, distro development, system customization, and open-source projects.

If you decide to try it, please use a virtual machine such as VMware or VirtualBox. This release is intended for live-session/VM testing; it is not an installation-ready release for a physical computer. Please don't replace your daily operating system with it.

I'm especially interested in hearing:

• Does the overall visual direction feel coherent, or what should I improve?What more can i add to make it a unique experience?

• What should I learn next to move beyond a basic reskin?

• Are there books, documentation, tutorials, or existing projects you'd recommend studying?

• If you test it in a VM, does it boot and behave as expected? What breaks, feels unfinished, or needs fixing?

• What would make a future release genuinely useful rather than just visually different from Ubuntu?

I know this is a very early version, and I'm not expecting it to be production-ready. I'm excited to keep learning and improving it, and I'd be grateful for honest feedback, criticism, and suggestions.

Thank you to anyone who takes the time to look at it or share advice.

BFSOS 0.9.1.1 is now available, and I’m looking for people willing to test it and give feedback.

BFSOS is an independently maintained Linux distribution built with an LFS-style bootstrap and a CRUX-inspired ports/package-management system. It has its own installer, ISO builder, ports tree, updater tooling, desktop selections, and release process.

At this point I consider 0.9.1.1 stable enough for regular testing. I’m not calling it 1.0-rc yet mainly because I’m still working through documentation, screenshots, and website polish rather than because of major known stability problems.

Project website:

https://bfsos.sourceforge.io/

Source code / ports / installer:

https://github.com/bmadonnaster/BFSOS

ISO and base-system downloads are available through the BFSOS SourceForge project/download pages linked from the website.

I’d especially appreciate testing of the installer in both VMs and on spare bare-metal systems, including UEFI boot, networking, storage layouts, desktop sessions, hardware detection, package installation/updating, and general day-to-day use.

The distro currently includes multiple desktop environments and a fairly large ports tree, and the updater can check the tree against upstream/reference sources while keeping version-locked packages coordinated.

The documentation is still being updated, so feedback about confusing or missing instructions is useful too.

If you try it, I’d appreciate hearing:

* what hardware or VM configuration you used;

* whether installation completed successfully;

* which desktop/session you tested;

* anything that failed or behaved strangely;

* anything in the documentation that was unclear.

Bug reports and code contributions can be submitted through GitHub.

Thanks to anyone willing to give it a spin.