Hi all!
I first brought this up on IRC but had to go before I could post the log report asked of me.

The issue:
My Solus installation I just performed did not integrate itself with the environment, so I'm wondering if maybe that is why I'm having some issues compared to another Solus+Bedrock user. As a stopgap I've added `source /bedrock/run/profile` to `~/.bashrc` and `/root/.bashrc` but maybe that doesn't fix everything necessary.

I was asked to run `brl report` so here is the zerobin output.

Thoughts?

root version of report gen here.

After discussion with you on IRC, I've exhausted ideas I have to debug the issue remotely. When I find the time I'll attempt to hijack a Solus install and see if I can reproduce the issue discussed. If so, it should be much easier for me to debug the issue locally.

That would be fantastic! You mentioned on IRC that you tried to install the same program that I had (zoom from arch:AUR) and had absolutely no issues - I would love to get my install of Solus+BRL up to that ease of use.

I've attempted the userland install method, and encountered problems. I was able to get around most of them, but finally stuck at the musl compiler I think not finding <scsi/sg.h>, despite it being in linux_headers/include/scsi/sg.h

Here is what I did to make progress on the problems I overcame during the tarball making process. I don't know what I'm doing here, so it's probably wrong!

I'll try another bare metal hijacking from the downloadable shell file.

So I should note that I never said one important thing, that I was using the downloadable shell installer: https://github.com/bedrocklinux/bedr....7.6-x86_64.sh

I'm now trying to build the script myself using beta 1.0beta2 (since I've tried 1.0beta3 this morning, see later post)

Well I tried 1.0beta2 and followed all the instructions, twice. After a reboot both times I get this error trying to do anything with brl (but it DOES see brl by default!):

I apologies for the time it's taken me to get around to it. Personal life surprises have eaten more of my time than usual in the past few weeks, on top of which Bedrock has gotten more attention than usual recently and swamped me with support requests. I haven't forgotten about this, and I fully intend to get to it as soon as I have a moment.

While past releases had multiple installation options, the current only has one, unnamed install method. I'm a bit lost as to what you're doing.

If you go to the project website at https://bedrocklinux.org/ you can follow "Installation instructions" on the left navigation bar to find the current release's installation instructions.

If you go to the project website at https://bedrocklinux.org/ you can follow "All releases" on the left navigation bar to find the the list of Bedrock Linux releases. We've never had a 1.0beta3 release. Note this FAQ entry about the name change.

If you go to the project website at https://bedrocklinux.org/ you can follow "Installation instructions" on the left navigation bar to find the current release's installation instructions which includes a link to the current release's source code, should you wish to compile it yourself.

You can also go to https://github.com/bedrocklinux/bedrocklinux-userland and just clone master, which I try to keep in sync with the current release.

That's the expected installation method for the current release.

While you might be able to adapt to each error message you run into and stumble your way to something, in general the instructions for 1.0beta2 won't work for building the current 0.7.6 release.

Also the post timestamps make it seem like an earlier post.

Bedrock Linux 1.0beta2 doesn't have a `brl fetch --list`. Its `brl` works completely differently.

While I am amenable to assisting with 1.0beta2 when time is available should you have some desire to use it, I strongly recommend the current `0.7.x` release. I've heard no disagreement to the idea that it is a significant improvement over past releases. Moreover, the entire community and all of my support resources have moved over to it; it will be much easier and faster for me to support.

If you insist on 1.0beta2, make sure to use its documentation rather than the `0.7.x` documentation.

Thanks so much for your detailed reply; I really appreciate it.

What I had done was attempt the beta2 userland compilation using the beta2 install instructions.
Then I also tried beta3 when I encountered too many issues to deal with on my own, but this was using the beta2 instructions.
I did not try just the userland master branch though - maybe I'll have better results with that.
I then went back and used the 0.7.6 shell installer as that doesn't give any errors for me, though I still needed to add 'source /bedrock/run/profile' to the appropriate places.
Oddly enough, on this new hardware I've been installing on, I get a very different behavior when trying to 'brl fetch ubuntu' where it gives a generic error and quits. On my personal laptop I installed an ubuntu strata without any issue.
So I think the safest thing to do if you have a minute is to start up a VM (I used VirtualBox) with Solus 4.0 and try to hijack it. I bet you'll see the same lack of brl in path that I do. I do make sure to update Solus first before attempting a hijack; attempting it the other way around causes too many changes that Bedrock is not aware of and creates an unbootable install (probably the kernel update?).

I was able to reproduce both issues you've mentioned.

brl is not in the $PATH because apparently Solus makes /etc/profile a symlink to a file in /usr. We can sort of work around this by creating a /etc/profile.d/ directory and symlinking /bedrock/share/shells/include-bedrock to /etc/profile.d/99bedrock.sh. However, another package could create a /etc/profile.d/*.sh script which overwrites it and breaks things again, which is why Bedrock favors /etc/profile. I'll consider adding code to detect this scenario and fall back to an /etc/profile.d/*.sh script, as that's better than it flat out not working, but I'm not sufficiently confident in that to recommend it for production.

The issue in which the system is not bootable if Solus' kernel/initrd is updated post hijack appears to be because grub.cfg is configured to look in the root directory for the kernel and initrd rather than /boot. As a work around, you boot by by hitting `e` at the bootloader prompt and add /boot to the two file paths that are in the root directory. Once booted, you can manually edit /bedrock/grub/grub.cfg to fix it. However, I expect it to break again on the next update. I could not find out why a Bedrock'd Solus did this in the time I was able to allot to debugging it, and I'm very uncomfortable with the idea that a Bedrock user could find the system unbootable like this.

As noted on the distro support page we don't actually have any Bedrock distro maintainers who actively maintain Solus support. I've tried to find time to give it some attention despite this and have gotten it working in the past - hence the "Yes" in the hijack-able column you saw before and mentioned on IRC - but I keep finding they make changes which break functionality on Bedrock. Moreover, from prior experience I don't think the Solus devs are overly eager to have it work with Bedrock. While they never said anything outright, reading between the lines I got the impression they have a very specific curated experience in mind and things like Bedrock ruin their artistic vision.

Had I more time I'd be happy to pursue this out of principle - I'd certainly like Solus to work with Bedrock - but given the practicalities of the situation I'm going to have to throw in the towel. Solus on Bedrock really needs an active maintainer and we don't have anyone fit for the position.

My apologies for the bad news, particularly after having kept you waiting so long for me to get around to investigating it.

1 members found this post helpful.