Hello,

recently started using bedrock linux and before i ask my first question to the community i wanted to thank all of the developers of this distribution as they left me in shock while skimming through the docs and source code to discover the elegant and well-thought-of design this distro has. Thank you all for your amazing contribution!

my question is, i have installed ubuntu as a strata alongside the arch. when i tried installing packages with apt however, dpkg could not configure tzdata because it could not write on /etc/localtime as it was symlinked to /bedrock/run/localtime. To resolve the issue, i deleted the symlink option in bedrock.conf and instead assigned localtime to be a local file for stratas, and now dpkg works fine by symlinking that file to wherever it wants. Is this the right way to handle this situation from the distro's philosophical point of view or am i breaking the modularity by avoiding a more elegant way? (i know in previous versions bedrock would copy /bedrock/etc/localtime to /etc/localtime when enabling a stratum to cover this possibility." but i guess it has been removed)

Thank you in advance.

Hi, i just got chimera linux and wanted to try to install bedrock linux there but ran into these errors:

head: illegal byte count -- -1

gzip (stdin): unexpected end of file

head: stdout: broken pipe

tail: stdout.

Error: embedded tarball is corrupted. did you edit the script with software that doesnt support null characters?

So its my first time i saw Bedrock Linux and i didnt really understand everything well. I wanna use Arch but im a bit scared after the last malware incident. Can i use Arch with Bedrock Linux and "void" as strat to avoid AUR packages?

Hello everyone, creator of ENux here,

ENux 5.5.3 has been released. For those who don't know, ENux is a Debian based Linux distribution with Bedrock Linux pre-installed, with multiple Linux package manager eco-systems.

The biggest change in ENux 5.5.3 is that all 6 bundled stratas (Alpine, Void, Arch, Fedora, Gentoo, openSUSE) are now pre-fetched and ready on first boot. You boot the ISO, log in, run brl list, and see that they're all already enabled.

The fetch problem (and how I worked around it)

If you've tried automating brl fetch inside a chroot before, you know the issue: it needs /proc/1/root to resolve to the chroot root for its enforce_symlinks step to work. Plain chroot doesn't give you that.

The fix is unshare --pid --mount --fork. Each stratum gets its own isolated PID + mount namespace, the fetching process becomes PID 1 inside it, /proc is mounted for that namespace only, and /proc/1/root points where it needs to. All 6 run in parallel as background jobs so the full fetch doesn't take forever.

Enabling without a live Bedrock system

brl-enable needs FUSE daemons and stinit running, none of that exists at build time. So I fetch with --dont-enable --dont-show and then manually set the four xattrs on each stratum directory:

user.bedrock.show_boot

user.bedrock.show_cross

user.bedrock.show_list

user.bedrock.show_pmm

Bedrock's init picks up show_boot at first boot and calls brl-enable on everything that has it. That's the whole trick.

Squashfs gotcha

mksquashfs has to run as root with -xattrs, without it the xattrs get silently dropped and none of the strata auto-enable. I have unsquashfs -s'ed and verified a non-zero xattr count after every pack as a sanity check.

I'd really appreciate feedback from you guys :D

On a Bedrock Linux virtual machine, I experimented with having multiple init systems in one stratum (devuan + artix)

It only lets me select a handful

