[Aboriginal] Unable to use gcc inside chroot of latest aboriginal.
rob at landley.net
Sun Jan 17 08:40:28 PST 2016
On 01/17/2016 03:55 AM, KARBOWSKI Piotr wrote:
> On 01/17/2016 10:29 AM, KARBOWSKI Piotr wrote:
>> Seems kind of like broken toybox to me. Anything that is symlinked to
>> toybox does not work here, I mean, it prints the very same help/error
>> output, looks like its `strings`.
> Okey, I wasn't running cp with -n, which was resulting in overwritting
> the strings symlink with strings binary, which was actually overwritting
> the toybox binary with strings...
I was replying to your first message and went "lemme read the second..." :)
> So yeah, running chroot ./foo /sbin/init.sh gives me working gcc.
> Btw, exiting from the 'chroot ./foo /sbin/init.sh' somehow breaks my
> host's /dev/pts and I am no longer able to spawn any terminal...
That's really weird. The cleanup from the chroot is done _within_ the
chroot, and shouldn't have access to your host mount points.
The mountpoint is created via:
mountpoint -q dev/pts || mount -t devpts dev/pts dev/pts
And the end of the init script is just:
echo Type exit when done.
So we mount -t devpts and then umount it again. It sounds like your
kernel is unmounting every instance of -t devpts when any instance is
To support containers, we now allow multiple instances of devpts
filesystem, such that indices of ptys allocated in one instance are
independent of indices allocated in other instances of devpts.
To preserve backward compatibility, this support for multiple
instances is enabled only if:
- CONFIG_DEVPTS_MULTIPLE_INSTANCES=y, and
- '-o newinstance' mount option specified while mounting devpts
So the behavior changed there, but git annotate says the documentation
change was in 2009...
Either way, that's a kernel issue in your host system.
> -- Piotr.
More information about the Aboriginal