to understand the limitations and usages of buildFHSUserEnv I would like to ask whether it is possible to somehow elevate the execution context from the custom file system out to the original operating system.
One application is the usage of vscode-fhs to change configuration.nix and then run sudo nixos-rebuild switch, which seems to break. I am interested in the general question, whether we somehow can get out of the inner file system and work on the normal operating system.
Hi @hmenke this question has nothing todo with sudo, it only asks about file system accessibility.
The phrase “This gets asked like once a week” discourages people to ask questions which in its own is inappropriate on a page like discourse. Please consider your choice of words.
It’s a matter of fact that this gets asked once a week. I think the documentation around FHS environments should be better. I’ll see whether I can write something up.
yes really, when I asked this question I was not aware that sudo is any special command and just wanted to see the original system in the inner one.
Unfortunately that does not seem possible.
I’ve had a look at the source. The problem is basically only with stuff in /etc because the FHS does not bind-mount all of /etc but only individual files.
I don’t really know why that is done. Probably because it makes it easier to merge with all the /etc directories coming from the derivations to be enclosed in the FHS.
Regarding vscode, there is also a non-FHS version of the derivation. Could you use that instead?
yes I could and had used it. However if you want to use vscode to install vscode extensions it seems like the FHS version has best support for this. Also a couple of other bugs I run into haven’t occured in the FHS version which hence looks much stabler.
on the other hand it seems nix buildFHSUserEnv is not designed for editors and IDEs like Visual Studio Code.