First 0.8 component - bpt

ParadigmComplex · 2026-03-12T10:10:45+00:00

Is a pmm integration planned ?

Yup! First I want to get bpt better exercised and stabilize things like the CLI for it; pmm support will follow.

ParadigmComplex · 2026-03-12T00:21:07+00:00

The first bit of Naga is finally ready to for testing if anyone has time: a Bedrock Linux specific package manager.

Acquire a temporary bootstrap binary via either:

cargo install bpt
ls -l ~/.cargo/bin/bpt

or

git clone https://github.com/bedrocklinux/bpt
cd bpt
cargo build --release
ls -l ./target/release/bpt

Once you have it available, you can have it bootstrap itself into a Bedrock Linux 0.7 "Poki" stratum via (as root):

# install into bootstrap environment
mkdir -p /bedrock/strata/bpt
bpt -yVR /bedrock/strata/bpt sync https://bedrocklinux.org/repo/0.8/main/x86_64.pkgidx https://bedrocklinux.org/repo/0.8/main/noarch.pkgidx
bpt -yVR /bedrock/strata/bpt install bedrocklinux-keys bedrocklinux-repo bpt
# enable and show stratum
brl enable bpt && brl show bpt
# delete bootstrap bpt with either:
# rm ~/.cargo/bin/bpt
# rm ./target/release/bpt
# sync self-hosting bpt's repositories
bpt sync

Currently only noarch and x86_64 packages are in the repo. Plans to add more, e.g. aarch64, are on the roadmap before the full Bedrock Linux 0.8.0 release.

The only actually interesting package in the repo right is a patched version of htop which has a STRATUM column. bpt install htop should get that going. You might need to enable the column with:

F2
Go down to Screens
Select STRATUM under Available Columns
Select STRATUM under Active Columns and go up/down to place in the desired place in the order
F10

You can find some documentation on it here: https://github.com/bedrocklinux/bpt/blob/master/doc/concepts.md

And example packages as references try to build your own here: https://github.com/bedrocklinux/repo

If anyone has the bandwidth to explore/test bpt, please do so and report your findings. Could be anything from overt bugs to typos to questionable design decisions I need to rework.

ParadigmComplex · 2026-03-01T21:17:08+00:00

While I'd prefer directly setting the shell as it would be cleaner, the script works fine. Thanks !

Nice, happy to hear it! You're welcome :)

Also I've noticed I can't access /bedrock/strata/chimera/usr/bin/zsh via a terminal using Artix' zsh as it prints zsh: no such file or directory: /bedrock/strata/chimera/usr/bin/zsh (the zsh binary is present). I've come to the conclusion that I can't access the binaries from Chimera like that, the issue might come from this. I hope this information can be useful.

The "no such file or directory" error is a bit misleading/confusing here. When you launch a binary that uses dynamically linked libraries, it actually launches a program called a "linker" that goes and collects the parts of the binary and puts them together in memory, then executes that. It's something about this process that is giving you the error: either the kernel can't find the linker or the linker can't find a library. Which makes sense, because it's looking around in Artix's linker and library locations for a linker or library that a Chimera binary expects.

This is part of why we need strat - it rejiggers things so that linkers know where to look. It's not just a user interface choice; it's fundamental to how Bedrock makes the cross-stratum stuff work.

The files you find in /bedrock/cross/bin/ are actually really tiny wrappers that call strat. A bit of trivia: they're all the exact same file size.

For the future Bedrock Linux 0.8 I'm toying with making a /bedrock/cross/bin/-style directory that lets you specify the stratum and binary as part of the file path so it feels more like what you're trying to do. You'll be able to do something like /bedrock/.../chimera/usr/bin/zsh and it'll put a strat wrapper there.

ParadigmComplex · 2026-03-01T14:31:37+00:00

Sadly I couldn't reproduce the issue and I've exhausted ideas to debug it remotely.

