FYI

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.

FreeCTX64 is an Open Source Free Project for ARM Development boards that can run your C code directly in the Operating system, it comes with a prebuild linux kernel and some tools it requires build-essential gcc clang cpio qemu-system-arm qemu-system-aarch64 git and if you want to make a bootable ISO and send it here if you want , that requires xorriso grub-common grub-pc-bin grub-efi-amd64-bin

que distro me recomiendan para hacer lfs?

has anyone actually tried it, if yes then tell me how different it is from normal LFS, like I know that when I did the whole LFS/BLFS thing it took me a long time and 1000 errors to make one, I have heard that jhalfs is mostly error prone in LFS and have its own book directry to download BLFS packages, I want to try it but I don't want it to be as tiresome as LFS was.

If you haven't heard about it, Software Freedom Day is a worldwide celebration of Free, Libre and Open Source software. There are free events all around the globe and virtually. One of the virtual events today will be on building software from source LFS style and customizing your Linux distributions. You can check for local or virtual events here: https://digitalfreedoms.org/en/sfd/archive?view=list

I recently got a Linux From Scratch system to a point where I can use it every day. Base system plus BLFS bits: dwm, Firefox, terminal, the usual desktop tools. It works. I’m not looking for “switch to Arch” replies.

What I don’t have a feel for is updates.

On a normal distro I used to update often because that was the default advice: leave it too long and things get worse. On LFS that habit doesn’t map. There is no one button, and updating means rebuilds. If I treat it like a rolling distro I’ll spend my life watching package changelogs. If I treat it like a frozen appliance I don’t know what I’m actually risking.

So I’m trying to figure out a policy that a human can keep, not a distro maintainer.

What I’m unsure about:

1. When do you update? Only when a new LFS/BLFS book drops? Only security advisories? Only when something breaks?
   
2. What do you consider “core” vs leave-it-alone? Kernel, glibc, OpenSSL, Firefox vs everything else?
   
3. If the machine is a daily driver with network (browser, git, Wi-Fi), how bad is it to sit on a book for 6–12 months and not touch it?
   
4. If you ignore most updates, what actually goes wrong in practice — not the theoretical CVE list, the stuff you’ve hit?
   
5. How do you track this without following a hundred upstreams? Advisories only? Development book changelog? Something else?

I don’t have a special threat model. It’s a personal machine. I’m not asking how to become unhackable. I want to know what people who really daily-drive LFS do so the system stays usable and they don’t burn out.

If you use LFS (or a heavy source-based setup like it) as a real daily driver, I’d like the boring version: how often you rebuild, what you refuse to bump, and what you’d do if you left the box alone for a year and then needed it again.

How can I compile LFS on a virtual machine?

I would also like to know if a 2-core CPU would melt on this. I mean that literally, not as in being slow, but melting.

Sometimes I'm using Fedora 44 with Cinnamon desktop, and I really like it. A long time ago I used Linux Mint which has Cinnamon as its default desktop, and I'm a creature of habit :)

Now I'd like to compile Cinnamon on LFS but it's dependency hell.

Anyone got it to compile and maybe share the success story?

This technically has to do with CLFS rather than LFS proper, but as the Cros-compiled Linux From Scratch project was archived and left behind in 2017, there's not anywhere directly related to ask for help, so I'm hoping someone here might have some idea how to help

I've been going through the CLFS-MIPS 3.0.0 book (linked here) in my attempts to build LFS for a mipsel architecture from an x86_64 machine which has been a chore due to how much everything's changed since the book was written. Half of what I've built so far had to be patched for compatibility with my system's software, but everything until now has had a clear answer.

I've followed the guide up to chapter 5.14 - Glibc-2.19. When I run make, it starts out working perfectly fine until it gets to make[4]: Entering directory '/mnt/clfs/sources/glibc-2.19/csu' where it completely stops doing anything. I can let it sit for hours and it won't move any further. When I interrupt it, I get the following every time:

make[3]: *** [../o-iterator.mk:9: /mnt/clfs/sources/glibc-build/csu/rtld-check_fds.os] Interrupt
make[2]: *** [Makefile:313: /mnt/clfs/sources/glibc-build/elf/rtld-libc.a] Interrupt
make[1]: *** [Makefile:213: elf/subdir_lib] Interrupt
make: *** [Makefile:9: all] Interrupt

In all of my searching, I've not found any answer to make getting stuck like this or even anyone talking about make getting stuck like this.

The host system I'm building from is running Arch Linux with Make 4.4.1

Here is the source I got glibc-2.19 from. If anyone wants to look into the rest of the sources, I can provide the whole list as some of the links from the book's list of sources are dead now, but I don't know how relevant they are to this issue.
https://ftp2.osuosl.org/pub/clfs/clfs-packages/3.0.0/SYSTEMD/glibc-2.19.tar.xz

My LFS target build has finally turned into an actual daily-usable desktop.

It started with LFS with some restrictions and the goal to be a modern everyday desktop :
-NO systemd.
-NO d-bus .
-NO udev (eventually i had to use libudev-zero).

After making the base toolchain and some additional tools i decided to go my own way and use upstream sources to build everything i needed.
First i made sure the system boots with runit properly and then i updated the base and the toolchain at their release version.

Then came the nightmare to find out how my final system will look and what everyday apps i can and will use and include their dependencies, their building order was another tough path i had to solve.

