Consider a computer that has at least two distros on it, each of which is on a sub-volume of the same BTRFS partition. One is a minimal distro whose function is to manage the lilo boot loader. The other is the usual system, functioning as a more or less average desktop Linux system (browse web, get mail, etc.).

Currently all distros on the machine boot correctly with their respective init ram disks.

I was thinking of installing Bedrock on the desktop distro. Can bedrock handle the "/" partition being mounted on a sub volume?

If no one provides you a good answer, consider just trying it out and seeing.

I can't imagine complicating the complexity that is btrfs by trying to host more than one operating system on one volume.

Looks like that's what I'll have to do. It will be an involved process to set it up in qemu, because only a LFS or a slackware installer can easily be put the entire OS all on sub volume mount mounts.

It turns out that I remembered incorrectly: Slackware doesn't easily install to a sub volume. Turns out on that computer I'd installed Crux as the first OS and then copied in a BLFS for the second.

I wasn't going to do another Crux install, so in Qemu I put in a Buildroot system. Quick & easy to install, just add kernel, modules & lilo and use betterinitramfs.

Once I had that working, with "/", "home" and an extra "stuff" mount point all mounted to sub volumes, I put in Bedrock.

The good news: the bedrock system, all on sub-volumes boots fine. I can log in and the commands I've typed in the console seem to work correctly. Was able to get online OK, used the busybox wget to download the Bedrock installer.

However, when I tried to add a stratum, new problems emerged. I get the feeling these problems are probably not file system or mount-point related but I'll mention then just in case I am incorrect.

When I tried to check for updates via "brl update":
There is no gpg in busybox, so that, so far, seemed OK. When I tried again with the "--skip-check" option:
After the "... " it put my prompt, so brl exited without the usual expected trailing linefeed.

I then tried to put a Void stratum on, figuring I could then get gpg and whatever else was needed that way. The run started OK, with the CPU architecture line, the determining mirror line. Then it balked:
There was more to the message, snipped for size.

Attempted to fetch a Debian stratum, and got the same error message.

I remember, years ago, installing LFS, there was a certificates package. On my phone, lack of newer certificates has begun to curtail web browsing. I could guess that busybox / buildroot doesn't have a certificates package?

So, it looks like sub-volumes are fine? it looks like my above errors are unrelated to sub-volumes?

More data to report.

After installing devuan in another disk image, then tarring that up, I was able to then boot into the previous disk image and "brl import" that. As expected, the presence of a gpg executable enabled "brl update" to work.

installed links, btrfs-programs in Devuan. The Links browser loads web pages fine, so no certificate problems there.

While booted from the Devuan init, ran xorg, window manager, and xterm fine.

Unexpectedly, the fetch of Void still failed with the same certificate error. That's really weird.

A look at the /etc/fstab, which we know gets modified on the fly at boot time by bedrock, still had the valid "subvol=" options for all subvolume mounts. I'd think, based on that, that bedrock is handling BTRFS fine (so long as the kernel & initramfs can, obviously).

I'd guess that brl is being difficult for reasons unrelated to BTRFS. To the best of my knowledge, no kind of "certificates" are involved in a file system.

Seems that way to me.

Your description hasn't included steps which attempt to resolve the issue described in the error message. The fact you keep getting it does not sound weird to me. Bedrock does not distribute certificates, as we don't have the manpower to guarantee someone is on top of associated security updates 24/7/365. Rather, Bedrock gets it from another distro the user presumably trusts for these things. As noted in the error message, `brl fetch` looks for installed certificates in the calling process' stratum. Either install certs in the calling stratum, or change which stratum you use to call `brl fetch`.