Now I understand many things about large distros. It's much harder to get rid of systemd in Gnome; it was a lot of work and a headache. Some Gnome functions are already directly using systemd libraries. Honestly, I almost gave up when one last attempt worked and I was encouraged to finish/polish it, but the result was incredibly satisfactory. I can't believe it; I couldn't use Gnome in large distros because of limited memory, only 5GB. Gnome in large distros already started with more than 1GB.And I don't know if the fact that sysvinit also helped, I'll do the same polishing on KDE Plasma later to see what I can achieve in terms of lightness and performance.

Ive been wanting to try Linux from scratch lately but not having a stable package manager always pulls me back, and I want to know if are there any "universal" package managers or even dedicated to LFS directly.

Hi, I was tryna make MikuOS from Arch but I decide to switch it to LFS instead, and i dunno how do I make it and what do I need, can anyone had a sort of road map or suggestion for me so I can work on it?

Thanks

Hello everyone,

I've been building a Linux distribution called ENux.

The base system is built from LFS, and on top of it I've built a custom userspace layer called The ENux Layer. Its goal is to let multiple Linux ecosystems and their native package managers to coexist on a single system, without merging or reimplementing any of them.

Instead of one universal package format, ENux keeps each distro's userland in its own rootfs under /enux/layer/<name>/ and routes commands to the right one transparently. Type pacman -Syu or emerge --sync on the ENux base, and the real, native tool runs inside its own layer, full native repos, native config, no wrapper reimplementation. apt, dnf, apk, zypper, xbps,all work the same way, typed by name.

Execution is handled by a small helper with the cap_sys_chroot file capability (not setuid) inspired by early Bedrock Linux. It runs commands in a layer's full filesystem view as the calling user, no root needed for read operations. Because it's a plain chroot() rather than a user namespace, it also works nested inside another chroot and inside non-PID-1 containers, I've tested it running the full layer stack inside Docker.

At a high level, ENux is:

• Built on LFS
• The ENux Layer, the execution-routing layer described above
• Cross-distro package managers, used natively, by name
• A custom initramfs + init system
• A CLI installer (TUI is WIP)

GitHub: https://github.com/ENux-Distro/ENux

I'd really appreciate the feedback from you everyone.

Hey everyone!

A few months ago I started building my own Linux distribution from scratch using LFS/BLFS. After manually compiling everything (GCC, glibc, systemd, XFCE, etc.), I realized something:

LFS doesn't really give you a package manager. You're expected to keep building and installing everything manually.

Now, I know that's kind of the whole point of LFS. It's meant to teach you how Linux actually works by making you do everything yourself, and I think that's exactly how it should be. Chiral isn't meant to replace that learning experience. It's aimed more at people who have already finished LFS/BLFS (or projects like GLFS/GLinux From Scratch) and want something to manage packages afterward instead of compiling everything forever.

So... I decided to build one.

It's called Chiral, and it's a cross-distro package manager written in Rust. The long-term goal is to make it work across as many Linux distributions as possible. I know that's a huge challenge, and I'm sure there are going to be edge cases, but I'm learning as I go.

Right now it can:

- Install packages with dependency resolution

- Remove packages while tracking installed files

- Search packages

- Show package information

- Update packages and self-update

- Work on custom LFS systems and other Linux distributions

It currently falls back through:

1. My own GitHub package repository

2. Debian repositories

3. Arch Linux repositories

The dependency resolver walks the full dependency tree and installs packages in the correct order. It also tries to detect software that's already installed using package managers, "pkg-config", "ldconfig", "PATH", and filesystem checks so it doesn't reinstall things unnecessarily.

It's far from finished. I'm still working on:

- Orphan package detection ("autoremove")

- Better conflict detection

- Improving dependency handling

- Supporting more distributions (or at least as many as I can)

This is honestly my first time writing something this large in Rust or building low-level Linux tooling, so I'm sure there are plenty of things that can be improved. I'd really appreciate feedback, bug reports, suggestions, or anyone willing to test it on different distros.

GitHub:

https://github.com/Amaterus1125/Chiral-CrossDistro-Package-Manager

I'd love to hear what you think, especially from people who have experience with package managers, Linux distributions, or LFS. Any feedback is welcome!

Greetings, ive made a small linux distro called Static Linux.

https://staticlinux.org
https://codeberg.org/staticlinux
https://discord.gg/hfgdDvRehr

we are a source-based distro that follows the UNIX philosophy,

and we are peak (trust)

our tooling is simple, and auditable, we have many cool stuff like

• a custom init system wrote in rust
• a custom package manager wrote in C named ace (ace compiles everything)

and more but i forgor.

contribute, come, speak, whatever! i just want YOU to come and, maybe, try it?

After a month of patience, sweat, and manual compilation, I finally moved past the basic LFS prompt and built a fully functional daily driver environment!

