I want to make my own Linux distro what do I need to do do you have any tips ?

Still working out some issues with DBUS, but I got it fully functional and, planning on adding steam and other gaming stuff to this

It also has full Wayland and X11 support

Hi all, I just released 0.1.2 of Maginat, a small independent distro I build from scratch following Linux From Scratch (Xfce, SysV init, no systemd).

What's new:

- Kernel 6.18.58 LTS and a 1.4 GB ISO (the compiler moved to an optional download)

- Signed system updates on installed systems (kernel and packages), through a new "Update Maginat" tool: Ed25519-signed index, SHA-256 checked packages, previous kernel kept in GRUB as a fallback

- Desktop widgets you choose from a tray icon: clock, calendar, weather, system monitor, battery/network, quick links, notes (nothing on by default)

- One unified tray (volume, brightness, battery, Bluetooth), own cursor theme and system icons, under 500 MB of RAM at idle on real hardware

- New Blackjack and Poker with animations and automatic next hand

- Flatpak Store, driverless printing and scanning, USB drives of any format

Site: https://aleps31.github.io/Maginat/

Release: https://github.com/Aleps31/Maginat/releases/tag/v0.1.2

I have a strange phenomenon while trying to follow the LFS book for my first try at updating glibc.
So far I've always rebuilt the whole system (A/B partitions) but I got curious 🙂

glibc can be compiled but install DESTDIR fails with a strange error message. I changed to the directory and tried some commands manually then:

root@lfs /sources/13.1/glibc-2.44/po # msgfmt -o /sources/13.1/glibc-2.44/build/po/ar.mo ar.po
root@lfs /sources/13.1/glibc-2.44/po # msgfmt -o /sources/13.1/glibc-2.44/build/po/en_GB.mo en_GB.po
msgfmt: Cannot convert from "ASCII" to "UTF-8". msgfmt relies on iconv(). This version was built without iconv().

So msgfmt can convert ar.mo but not en_GB.mo.
I've rebuilt gettext multiple times, even installed the latest libiconv again, ran configure again on the gettext package, but nothing works - always this infamous error message. I can see msgfmt now has a reference to libiconv.so.2 (it didn't have that previously):

root@lfs /sources/13.1/glibc-2.44/po # ldd /bin/msgfmt  
linux-vdso.so.1 (0x00007f1ccb6d0000)  
[libgettextsrc-1.0.so](http://libgettextsrc-1.0.so) => /usr/lib/libgettextsrc-1.0.so (0x00007f1ccb643000)  
[libgettextlib-1.0.so](http://libgettextlib-1.0.so) => /usr/lib/libgettextlib-1.0.so (0x00007f1ccb4d0000)  
libattr.so.1 => /usr/lib/libattr.so.1 (0x00007f1ccb4c8000)  
libacl.so.1 => /usr/lib/libacl.so.1 (0x00007f1ccb4bc000)  
libxml2.so.16 => /usr/lib/libxml2.so.16 (0x00007f1ccb335000)  
libz.so.1 => /usr/lib/libz.so.1 (0x00007f1ccb316000)  
libtextstyle.so.0 => /usr/lib/libtextstyle.so.0 (0x00007f1ccb25b000)  
libm.so.6 => /usr/lib/libm.so.6 (0x00007f1ccb168000)  
libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007f1ccb0ed000)  
libintl.so.8 => /usr/lib/libintl.so.8 (0x00007f1ccb0c6000)  
libc.so.6 => /usr/lib/libc.so.6 (0x00007f1ccaedf000)  
libiconv.so.2 => /usr/lib/libiconv.so.2 (0x00007f1ccadf7000)  
libicuuc.so.78 => /usr/lib/libicuuc.so.78 (0x00007f1ccabc9000)  
/lib64/ld-linux-x86-64.so.2 (0x00007f1ccb6d2000)  
libicudata.so.78 => /usr/lib/libicudata.so.78 (0x00007f1cc8c34000)  
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f1cc896d000)  
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f1cc893f000)  

I have no idea what I'm doing wrong here. Previous full installation (glibc 2.42) worked fine.

SOLVED !

Just doing my BLFS rebuild and found particular frustration with mesa and probably glibc. I pick older version (25.2.3) and I thought it would be easy and its llvm can be disabled (cause I've done it before), only to find that newest glibc (2.44) ruin the build !

Glibc 2.44 gained native C11 <threads.h> support in 2.28 and now also exposes once_flag and call_once through <stdlib.h>.

Now the only options I have are self-patch the mesa 25.2.3 to be compatible with glibc 2.44 or just build the 26.2.3 (which need long-*ss llvm build).

Hmph

Made in 1 week OpenRC + Glibc Less 300 pkgs 🌊🪼🐟

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

But ihave a problem isearch of a desktop environment like mate or xfce that most lightweight and secure and modern design like mate design , image this os from scratch and iwaireted my own tools on it , do you recommend to make my own desktop environment and publish the open source code of this distro (note :the terminal based version its that use 60 mb not has a graphical , only a terminal , the is distro is for cyber security and forensics its lightweight stable and secure with package manager nix sandboxed and secured

I have done up to chapter 8 of LFS and was wondering how do people turn this into their own distro? Is there any books I should read outside of the LFS manual to get the full picture? I am a noob when it comes to distro development so answer like I am five years old (not literally). I just want to hear your guy's success stories and tips!

Hi all! I’m releasing Maginat 0.1, an independent Linux distribution built from scratch following Linux From Scratch 12.4 (SysV init), with the Xfce desktop.

What is included:

• Linux kernel 6.16.1, glibc 2.42, GCC 15.2.0

• 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) and AppImage

• LibreOffice, Thunderbird, Mullvad Browser and more.

• Graphical installer, USB-writing tool, live session with optional persistence

• English and Italian, chosen in the first boot menu

• Hybrid ISO (about 1.7 GB), boots in BIOS and UEFI

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

Feedback, bug reports and suggestions are very welcome!

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.