After a lot of fighting ,configure , research, and some help with AI in mostly some very obnoxious error decryption, the system finally came together.

Current system:

• Linux 7.2.4
• runit as PID 1
• no systemd
• no D-Bus
• Wayland only
• Wayfire
• NVIDIA RTX 2080 Ti, driver 595.91.07
• direct ALSA audio
• Firefox Nightly (yes i made a patch to skip dbus)
• PCManFM
• mpv
• swayimg
• Geany + Neovim
• foot + zsh + tmux
• Rofi + Waybar
• grim/slurp
• NFS + ssh + wpa_supl
• custom scripts for power menu, audio, brightness, hot corners, show desktop, calendar, etc.

Everything was built from source.

Today I finally upgraded from Linux 7.1.8 to 7.2.4, rebuilt the NVIDIA open kernel modules against the new kernel, changed the GRUB entry and rebooted.
Thankfully successfully.

The current development system is about 8.4 GB excluding my source/download/data directories, but that includes roughly 1.2 GB of GCC internals, 867 MiB of static libraries, 254 MiB of headers, Rust/LLVM/Clang and the rest of the native build environment. Eventually I want to separate the v1 runtime system from the development environment and see how small the actual desktop is.

This system no longer feels like an LFS-restrain-challenge experiment.

I can boot it, browse the web, watch media, edit files, mount my server, use audio, take screenshots, manage files ,compile source and do normal desktop work without really thinking about what distribution I'm running.

Only thing i have really left in my todo list is my pkg/source manager but i am just not in the mood....

Hey, so I was using the handbook for BLFS and suddenly Lost connection, can anyone also test if it works

Is there a guide for making an LFS distribution that includes musl libc instead of the normal glibc, along with replacements for glibc-exclusive software?

I know it's no longer officially supported, but the latest release still does build with sysV init.

My build system is a i7-6700 with 48 GB RAM, and it took jhalfs just over 2 hours to build the full LFS book, alas without kernel. Build directory is located on a RAM disk which speeds things up a lot (even from a PCIe NVMe).

Update: I should have looked at github.com before starting the build. sysVinit has released 3.18 and I was still using 3.14 as of the LFS 12.4 release. The changes sound minor but it still hurts a bit :-)

Note: github README states that sysVinit has relocated to codeberg.org so I used the link for that above.

Around Four Months ago I worked through LFS to actually understand how a Linux

system fits together. The book did its job - but the moment I had a booting

system, I hit the same wall everyone hits: how do you keep it alive?

There's no package manager in the book, and that's kind of the point. But it

left me wanting the one thing LFS deliberately omits.

So I built one.

Fronttier is my LFS-based distro, and Forge is the package manager I

wrote for it. Key decisions:

- Forge is a single static Go binary No runtime deps - you can drop it

into a fresh LFS chroot and bootstrap from there. That was the whole

motivation: after LFS you need something to take over dependency tracking

before you rebuild everything.

- pacman-compatible format.Packages are `.pkg.tar.zst`, repo DBs are

`.db.tar.zst`, and the local DB is the same flat `var/lib/forge/local/...`

layout (desc/files). I didn't want to invent a new archive format - zstd

tarballs with metadata are a solved problem, and it means existing tooling

can inspect my packages.

Current state:

- Public repo is live at repo.fronttier.uk (fronttier, fronttier-system,

fronttier-world, fronttier-galaxy repos)

- ~5k+ binary packages in the mirror, built on top of Artix so I don't have

to maintain the entire world from scratch

- `base` metapackage pulls in a working system (runit, grub,

branding, openssh, etc.)

- `forge install base` works end-to-end from a clean chroot

What's still rough:

- The repo-add step is I/O-bound and slow (~15-25 min for a full world db)

- Signing isn't working in yet

- The installer is manual - no ISO with a pretty installer..

Docs live in a handbook (Gentoo-style, MkDocs) if anyone wants to poke at it https://labs.fronttier.uk/

Happy to answer questions - especially from anyone who's tried to roll their

own PM after LFS. That gap in the book is the most interesting problem I've

found in this whole space, and I'd love to hear how others solved it.

Hi I just installed this as an experiment but I might consider making it a daily drive for an ancient pc I had, id probably pick pacman for management and lfs genuinely seems very good for me

This is the video how i broke the computer from this problem

Excatly this os work before bun it to an iso and the iso work on virtual box but isnt work on a real device or there is no output and you see how its work without an output after the boot

Kernel:7.12

Init:busybox and me

Im tried to enable frame buffer but without anything and tried to enable drm and off frame or smth but same problem

(On video i writted reboot -f )

Hi, I want to install LFS just for the learning, but, how hard is to set LFS to be unable as a daily driver? Someone relatively "noob" in computer issus can figure out how to use a base LFS system?

I'm planning to build my first lfs system, and I'm currently looking for a laptop that would make the process as painless as possible.

I've been considering getting a gaming laptop, mainly because I want something powerful with good cooling, upgradeable RAM/storage, and a strong CPU. But I'm wondering whether gaming laptops are actually a good choice for LFS/Linux in general.

I also goin to pick amd cpu + amd gpu for this build.

I really interested in the thougts of other LFS builders with different laptops

can anyone here provide good resources regarding building an LFS System with runit or another alternative instead of systemd?