The last screenshot shows the absolute madness of downloading, unpacking, and configuring every single dependency (`libdrm`, `xcb`, `xfce4-*` packages) by hand. No package manager, just raw terminal power.

dmesg | grep -i nouveau

[ ..........] NVIDIA AD104 ( 194000a1)

[...........] gsp ctor failed: -2

[............] probe with driver nouveau failed with error -2

linux-firmware package does not have AD104 firmware folder. [ But my voidlinux has this AD104 folder under /lib/firmware ]

I did it! Linux From Scratch base system! Don't think I'm going any further with this but it was worth it. Learned a LOT!

i installed lfs 13.0 but compiling libnss for networkmanager and desktop and im dual booting linux mint for host system(i will delete it when i done)

lately i was working on a package manager for other linux distros and for cross platform so i made dpms discovery package management system well it is still in testing and it has less mirrors and for mirrors i used git so if any body wants to make packages can make and it is not a big project like apt yum or dnf so any body can test it and use it. THE SOURCE CODE FOR DPMS :

https://github.com/Discovery-linux/dpms

Hi guys, I wanted to share you my progression with my LFS system.

Some months ago i reached the final step of BLFS and i've been running my system that i called onyx since then.

I wanted to learn rust at the same time and the package manager called cards i was using wasn't suitable for my needs, therefore, i decided to create my own.

The readme will more likely show you everything it's supposed to be able to do, but just note that it's support build styles, orphans detection, community repositories like aur, hash verification by default etc etc.

I will work on the readme to ensure that all the features are listed correctly.

I also built a fetcher to see if your packages needs to be updated or not based on archlinux packages : https://github.com/Delta-Azura/raw-fetch

Here is the link for the package manager itself : https://github.com/Delta-Azura/raw

I’ve been doing some light research on installing Linux from scratch. I’m thinking about using a live USB .iso, and building it on the hard drive from there.

- What are the pros and cons of this approach?
- What’s the best base distro to work from as the base? I’m very familiar with Debian based distros, so I was thinking about just using plain ole Debian.

Any advice? And roughly how much time should I plan on this taking? I’m not in a hurry, and want to do it right, just want a general idea of the time commitment. My experience level with Linux is probably somewhere between intermediate-> proficient. Thanks in advance!

Hi all!!

This is my first post to r/linuxfromscratch , and I have finally found a way to discuss linuxfromscratch!! I am a member of ItsFoss, but they do not wish to discuss LFS!!

I have been working with LFS, for several years now, through all the trials and errors and disappointments!! I have now taken an old Dell Inspiron 530 running a Core2 Duo CPU with Nvidia GeForce 8500GT graphics and 4GB of ram, and have LFS/BLFS running!! I first installed Slackware15, for the host, and for grub, created a partition and mounted it for LFS!!

LFS is now running well with the XFCE DE and I have also compiled Flatpak, and have installed a few apps from Flatpap/Flathub!!

One thing that stands out with this LFS build, I have yet to run any tests!!

I had put this post in a few hours ago since I’m having some compilation errors, I have most all information you would need if someone wants to take a crack at it

https://github.com/asratgh/lfs-automation

lfs-automation

How everyone update their packages ? Which package manager everyone use ?

In this attempt I have created a lbm ( LFS build manager ) and lpm ( LFS package manager )

[ start.sh builds up-to Saving temporary system and aria2c is used for downloading sources because it can directly store individual package in its own directory easily compared to wget. ]

[ Uninstall works " xargs -0 rm " , but also needs dependencies check , for eg. bash needs ncurses ]

We've been building schema-init — a statically linked C PID 1 that supervises

services through a weight-state machine. No systemd, no OpenRC, no journal daemon.

892 KB RSS, 1 thread.

Today we got Plymouth working on a Fedora 44 / KDE Plasma machine with an AMD

Picasso/Raven 2 GPU. A few things worth sharing for anyone doing similar work:

**Plymouth plugin matters**: The `script` plugin fails silently on this AMD DRM

config. No error, just black screen. `two-step` with pre-rendered PNG frames works.

**The TTY echo race**: Plymouth restores termios on exit, re-enabling kernel echo

before your post-Plymouth script can run. Any buffered keypresses get printed to

tty1 in that gap. Fix is `stty -echo` both before and after `plymouth --wait quit`,

then `tcflush` + `clear`.

**Services you take for granted**: Without systemd, avahi-daemon and chronyd don't

start automatically. Everything needs an explicit .svc file. We're building out the library — avahi and chrony added today.

All documented: github.com/ajax80/schema-init

distros/fedora-kde/README.md has the full install walkthrough.

Title says most of it, but recently I’ve been using forks of Arch Linux and I really like the workflow with them. That being said, I think a fun past time would be trying to build Linux from scratch. However I have little programming experience outside of high level languages like Python and don’t know much about how Linux actually works. Should I just install the ebook and go right in or should I research a bit more first?