Issue entering an Arch Linux container: /bin/sh instead of /bin/bash, and degraded mode

[bpak]

Hello,

When running an Arch Linux container, the session opened with pct enter is systematically /bin/sh, although /etc/passwd specifies /bin/bash for the root user.

More interestingly, none of /etc/bash.bashrc, ~/.bashrc, /etc/profile, ~/.bash_profile, ~/.profile, ... gets executed, although it should be the case according to the Archwiki / Bash page.

I tried to change the CT option --cmode, use both a template from Proxmox or Linux Containers, but I'm still facing the same issue.
I couldn't find any help when searching the net for a solution, apart from this page in Archlinux forum, which refers to part of LXC source code, and seems to (maybe?) indicate "incompatible nss implementations" between the host and the guest.

I also tried to create containers with others distros (Ubuntu, Debian, Alpine), but the issue did not appear there, only with Arch.

Finally, it has to be noticed that running pct exec CTID /bin/bash will properly open a bash session though, but I would really want to avoid this, as I systematically use pct enter with all my other containers.

Do you see any way to correct this problem, or could you please help me investigating further?

Many thanks in advance for your help.

 

[LnxBil]

More interestingly, none of /etc/bash.bashrc, ~/.bashrc, /etc/profile, ~/.bash_profile, ~/.profile,

That is normal with every container I tried and not dependend on the guest OS. I could not figure out a way to get a proper login shell. A lot of environment variables are also still visible including PS1 so the prompt will therefore be propageted from the PVE host to the container. I ended up installing dropbear everywhere, so that I could get a valid and always working environment.

 

[bpak]

Really? Because on my side, I've been using Ubuntu server as the guest OS for my CTs for quite a time, and I've always enjoyed a custom /etc/bash.bashrc to benefit from colored PS1, bash completion and more.
I just did a quick test, by recreating a CT from the Ubuntu template, and it works without an issue.

But thanks to your post, I think I've narrowed the problem a bit:
- if I create the CT as I normally do (ie with --ostype ubuntu), my custom /etc/bash.bashrc is executed
- if I create the CT without --ostype ubuntu, my custom /etc/bash.bashrc is not executed

Maybe this would solve your issue?
Regarding mine with Arch, I think I'm going to play with --ostype and see if I can get something. I'm also going to dig in /usr/share/lxc/config/, as described in the pct manual page. It's where the distro-related LXC configurations are defined, and maybe there is something to update for Arch specifically.

Still a long way to go, but thanks to you, I think I now have a trail to follow, I thank you for that!

 

[LnxBil]

Maybe this would solve your issue?

Yes, could be. I never tried with Ubuntu, only Debian, Alpine and RHEL-based systems. Thank you for your help.

 

[bpak]

Did quick-and-dirty tests with Debian, OpenSuse and Fedora: it works.
For Alpine, it does not seem to work out-of-box though, but it may be due to the specificities of this distro.

 

[LnxBil]

Did quick-and-dirty tests with Debian

I just redid one and it does not work. What file will be included? I still have everything "inherited" from my PVE shell after running pct enter.

 

[bpak]

I just redid one and it does not work. What file will be included? I still have everything "inherited" from my PVE shell after running pct enter.

Did you try on an existing CT, or a new one? Because I guess that --ostype will impact the CT creation (basically applying custom recipes depending on the distro), but will not influence an existing CT.

 

[LnxBil]

Did you try on an existing CT, or a new one? Because I guess that --ostype will impact the CT creation (basically applying custom recipes depending on the distro), but will not influence an existing CT.

It was an existing container ... and the .bashrc is executed, my .bash_login is not executed due to the fact that this is not a login shell.