Bedrock LinuxThis forum is for the discussion of Bedrock Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
No problems during `brl fetch`, but when I executed first command
Code:
# cave help --all
cave@1567616172: [WARNING paludis_environment.userpriv.tty] In thread ID '19807':
... In program cave help --all:
... When making environment from specification '':
... When loading paludis configuration:
... Cannot verify that we have sufficient permissions to use PTYs properly using userpriv (user paludisbuild is not in group 5). Strange breakages may occur. You should ensure that the 'paludisbuild' user is in the group to which /dev/tty belongs
Above output gone after add the 'paludisbuild' user to group 5 in /etc/group file.
Seems something went wrong during step '[11/18 ( 61%)] Modifying paludisbuild'
I can reproduce the issue, and I think I see the associated bug. The code step you correctly called out as problematic is:
Code:
chroot "${target_dir}" usermod -a -G "$(stat -c %G /dev/tty)" ${paludis_user}
That chroot at the front makes the usermod update the local copy of /etc/group rather than the proper global one. Once the new stratum is enabled the global one takes precedence and the changes to the local one are ignored.
Fixing it should just entail making the group change outside of the chroot on the actual /etc/group and swapping usermod out for some busybox utility such as addgroup.
Catching this kind of thing is exactly what the beta releases are for, many thanks for being proactive here.
I'll see if I can fix it and push another beta this weekend.
@Philantrop Thanks for Exherbo fetcher, nice to try Exherbo using bedrock linux.
I've just checked how cave command works with latest Exherbo commits on github.
User paludisbuild is in group 5 now. Above issue is fixed, but next one appeared.
Code:
# strat exherbo-musl cave sync
Starting sync
Repository Status Pending Active Done
-> accounts starting 9 1 0
-> arbor starting 8 2 0
-> accounts no syncing required 8 1 1
-> installed starting 7 2 1
-> arbor active 7 2 1
strat: warning: unable to set cwd to
/var/db/paludis/repositories/arbor
for stratum
void-musl
due to: no such directory (ENOENT).
falling back to root directory
strat: warning: unable to set cwd to
/var/db/paludis/repositories/arbor
for stratum
void-musl
due to: no such directory (ENOENT).
falling back to root directory
fatal: not in a git directory
* /usr/x86_64-pc-linux-musl/libexec/paludis/syncers/dogit+https: could not switch from '' to 'https://git.exherbo.org/git/arbor.git'
-> arbor failed 7 1 2
-> installed no syncing required 7 0 3
-> installed-accounts starting 6 1 3
-> unavailable starting 5 2 3
-> installed-accounts no syncing required 5 1 4
-> installed-unpackaged starting 4 2 4
-> installed-unpackaged no syncing required 4 1 5
-> repository starting 3 2 5
-> unavailable active 3 2 5
...
cave is changing directory to /var/db/paludis/repositories/arbor
cave is calling some program which exherbo-musl does not provide. Bedrock assumes if this situation occurs, the specific build of the command doesn't matter and it should just forward one from another stratum. In this case, the void-musl stratum.
void-musl does not have a local /var/db/paludis/repositories/arbor. This is why you get that warning and probably why you get the following error.
To debug what the command that's being forwarded is, install `strace` in some stratum then run as root:
Code:
strace -o/tmp/log strat exherbo-musl cave sync
and provide /tmp/log (e.g. pastebin/bay/gist/whatever). Hopefully those logs will include execution of something from /bedrock/cross/bin.
I can think of two short-term work arounds:
Install whatever the missing item is in exherbo-musl so it gets it from exherbo-musl rather than reaching across strata to void.
Run `strat -r exherbo-musl cave sync` where that `-r` instructs strat to restrict the stratum to its own files; i.e., don't forward missing items from void-musl.
And two corresponding longer term solutions:
See if this is a missing dependency that exherbo should have come with. If so, work with exherbo to include it and/or get `brl fetch exerbo` to add it.
Add cave to the list of restricted programs in /bedrock/strata/bedrock.conf to which Bedrock automatically utilizes the aforementioned -r flag.
Philantrop would be know better than I do if it's a missing dependency that exherbo should have come with or not.
Ah, that's interesting. I guess we need to fine-tune Bedrock's rules a bit for your situation. I see a number of possible workflows to consider which might help:
Retain your pinned git and restrict cave so it only uses its own tools, ignoring pinning.
Remove your pinned git and configure whatever programs you explicitly want to call out to void's git to be from void. They'll prioritize the local git by default, which will then be void's.
Remove your pinned git, uninstall git from the non-void strata you want to call out to void's git, and put void higher than exherbo or whatever else has to retain git in your bedrock.conf [cross]/priority. This way exherbo's commands will call exherbo's git, but the other situations will either be void processes which prioritize their local git or non-void, non-exherbo processes which lack a local git and fall back to void's.
Remove your pinned git and explicitly call `strat void git` in the situations you want void's git. If it's only from your shell, you might be able to `alias git="strat void git"` which should hold in your interactive shell but not in other environments such as cave's internal calls.
None of these are perfect, sadly. There issues where you may have to play wack-a-mole where you may run into other programs that will need to be restricted, pinned to avoid, or have their local git uninstalled.
I'll put some time into thinking of a way to improve the Bedrock to handle this situation better.
Last edited by ParadigmComplex; 09-07-2019 at 06:12 AM.
As described, that will add both non-trivial amount of complexity and a non-trivial runtime performance hit. It could be worthwhile if the use case was strong enough, but I don't really understand the use case here at all.
You could get a similar effect by creating a file with
Code:
#!/bin/sh
strat void git $@
at /bedrock/strata/arch/usr/local/bin/git.
If that's insufficient for your needs, can you elaborate on what you're trying to do here? It's hard to provide a solution when I don't actually know what you're trying to do.
I want to pin some apps from other strata than hijacked.
e.g. I have hijacked artix, but I prefer to use firefox-esr from void strata. Create a file at /bedrock/strata/artix/usr/local/bin/firefox with proper content is sufficient for me. Thanks for the tip.
This stuff is definitely confusing if you're not used to thinking in this manner. One can make relatively complex webs of what-from-where.
There's nothing special about the hijacked stratum that gives it priority over anything else. Once the hijack is over, it's the same as all the other strata. If the local stratum provides something, that takes precedence over non-pinned cross-stratum stuff. If you get bash from the hijacked stratum, then launching stuff from the bash will prioritize the hijacked stratum's stuff, but that's not because it's the hijacked stratum. I think my current install was a hijacked Fedora, but I get zsh from Debian, so when I run `ls` I get Debian's `ls`. Also everything from Fedora has since been removed. This is the second thing you've mentioned that you want to come from Void. If you want most things to come from Void, consider making it your shell provider.
If you don't need another firefox around, the easiest solution is to just only have one firefox.
If you have multiple instances of firefox but want Void's to be the default, pinning should be fine. Something like this should get the job done:
Code:
pin/bin/firefox = void:/usr/bin/firefox
There were issues with git, but git operates very differently for these purposes. It's very unlikely you'll have something call firefox under-the-hood such that it matters that it's a cross firefox.
If you always want processes from artix to use void's firefox while processes from other strata could default to another, the /bedrock/strata/<stratum>/usr/local/bin/ thing would work, but I'm having difficulty imagining a workflow which would have this specific requirement. What you described here:
Quote:
Originally Posted by marcin-
I want to pin some apps from other strata than hijacked.
e.g. I have hijacked artix, but I prefer to use firefox-esr from void strata.
doesn't really cover the need, at least not as I'm interpreting it.
That having been said, if it gets the job done for you, do feel free to use it. As long as you have something that works for you here, I'm happy.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.