[lxc-devel] lxc-execute only finds lxc-init when lxc-init is manually populated inside of the container

[Peter Fedorow]

On 14-03-26 05:42 PM, Stéphane Graber wrote:
> On Wed, Mar 26, 2014 at 05:36:27PM -0400, Peter Fedorow wrote:
>> On 14-03-26 05:13 PM, Stéphane Graber wrote:
>>> On Wed, Mar 26, 2014 at 05:08:31PM -0400, Peter Fedorow wrote:
>>>> How to Reproduce
>>>> ----------------
>>>> 1.  lxc-create -n test1 -t ubuntu
>>>> 2.  lxc-execute -n test1 -- /bin/bash
>>>>
>>>> Fails:
>>>> lxc-execute: Failed to find an lxc-init
>>>>
>>>> 3.  lxc-start -n test1 -d
>>>> 4.  lxc-console -n test1
>>>> 5.  login
>>>> 6.  sudo apt-get install lxc
>>>> 7.  sudo shutdown -h now
>>>> 8.  lxc-execute -n test1 -- /bin/bash
>>>>
>>>> Success!
>>>>
>>>>
>>>> LXC Versions Tested
>>>> -------------------
>>>> Ubuntu automatic upstream - 1.0.1+master~20140326-1500-0ubuntu1~ppa1~saucy1
>>>> Ubuntu Trusty - 1.0.1-0ubuntu1
>>>> Ubuntu 13.10 - 1.0.0~alpha1-0ubuntu14.1
>>>>
>>>> OS
>>>> --
>>>> $ lsb_release -a
>>>> No LSB modules are available.
>>>> Distributor ID:    Ubuntu
>>>> Description:    Ubuntu 13.10
>>>> Release:    13.10
>>>> Codename:    saucy
>>>> $ uname -a
>>>> Linux bigserver 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14
>>>> UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>>>
>>>>
>>>> Additional Notes
>>>> ----------------
>>>>
>>>> Installing the binary is a work-around for 64-bit, there is no
>>>> obvious work-around for 32-bit containers on a 64-bit host.
>>>>
>>>> This is not the same as bug #22.  The library is being found, but it
>>>> needs to be loaded from outside of the container's rootfs.
>>>> Providing the binary alone inside of the container is insufficient
>>>> unless the binary is statically linked and 32-bit compatible.
>>>>
>>>>
>>>> Regards,
>>>> Peter Fedorow
>>>
>>>
>>> lxc-execute depends on lxc-init being available in the container rootfs,
>>> just like lxc-start depends on /sbin/init being available in the
>>> container rootfs.
>>>
>>> So to use lxc-execute, you just need to make sure whatever package
>>> provides lxc-init (in Ubuntu's case, lxc itself) is installed inside the
>>> rootfs before you use lxc-execute.
>>>
>>
>> I mentioned that work-around in the bug report, but as noted, it
>> does not work for 32-bit containers on 64-bit hosts.  (I even tried
>> it - see below.)  Further, even on 64-bit hosts, the default package
>> resolution for the Ubuntu lxc package pulls in 63 packages, yet it
>> is frequently desirable to use lxc-execute for light-weight tasks.
>
> Ah, I think I see the problem, the issue is about the path to lxc-init
> which is hardcoded inside LXC to the multiarch path.
>
> So the best way around this (which is arguably not ideal) is to install
> lxc (the 32bit version) inside the container and just symlink that
> lxc-init to /usr/lib/x86_64-linux-gnu/lxc/lxc-init in that container.
>
> I guess we should make the path to lxc-init configurable somehow to deal
> with that corner case.
>

That work-around did it.

To make it lest rigid, perhaps substitute "/i386-" for "/x86_64-" in the 
path for 32-bit containers on x86-64 hosts?

Unfortunately, this solution will still fail for 'non-conforming' Linux 
distros using different paths.  Providing 64 and 32 bit static versions 
of the binary, for manual population, or automatic injection via a 
mount, would be a substantially more elegant solution because it would 
work in more cases, and it would cause lxc-execute to function as most 
users would expect - without modifying the container.

Alternatively/additionally, adding a manual path option to lxc-execute 
will work too, but it isn't as nice for the user.

--cut--