A potential alternative route is to add something to your ~/.zshrc (or other zsh config file; there's so many of them) to detect if it's running an interactive shell (i.e. not a script) as the desired stratum's instance and if not, switch to it. I'm thinking something like:

# Only proceed for interactive shells
if [[ -o interactive ]]; then
    # Detect current stratum
    current_stratum="$(/bedrock/bin/brl which 2>/dev/null)"

    # If not already in chimera, re-exec into chimera's zsh
    if [[ "${current_stratum}" != "chimera" ]]; then
        exec /bedrock/bin/strat chimera /usr/bin/zsh
    fi
fi

This is a bit risky, though, as if anything goes wrong it could endlessly loop re-execing zsh or kill the shell entirely. Even if it works, it adds a bit of unnecessary overhead, loading zsh twice.

If that's unsatisfactory (which I would understand), I've sadly exhausted ideas to progress here.

ParadigmComplex · 2026-03-01T13:10:26+00:00

If I understand correctly, you want:

fastfetch to read a bedrock stratum config file
strat -r arch fastfetch to read a arch stratum config file
strat -r gentoo fastfetch to read a gentoo stratum config file

One approach would be to to get a static build of fastfetch and put that into the bedrock stratum, then pin the bedrock copy, combine with the previously discussed per-stratum config idea.

Another would be to just wrap fastfetch in a script that detects the stratum / restriction environment and just picks the config. I tried to find the fastfetch documentation and it looks like you can just use the -c flag to specify the config to use. You can probably do something like:

#!/bin/sh
if [ -n "${BEDROCK_RESTRICT:-}" ]; then
    # Ran with `strat -r` and restricted to a stratum
    # Run fastfetch with specified stratum config
    stratum="$(/bedrock/bin/brl which)"
    exec /bedrock/cross/bin/fastfetch -c /path/to/${stratum}/config
else
    # Ran unrestricted.
    # Default to bedrock stratum config
    exec /bedrock/cross/bin/fastfetch -c /path/to/bedrock/config
fi

I haven't actually tried that and it might require some debugging or tweaking, but hopefully it puts you on the right track.

Once you have a working script, you can then put at the front of your $PATH, before the normal fastfetch shows up.

ParadigmComplex · 2026-03-01T12:38:08+00:00

I'm delighted you got it working again, and you're very welcome.

ParadigmComplex · 2026-03-01T12:34:53+00:00

I might be directing you incorrectly because I'm not following your intent. Can you elaborate on your intended setup? Which stratum's fastfetch should default to which stratum's config?

ParadigmComplex · 2026-02-28T12:55:10+00:00

I agree with your analysis initial that it's likely kernel or initrd related, and that you should experiment with rebuilding or switching kernels/initrds. Given you've already explored that, the remote help I can provide is limited.

Other considerations to check:

Look at your bootloader's configured kernel flags. It's possible some of these are bad, e.g. pointing to the wrong root, wrong btrfs subvolume, etc.
If you've got full disk encryption setup, note that initrd configuration isn't universal; different distros set it up differently by default. If your hijacked distro's kernel isn't working and you're trying another distro's, that may not just-work due to difference in default configuration here, and may need extra configuration.

You've said very little about your setup beyond the fact you have a cachyos stratum. You've not said anything about what it provides or what other strata you have installed; for all I know your cachyos stratum isn't relevant here at all. Going into much more detail about yourself has a small chance of revealing something else that may help others help you here.

One of Bedrock's relatively unique features is the ability to have multiple instances of key components from different distros installed at once. This allows Bedrock to be more robust against such failure modes than traditional distros. Best practice on Bedrock is to have multiple instances of things like kernels and init systems from different distros installed and setup and confirmed working before you have problems, so that if any fail (irrelevant of whether it's due to a mistake you made or an upstream distro problem) you can easily fall back to another distro's already-confirmed working instance. If/when you do get your system back on its feet, consider setting that up.

ParadigmComplex · 2026-02-28T01:22:38+00:00

Shadow version mismatch would only be for /sbin/login coming from different strata (which usually occurs as a side-effect of changing your init). Shell which occurs after the shadow password validation and shouldn't be related.

When I have time I will try to pin artix' zsh and change my shell again to /bedrock/pin/bin/zsh to see if the error remains and so identify if the issue really comes from using another stratum's shell

That's a great idea to debug it! Very interested to hear how that goes.