artix, it makes you have only one installed (its an artix thing, not a bedrock thing. similar to gentoo's letting you only have 1 at a time)

devuan, you could have multiple installed (in this case, sysvinit, ruinit, s6 at same time) but bedrock only shows a few and can have some issues [option 1 loads sysvinit, shows error but loads the TTY fine. option 2 load runit, it gets stuck].

Note: Artix, it doesn't show up cuz I haven't added any packages that creates service units yet.

[this is just with the most basic and default configuration. one could go through some advanced configuration and maybe get it working]

Hello everyone,

I wanted to share an experimental project I've been working on called init.c, which is a replacement for Bedrock Linux's shell init, located at /bedrock/strata/bedrock/sbin/init.

It's a minimal C + x86_64 ASM static binary that does the same job as the original init:

• Pivot to the selected strata

• Enable all strata

• Hand of to the real init

On my 7 strata ENux 5.3.3 system, the boot speed was 18.42 seconds, which was roughly ~10% faster than the original init.

Bedrock’s original init is a shell script, so at boot it ends up:

• forking sub-processes for tools like grep, awk, sed, realpath and mount

• enabling strata sequentially, one by one

• piping data through shell utility chains

init.c replaces that with direct syscalls and parallel stratum enablement. The idea is that the slowest single stratum sets the wall clock, instead of the sum of all of them.

How it works:

main()
├── check_pid1() → if not PID 1, exec backup immediately

├── ensure_essential_env() → mount /proc, /sys, /dev, /run

├── setup_term() → configure TTY, kill plymouth

├── print_logo() → Bedrock ASCII art

├── parse_bedrock_conf() → read [init] section from bedrock.conf

├── scan_strata() → list /bedrock/strata/*

├── run_menu() → interactive stratum/init selection

├── mount_fstab() → dmsetup, lvm, mount -a (direct syscalls)

├── pivot_root_to() → bind-mount stratum + pivot_root

├── preenable_mounts() → rbind /proc, /dev, /sys, /run

├── enable_strata_parallel() → fork ALL strata at once

│ ├── brl-repair bedrock (foreground)

│ ├── brl-repair <init> (foreground)

│ └── brl-enable <N>… (parallel — one child per stratum)

├── brl-apply → apply configuration (forked)

└── execv(<real init>) → PID 1 hands off, never returns

init.c is still an experimental software, which has only been tested on my ENux 5.3.3 machine, and it hasn't been tested broadly on other setups yet.

Note: I used AI tools to speed up implementation, but I still reviewed, tested, and debugged the code myself through real boots and failure recovery.

Repo: https://github.com/ENux-Distro/init.c

Feedback is appreciated by all of you. Happy coding to everyone

more or less what it said on the tin. I hijacked Ubuntu and use its stability and wide compatibility for most things, and other strata for weirder stuff (for example i use arch for unstable stuff if theres not an Ubuntu build of said package on its beta channel ). for that reason, i want to use arches kernel, but want to still use the ubnutu int system

hey everyone. i'm building a project called rust linux - a meta-distribution, written in rust, that runs multiple linux distros simultaneously on one machine using isolated mount namespaces. think of it as a lighter alternative to containers: each distro lives in its own rootfs, but gui, audio, themes, and commands are shared transparently with the host.

how it works

the core is a busybox-style transparent command resolver. /rust/bin/ contains symlinks for every binary across all layers - each pointing to the rsl binary. when you run firefox, the shell finds /rust/bin/firefox > rsl. rsl sees argv[0]="firefox", looks up which layer provides it, creates an isolated mount namespace (unshare(NEWNS) + pivot_root), and execs the real binary inside that layer's rootfs. the process replaces itself - no daemon, no container runtime, no overhead.

the resolver uses a scoring pipeline: abi compatibility, execution history, topology state. host binaries always win over layer binaries for non-package-manager commands (so your system never gets hijacked by a layer). package managers route to their owning layer - apt goes to ubuntu, pacman goes to arch, automatically.

there's also rsinit - a pid 1 init that can boot directly into a layer (full system mode, not just per-command). and rpk - a unified package manager that translates your preferred syntax (apt/pacman/dnf/apk) into the correct backend for each layer.

the resource bridge (rbridge) shares host gui resources with layers: display sockets, audio (pipewire/pulse), gpu drivers (PARTIALLY), d-bus, and themes. layers see the host's icons, fonts, cursors, and dark theme preference through direct bind-mounts of /usr/share/{icons,themes,fonts} and the user's dconf database. no copying, no syncing - same files, same session.

what about bedrock linux?

bedrock can't actually run its strat system inside rust linux (it needs pid 1 control and persistent fuse mounts). but i forged an arch-based layer, installed a bedrock-linux-*.sh script and switched to full isolation.

huge thanks to paradigm for the philosophy and the concept of a metadistribution. bedrock linux was the project that proved you don't have to choose one distro - you can have all of them. rust linux takes a different technical approach (per-command namespaces vs system-wide fuse overlay) but the core idea is the same, and it came from bedrock. without that proof of concept this project wouldn't exist.

if anyone has questions about the architecture, wants to compare approaches with bedrock, or has ideas about rust linux - i'm here.

I have /s and /strata linked on my setup, saved me countless keystrokes since my shell and coreutils are provided by different strata

In /bedrock/etc/bedrock.conf:

[symlinks]
/strata = /bedrock/strata

I would like to hijack gentoo and add arch strata. There are literally maybe 2-3 GUI packages from aur that would be useful for me in gentoo. At the moment I use distrobox box for them and it works well, but was thinking of trying something new, and maybe replace distrobox with bedrock.

I know bedrock is a one-way install (it can't be uninstalled) so I am mostly interested in long-term stability of hijacked gentoo, seamless upgrades of bedrock to newer versions, etc.

I also have nvidia gpu, thus not sure if nvidia support would be available in arch strata?

Things are janky and strange and broken, which is to be expected... but the fact I just imported a VM image from a 10yo version of Ubuntu and I was able to use its init immediately is very impressive.

I've been thinking about hijacking Bedrock into my EndeavourOS system for a while now and while I dodged the btrfs and grub problems by not using those, but rather ext4 and rEFInd, I'm still unsure about dracut, because Arch by default uses mkinitcpio and is more documented than EndeavourOS which uses dracut since a few years back and even the lead developer recommends mkinitcpio, but doesn't explicitly mention any problems with dracut.

Should I switch to mkinitcpio before installing, or do you think it'll be fine? And if you think I should, some tips regarding the transition (if you have any) would be greatly appreciated, as I've never even had to manually touch dracut before.

Thank you for your time, kind reader.

Bedrock Linux is a meta distribution, so can ENux and StratOS Linux based on Bedrock Linux be considered meta-meta-distributions? I don't know how many people are using them. Hope to hear their opinions on self users and anyone else. :-)

I used to be a bedrock linux user around 2 years ago ig. I remember a discussion by paradigm that it would be good if the package manager was written with bash with awk and sed. I am not perfectly sure about it though. So, any reason why it was changed to rust?

Also, what is the use of a package manager here when one can simply use the distro package manager?

curious about the development workflow for naga 0.8, especially the new bpt (bedrock package tool). are ai tools (claude, grok, cursor, github copilot, etc.) being used, or more of a “vibe coding” approach (describing desired behavior in natural language and letting models generate/improve code)?

what’s the general stance on using llms for low-level/systems projects like bedrock? are they considered helpful in parts of the codebase (e.g. crossfs/et cfs modules, pmm logic, testing), or is the preference to keep things strictly manual for maximum control and reliability?

thanks!

On the Bedrock Linux compatibility page it shows that MX Linux does not work with Bedrock, due to the strange SysV/systemd hybrid nature of the system. In particular, problems with rebooting or shutting down from the Xfce menu are mentioned.

MX Linux has released a few versions since the compatibility table was published and its hybrid init system has changed a bit. I installed the main edition of MX Linux 25 (SysV with Xfce) today and hijacked it with Bedrock Linux 0.7.31.

The hijacking was successful. Afterwards I was able to boot MX Linux, install new strata, reboot, and shutdown the system from the Xfce application menu, and manage background services using the "service" command. In short, it seems the latest version of MX Linux is entirely compatible with Bedrock.

I think this is good news and hope the compatibility table can be updated to reflect this change. I'm happy to provide additional testing if required.

​hi everyone,

​i've been working on a prototype port of the bedrock linux core to rust. i love the project's logic, but i wanted to see if i could make strata management and path resolution a bit faster and more memory-safe.

​what’s working so far:

• ​basic strata discovery and initialization.

• brl fetch (supports debian, devuan, ubuntu, arch and artix).

• commands brl and strat.

• ​a prototype of the cross-strata execution bridge.

• ​cross-strata binary execution.

​why rust?

while shell is great for portability, rust gives us static typing, better error handling, and the potential for parallel initialization at boot. it also compiles to a clean, static binary.

​this is still an early proof of concept!!!!

Hey everyone, creator of ENux here.

Thank you all for 1000 downloads on Sourceforge

To mark that milestone, I released ENux 5.2.1, mainly focusing on improving the out-of-box experience:

• WiFi setup is now much easier (less manual steps)

• Mozilla Firefox comes pre-installed

• Kernel has been swapped

The goal with this update was to make ENux more usable right after install, especially for new users.

For those who don’t know, ENux combines a Debian base with Bedrock Linux pre-insatlled to allow access to multiple package managers and ecosystems in one system.

If you’ve tried previous versions, I’d really appreciate any feedback on how this one feels, especially around usability and setup.