Quote:
Now, that file in slackware is in turn called by /etc/profile. However, the hijack-install of bedrock overwrote /etc/profile with its own version, which does *not* call anything in /etc/profile.d. Oops! The bedrock rc.conf file sets the language to LANG=en_US.UTF-8, which some programs in slackware, including lsblk, can have trouble with, based on comments in the original /etc/profile and my own recent experience.
|
Your analysis of what's happening with /etc/profile is correct, but I think you're missing why things are set up this way. I also think it's the wrong way to solve the problem you're having.
Bedrock Linux overriding the stratum's /etc/profile is key in how Bedrock Linux works. Amongst other things, it enforces the same LANG everywhere. The idea is you set it in
/bedrock/etc/rc.conf instead of the per-distro specific ways. Without this you can end up in situations where one terminal (e.g. xterm) uses one keyboard layout but another (e.g. xfce4-terminal) uses another keyboard layout, which is usually undesirable and very confusing. Instead of breaking Bedrock Linux's enforcement of LANG in /etc/profile, try just setting the LANG item in /bedrock/etc/rc.conf instead.
You are correct that Bedrock Linux doesn't currently respect /etc/profile.d/* items. Amongst other things, I believe this breaks bash completion. I've been meaning to fix this... I'll see if I can get it done properly for the upcoming release. There's a non-trivial aspect of doing it correctly that I need to be careful about. If you want to do it yourself, just make sure it happens *before* the bulk of the Bedrock Linux code in /etc/profile there so Bedrock Linux overrides whatever it picks up.
Quote:
By changing the /etc/profile to call scripts in /etc/profile.d, I got lsblk to display correctly. Bonus: there is a good chance that other problems, as yet undiscovered, are fixed by running things in profile.d.
|
Yes, but you also might have broken some of the standardization/interaction stuff for Bedrock. I'd recommend reverting that (or changing it so Bedrock Linux's bits are done later and override whatever was in /etc/profile.d) and fixing the issue another way - either changing /bedrock/etc/rc.conf to use en_US sans utf8, or fixing the vt to support utf8.
Have you tried astrogeek's recommendation of
Code:
append = " vt.default_utf8=1 "
in lilo?
Quote:
The bedrock /etc/profile uses busybox but (so far) seems to interpret the .sh files without problems.
|
It's usually sourced by a shell instead of run directly as a stand-alone executable. That first hashbang line is ignored as a comment. It'll probably use Slackware's /bin/sh or /bin/bash when booting, if I had to guess.
Quote:
@ParadigmComplex: I'm using slackware's init but /etc/profile is run at login time. I'm not referencing /etc/profile nor /etc/profile.d/* as local files. It seems to run OK, though. I think this is because slackware is both the rootfs and global stratum?
|
We may be on different pages - either you're missing a nuance of how Bedrock Linux works here, or I'm misunderstanding you. "Referencing ... as local files" doesn't make sense in this context.
Sadly, while much of Bedrock Linux "just works", there is a bit of under-the-hood stuff that you'll need to know for situations like this.
The docs describe it here, but linking you to this earlier didn't seem to help. I'll try to rephrase here:
- Bedrock Linux lets you use software from a variety of distros.
- If different distros need to have have different files at the same path to ensure everything works (e.g. Debian and Ubuntu will have different /etc/apt/sources.list files), you'll end up with multiple instances of these files. These files are called "local" files. To differentiate between different instances of these local files Bedrock Linux has a piece of metadata associated with them called the file's "stratum". So you could have a (debian, "/etc/apt/sources.list") and a (ubuntu, "/etc/apt/sources.list") - by specifying Debian or Ubuntu you can indicate to which /etc/apt/sources.list you are referring.
- Some files should be the same for all distros. For example, consider your ~/.bashrc file. These are called "global" files. You'll only have at most one instance of each. These actually have the stratum metadata as well - they all get tagged as "global".
- Everything defaults to local. The exceptions which should be global are configured in /bedrock/etc/strata.conf and /bedrock/etc/strata.d/* (which may refer to /bedrock/etc/frameworks.d/*). You can run "bri -c <stratum> bind ; bri -c <stratum> share ; bri -c <stratum> union" to see all of the global files for a given stratum.
- If some process tries to do something with a local file, Bedrock Linux does some pretty nifty logic to figure out from context which one should be provided. It's *usually* correct. For example, if Debian's apt-get tries to open /etc/apt/sources.list Bedrock Linux will give it the Debian one. If you run "reboot", you'll get the "reboot" executable associated with the current init system.
- If some process tries to do something with a global file, what file to give it is obvious, as there's only at most one instance of such a file. Just give it that one.
- In certain situations when you try to do something with a local file Bedrock Linux can't tell from context which instance of the file you you want. Even a bright human looking over your shoulder as you type may not be able to tell. If you run "vim /etc/apt/sources.list" which /etc/apt/sources.list do you want, Debian's or Ubuntu's? To solve this you can explicitly tell Bedrock Linux which one you want by prefixing the path with "/bedrock/strata/<stratum-name>". So if you want to edit Debian's /etc/apt/sources.list with vim you should run "vim /bedrock/strata/debian/etc/apt/sources.list".
- If you don't specify which local file, Bedrock Linux will guess the one that matches the process trying to use the file. So if you use Debian's vim to edit "/etc/apt/sources.list" you'll get Debian's, and if you use Ubuntu's vim to edit "/etc/apt/sources.list" you'll get Ubuntu's. If you used Slackware's vim to edit "/etc/profile.d/lang.sh", you edit Slackware's "/etc/profile.d/lang.sh", but it's best not to rely on that in case you later try to do something like using Slackware's vim to edit Debian's "/etc/apt/sources.list" by doing "vim /etc/apt/sources.list".
- "/etc/profile.d/lang.sh" is a local file. To indicate you explicitly want Slackware's instance of it, you should edit "/bedrock/strata/slackware/etc/profile.d/lang.sh".
- "/etc/profile" is a global file; every process from every distro sees the same file here. This is part of how Bedrock Linux enforces things like the same locale everywhere. You can edit it with just "/etc/profile" - Bedrock Linux will know you mean the global instance.
That make sense? If not, do let me know where it lost you and maybe I can resolve the confusion.
I'd really like to be able to make that part "just work" such that you never had to manually prefix with "/bedrock/strata/<stratum>" or worry about this, but I don't think it's even theoretically possible. It'd also be nice if I could explain it more succinctly.