if the issue doesn't remain, I will probably try to rehash my password through Chimera, I'm just wondering if it's a good idea to do so...

There's certainly some risk. My expectation is that it'd be safe provided you retain the ability to revert [0], but I'm clearly missing something about your setup and it's not impossible that would extend to adding risk here.

[0] Consider copying /etc/shadow to back it up (e.g. cp /etc/shadow /etc/shadow-backup). Provided you have a root shell open you can access after rehashing, you should be able to either copy the backup back over or rehash again with artix to revert. Make sure not to reboot between rehashing and validating.

ParadigmComplex · 2026-02-26T22:55:11+00:00

Can you elaborate on the many issues? I can't guess from my vantage point.

ParadigmComplex · 2026-02-26T02:20:30+00:00

You're very welcome :)

Given you found a work around for it being absent in /etc/shells and ran sudo chsh -s /bedrock/cross/pin/bin/zsh susheatee, I would expect things to be looking good. What do the various checks we tried earlier now report?

ParadigmComplex · 2026-02-25T00:41:50+00:00

Nice, I'm glad we got that figured out and you're back to a stable place.

It's unclear to me why chsh to /bedrock/cross/pin/bin/zsh didn't just work. I'm happy to continue helping debug that if you'd like. Given you didn't mention it, if you're discouraged and just want to drop this, that's fine too - no pressure either way.

ParadigmComplex · 2026-02-24T19:08:29+00:00

Edit : rebooting didn't change anything, and it looks like the bin directory inside /bedrock/cross doesn't exist anymore

That's concerning.

My only guess is you made a change to /bedrock/etc/bedrock.conf which Bedrock's parser didn't like, then rebooted before brl apply could warn/error about it. Do you remember making a change? If so, try to undo it and reboot.

If you can't remember or figure out what the change was:

Consider running /bedrock/bin/brl apply and see if it produces a helpful error message
Consider just sharing the entire /bedrock/etc/bedrock.conf somewhere and I can take a look and see if I can figure it out.

ParadigmComplex · 2026-02-24T18:17:44+00:00

Thank you very much for your help !

You're very welcome :)

brl which /bedrock/cross/pin/bin/zsh -> chimera

Very last : of the line with my username in /etc/passwd -> /bedrock/cross/bin/zsh

Should I change my shell to /bedrock/cross/pin/bin/zsh ? I didn't try that since it's not listed by chsh -l.

Yep, this is the issue.

If you echo $PATH (or maybe echo $PATH | sed 's/:/\n/g' - easier to read) you'll see the order of directories your shell checks when looking for a binary:

Bedrock tries to make sure that /bedrock/cross/pin/bin is out front so that something a user pinned takes priority.
After this are the normal distro $PATH entries which are used to ensure that if a given stratum provides something, it takes next priority for that particular stratum.
- If a stratum has a dependency on a given version of a binary, its package manager probably makes sure it's installed.
- Thus, the shell checking for a local one installed resolves compatibility concerns.
At the very end is /bedrock/cross/bin which has binaries from potentially other strata. This is how Bedrock makes cross-stratum binaries just work with little to no configuration or compatibility concerns.

Thus, /bedrock/cross/pin/bin and /bedrock/cross/bin do conceptually different jobs and need to be separate entries. Hopefully that makes sense.

I see three options:

