[Aboriginal] Unable to use gcc inside chroot of latest aboriginal.

Rob Landley 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.
  cd /
  umount ./dev/pts
  umount ./dev
  umount ./sys
  umount ./proc

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
unmounted? Hmmm...


  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:

	- '-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 mailing list