LinuxQuestions.org - Bedrock Linux: "/" partition mounted on a BTRFS subvolume

- Bedrock Linux (https://www.linuxquestions.org/questions/bedrock-linux-118/)

- - Bedrock Linux: "/" partition mounted on a BTRFS subvolume (https://www.linuxquestions.org/questions/bedrock-linux-118/bedrock-linux-partition-mounted-on-a-btrfs-subvolume-4175710714/)

Bedrock Linux: "/" partition mounted on a BTRFS subvolume

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.

Quote:

Originally Posted by ParadigmComplex (Post 6345711)

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

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":

Code:

ERROR: `gpg` required for cryptographic signature verification.  Either install it (often in `gnupgp` package) or use `--skip-check` flag to disable check."

There is no gpg in busybox, so that, so far, seemed OK. When I tried again with the "--skip-check" option:

Code:

* Checking for updates

Checking https://raw/githubusercontent.com/bedrocklinux/bedrocklinux-userland/0/7/releases...

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:

Code:

ERROR: Unable to determine calling stratum certificate file

ERROR: Unable to automatically find a valid mirror.  Manually specify a mirror with `--mirror`.

ERROR: Unexpected error occurred.

This is commonly due to distro mirror layout changes breaking `brl fetch`.  Possible solutions:

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.

Quote:

Originally Posted by jr_bob_dobbs (Post 6346410)

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

Seems that way to me.

Quote:

Originally Posted by jr_bob_dobbs (Post 6346805)

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

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`.