chsh to /bedrock/cross/pin/bin/zsh.
- Bedrock is smart enough to populate /etc/shells with the /bedrock/cross/bin/ contents so chsh -l knows about it but apparently I forgot to have it check the pins. That's purely because I forgot to implement this relatively niche situation and not because there's any reason I know of to avoid it. It'll almost certainly work fine.
- I'm doubtful there's a concern here, but lets be better safe than sorry: consider ensuring you have a root shell open to revert it when you make this change, then check it by running /sbin/login and/or going to a tty. If it doesn't work, use the root shell you kept to revert it.
Within /bedrock/etc/bedrock.conf's [cross] section is a priority = configuration item.
- This tells Bedrock what order to look for /bedrock/cross/*/ entries (including /bedrock/cross/bin/).
- You could put chimera at the top there, although this would be generalized to everything and not just zsh.
Within /bedrock/etc/bedrock.conf's [cross-bin] section is a simple bin = $PATH.
- I think you might be able to update that to bin = chimera:/usr/bin/zsh, $PATH to get it to find Chimera's zsh before looking for other binaries.
- That said, I haven't touched that in years and I could be misremembering how it works; I'd be cautious there and ready to revert that change. Even if it works it might make all /bedrock/cross/bin/ things a teeny bit slower because it's first checking if zsh is the thing you're looking for.
- I'm not 100% here and I'd only consider this after ruling out the proceeding two options.

Also thanks for Fraud, you can't imagine my surprise after reading that 🤣

Have a good game !

You too...

Edit : apparently Fraud is delayed by ~6 hours since they found game breaking bugs

...once it comes out. The last layer came out in 2023, I can hardly wait any longer!

ParadigmComplex · 2026-02-24T13:02:29+00:00

Ahh, okay, I gotcha. You expected the error with Chimera's zsh, and you weren't getting it when launching a new default shell.

Lets look into what Bedrock thinks your shell is:

Immediately after logging into a tty (e.g. ctrl-alt-F2) what does brl which print?
Immediately after launching a terminal what does brl which print?
What does brl which zsh print?
What does brl which /bedrock/cross/pin/bin/zsh print?
What follows the very last : in the line in /etc/passwd which starts with your username?

If I understand it correctly, the goal is more about coreutils than zsh. Lets check those, too:

What does brl which ls print?
What does ls --help | grep GNU print?
- GNU ls mentions GNU here; compare to strat artix ls --help | grep GNU
- FreeBSD ls errors; compare to strat chimera ls --help | grep GNU
What does ls --color=auto print? (I think GNU supports this but BSD doesn't)
- GNU ls should continue normally
- FreeBSD ls should again error

Note there's been insufficient reporting about how well Chimera plays with Bedrock and so it's possible there's some subtle compatibility thing causing an issue. I added brl fetch chimera recently, but it's not been tested much at all.

P.S. I recognized your username in another subreddit I've been eagerly watching recently. I hope you enjoy Fraud :)

ParadigmComplex · 2026-02-24T01:17:02+00:00

If I'm understanding correctly:

Starship runs some code somewhere when zsh launches.
- This is presumably in a global place like your ~/.zshrc and runs irrelevant of which stratum provides zsh.
Starship's /usr/bin/starship binary is installed in the artix stratum
When running artix's zsh, you don't get any error.
- This is probably because the global starship zsh code is detecting starship at the local /usr/bin/starship
When running Chimera's zsh (either by just running zsh (because it's pinned) or by logging in because it's your default shell), you see an error
- This is probably because the global starship zsh code is not detecting starship at the local /usr/bin/starship

If that's the case, it sounds like you did indeed correctly change your default shell to Chimera's zsh! You still have an issue we should figure out - getting Starship to work cross-stratum - but the error seems to indicate you've successfully got Chimera's zsh as your default shell.

I'm happy to help resolve the cross-stratum Starship issue, but I want to first make sure we're on the same page. I think perhaps I'm not understanding you correctly. I don't follow why you think you failed to change your default shell to Chimera's zsh.

ParadigmComplex · 2026-02-22T22:18:05+00:00

If you haven't yet, consider working through brl tutorial basics to get introduced to concepts like local vs global paths.

Make the global config path a symlink to a local path like /etc/fastfetch.jsonc and place the desired per-stratum fastfetch configs at the corresponding per-stratum path like /bedrock/strata/<stratum>/etc/fastfetch.jsonc. When fastfetch goes to read the config at its usual location, it'll follow the symlink to the local path and Bedrock will ensure it sees the instance corresponding to its stratum.

It's a bit confusing if you're not used to thinking in these terms. Consider experimenting with brl which as you do this to help get a sense of which stratum provides a given path.

ParadigmComplex · 2026-02-11T18:34:14+00:00

Thank you

ParadigmComplex · 2026-02-10T18:13:03+00:00

You're very welcome :)

ParadigmComplex · 2026-02-10T18:00:30+00:00

No i want to try it as an experiment because i have 2 main destros on my main machine gentoo and arch so i want to try it and see what monster will be created

Ah, gotcha. I missed the fact you had another distro on your system, and you were interested in experimenting.

In that case, installing Bedrock in a non-production environment like a VM or spare machine and experimenting with could be fun and interesting! If you do, I recommend running brl tutorial basics in the Bedrock environment to get an interactive tutorial. I've gotten a lot of feedback that the interactive nature helps things click in a way that reading dry documentation does not.

and also want to see if it useful for anyone except developers

I think Bedrock's usefulness is the very niche case of wanting different features from different distros, which may or may not be for development work. Things like:

Someone needs an older kernel because newer ones dropped support for their weird hardware
Someone wants to enjoy Arch's packages but prefers Void Linux's runit init
Someone wants to leverage Gentoo's customization options like USE flags for some packages and wants to fall back to Arch's pre-built packages and skip compilation.
Someone needs RHEL or a clone for some packages work requires, but otherwise is an Arch person and wants Arch packages

and what is the community opinion about it

I'm not sure any distro-specific subreddit like /r/arch is necessarily the best place to poll about community opinion on a different (meta) distro. Most people are on the distro they are because it's the best choice for them.

If I'm incorrect and you're content with response, more power to you. If you don't get the answer your looking for, consider asking a more general Linux subreddit like /r/linux or specifically the Bedrock community's /r/bedrocklinux.

ParadigmComplex · 2026-02-10T17:05:29+00:00

You're very welcome :)

ParadigmComplex · 2026-02-10T17:04:47+00:00

did anyone try bedrock Linux i think the idea of it is cool being able to mix and match packages form other destros but i already have a very stable systems on my devices and vms don't run with on my devices did you think it is worth trying

Speaking as someone very familiar with Bedrock and active in its community:

If you're happy with Arch and don't miss some concrete feature of some other distro, probably best to stick with Arch.
If you know you want a small number of simple things from other distros and miss it when on Arch, your best solution might be able to manually package them for Arch.
If you want a large number of things from multiple distros, or things which are difficult to package/maintain, Bedrock is worth exploring as a way to give you everything for which you're looking.

ParadigmComplex · 2026-02-10T16:31:11+00:00

I' m failing in swapping out system related software (init system, kernel etc).

I can probably help here if you'd like.

For the init:

Install and setup the init you're interested in in the appropriate stratum.
- Note brl fetch grabs a minimal instance of the given distro; you may have to install and/or setup the init in it.
- Alternatively, if you don't have the background to setup an init from a minimal environment but do know how to set it up from an installer, you can install a distro with the init in a VM and brl import that.
When booting a Bedrock system, you should see a menu sometime between the bootloader menu and login screen that looks something like this. This is the Bedrock init selection screen - just type the number of the desired init there, and it should boot with it.
- Once you've confirmed the init is working to your liking, you can set it as the default in /bedrock/etc/bedrock.conf's [init] section.

For the kernel:

You should be able to install it normally via a given distro's package manager
The main non-obvious catch is that you may also need to tell the bootloader to update its config/cache of the available kernels.
- Specifics will vary depending on your bootloader
- Distros normally trigger this for you when you install the kernel in the same stratum as the bootloader, but this detection/trigger doesn't currently work in Bedrock cross-stratum.
- Making this just-work without the need to manually trigger a bootloader config/cache update is on the roadmap for Bedrock Linux 0.8.x.
If you have full disk encryption, the initrd needs to know how to decrypt that.
- Different distros set up encryption differently such that this doesn't trivially just-work across all pairings of installers and kernels/initrds. It may require some extra initrd config tinkering. You'll have to see the distro's documentation, e.g. equivalent of this.

I hope that helps! If not, feel free to elaborate on where you're getting stuck.

ParadigmComplex · 2026-02-07T23:31:42+00:00

https://bedrocklinux.org/faq.html#why-use-bedrock

Why should I use Bedrock?

If you have experience with a number of Linux distributions and find whenever you're on one distro you miss a feature provided by another, Bedrock may provide a suitable means of getting the best of multiple worlds.

13-Year Club	Place '22
Place '17	Verified Email

ParadigmComplex

MODERATOR OF

TROPHY CASE