New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LXC containers? #364

Open
kzahel opened this Issue Sep 12, 2013 · 138 comments

Comments

Projects
None yet
@kzahel

kzahel commented Sep 12, 2013

I am wondering if it is possible to run LXC containers in my chroot. Has anyone tried this? I tried to create one in ubuntu precise but got an error "wrong fs type on /dev/shm"

I think running a container inside a chroot may not be a supported use case for lxc yet. But for chromeos it's sort of our only option, aside from doing a dev_install and some portage overlay magic?

I'm just kind of rambling here, but I couldn't find any information about LXC on chromeOS and this seemed like a reasonable enough place to find some.

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Sep 12, 2013

Collaborator

I gave a quick try at LXC, but I didn't manage to get it to work on my Arch laptop, so I got bored of it and gave up (maybe I should try again)... Instead I went for a lower level approach (dirty branch here: https://github.com/drinkcat/chroagh/commits/container.tmp), and I managed to "boot" Arch in a container, directly from Chrome OS. My idea is that it would be neat to start the crouton chroots in their own containers, so we can use systemd services, shut down chroots in a cleaner way (processes belonging to the chroot are clearly separated), control hardware access, etc.

So, in short, kernel support is available, and it's something I'd really like to get working. The only issue I have now is that the kernel for Samsung ARM is still stuck on 3.4, so it lacks some features, like being able to rejoin an existing container (important for crouton), or create a new instance of /dev/pts (not so critical for crouton, more so if you care about container isolation...).

Now, back to LXC, I see 2 options:

  • Compile it statically in a chroot (no idea how difficult that may be), and move it to /usr/local/bin in Chrome OS. Chances are it may work...
  • Find out what prevents it to work from inside the chroot. It looks like it's complaining about /dev/shm being a bind mount, you could try to remount /dev/shm with something like mount -t tmpfs tmpfs /dev/shm, and see where it fails next...
Collaborator

drinkcat commented Sep 12, 2013

I gave a quick try at LXC, but I didn't manage to get it to work on my Arch laptop, so I got bored of it and gave up (maybe I should try again)... Instead I went for a lower level approach (dirty branch here: https://github.com/drinkcat/chroagh/commits/container.tmp), and I managed to "boot" Arch in a container, directly from Chrome OS. My idea is that it would be neat to start the crouton chroots in their own containers, so we can use systemd services, shut down chroots in a cleaner way (processes belonging to the chroot are clearly separated), control hardware access, etc.

So, in short, kernel support is available, and it's something I'd really like to get working. The only issue I have now is that the kernel for Samsung ARM is still stuck on 3.4, so it lacks some features, like being able to rejoin an existing container (important for crouton), or create a new instance of /dev/pts (not so critical for crouton, more so if you care about container isolation...).

Now, back to LXC, I see 2 options:

  • Compile it statically in a chroot (no idea how difficult that may be), and move it to /usr/local/bin in Chrome OS. Chances are it may work...
  • Find out what prevents it to work from inside the chroot. It looks like it's complaining about /dev/shm being a bind mount, you could try to remount /dev/shm with something like mount -t tmpfs tmpfs /dev/shm, and see where it fails next...
@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Sep 12, 2013

Collaborator

@kyle - Hadn't heard of 'LXC Containers' but after Googling it I think this
concept sounds pretty exciting and promising - 'a chroot on steroids' is
one description. I'll play around with it on a desktop Ubuntu install and
see what happens...

@drinkcat - Are 'croagh' 'c_h_roagh' the same thing? I had a '
croagh:031df18f' quantal chroot installed with kde, unity & xfce a while
back but haven't played with it in a while, I'll tinker with it again too.
If they are different, I'll get the 'chroagh' tarball and try it out.

On Thu, Sep 12, 2013 at 12:04 AM, drinkcat notifications@github.com wrote:

I did a quick try at LXC, but I didn't manage to get it to work on my Arch
laptop, so I got bored of it and gave up (maybe I should try again)...
Instead I went for a lower level approach (dirty branch here:
https://github.com/drinkcat/chroagh/commits/container.tmp), and I managed
to "boot" Arch in a container, directly from Chrome OS. My idea is that it
would be neat to start the crouton chroots in their own containers, so we
can use systemd services, shut down chroots in a cleaner way (processes
belonging to the chroot are clearly separated), control hardware access,
etc.

So, in short, kernel support is available, and it's something I'd really
like to get working. The only issue I have now is that the kernel for
Samsung ARM is still stuck on 3.4, so it lacks some features, like being
able to rejoin an existing container (important for crouton), or create a
new instance of /dev/pts (not so critical for crouton, more so if you
care about container isolation...).

Now, back to LXC, I see 2 options:

  • Compile it statically in a chroot (no idea how difficult that may
    be), and move it to /usr/local/bin in Chrome OS. Chances are it may
    work...
  • Find out what prevents it to work from inside the chroot. It looks
    like it's complaining about /dev/shm being a bind mount, you could try
    to remount /dev/shm with something like mount -t tmpfs tmpfs /dev/shm,
    and see where it fails next...


Reply to this email directly or view it on GitHubhttps://github.com//issues/364#issuecomment-24293903
.

DennyL@GMail

Collaborator

DennisLfromGA commented Sep 12, 2013

@kyle - Hadn't heard of 'LXC Containers' but after Googling it I think this
concept sounds pretty exciting and promising - 'a chroot on steroids' is
one description. I'll play around with it on a desktop Ubuntu install and
see what happens...

@drinkcat - Are 'croagh' 'c_h_roagh' the same thing? I had a '
croagh:031df18f' quantal chroot installed with kde, unity & xfce a while
back but haven't played with it in a while, I'll tinker with it again too.
If they are different, I'll get the 'chroagh' tarball and try it out.

On Thu, Sep 12, 2013 at 12:04 AM, drinkcat notifications@github.com wrote:

I did a quick try at LXC, but I didn't manage to get it to work on my Arch
laptop, so I got bored of it and gave up (maybe I should try again)...
Instead I went for a lower level approach (dirty branch here:
https://github.com/drinkcat/chroagh/commits/container.tmp), and I managed
to "boot" Arch in a container, directly from Chrome OS. My idea is that it
would be neat to start the crouton chroots in their own containers, so we
can use systemd services, shut down chroots in a cleaner way (processes
belonging to the chroot are clearly separated), control hardware access,
etc.

So, in short, kernel support is available, and it's something I'd really
like to get working. The only issue I have now is that the kernel for
Samsung ARM is still stuck on 3.4, so it lacks some features, like being
able to rejoin an existing container (important for crouton), or create a
new instance of /dev/pts (not so critical for crouton, more so if you
care about container isolation...).

Now, back to LXC, I see 2 options:

  • Compile it statically in a chroot (no idea how difficult that may
    be), and move it to /usr/local/bin in Chrome OS. Chances are it may
    work...
  • Find out what prevents it to work from inside the chroot. It looks
    like it's complaining about /dev/shm being a bind mount, you could try
    to remount /dev/shm with something like mount -t tmpfs tmpfs /dev/shm,
    and see where it fails next...


Reply to this email directly or view it on GitHubhttps://github.com//issues/364#issuecomment-24293903
.

DennyL@GMail

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Sep 13, 2013

Collaborator

@DennisLfromGA :

  • croagh was the name of a branch of crouton, written by @dnschneid, that allows multiple distributions to be supported (currently Debian and Ubuntu). It was merged a few months back now.
  • chroagh is my own repository (https://github.com/drinkcat/chroagh), where I stage branches before pushing them here. The master branch is a fork of crouton, with Arch support, and a few other branches that are not pushed to crouton yet. It should be useable, but is a bit outdated currently as I haven't backported the latest modifications in crouton (I'm waiting for my audio branch to get in before I rebase again).
Collaborator

drinkcat commented Sep 13, 2013

@DennisLfromGA :

  • croagh was the name of a branch of crouton, written by @dnschneid, that allows multiple distributions to be supported (currently Debian and Ubuntu). It was merged a few months back now.
  • chroagh is my own repository (https://github.com/drinkcat/chroagh), where I stage branches before pushing them here. The master branch is a fork of crouton, with Arch support, and a few other branches that are not pushed to crouton yet. It should be useable, but is a bit outdated currently as I haven't backported the latest modifications in crouton (I'm waiting for my audio branch to get in before I rebase again).
@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Sep 13, 2013

Collaborator

@drinkcat, Thanx for clearing that up, I guess I didn't understand exactly
what it was and what David had done with it.

I had downloaded your 'chroagh' repo (7a16b4b) but hadn't installed it and
played with it yet. From reading your comment above '"boot" Arch in a
container, directly from Chrome OS', it sounds a little different from a
'crouton' chroot, can you explain it a little more for me please? I'll wait
until you've rebased again and then give it a whirl.

P.S. I'm due to get my 128GB SSD for my Acer C7 today so I'm excited!

On Fri, Sep 13, 2013 at 10:44 AM, drinkcat notifications@github.com wrote:

@DennisLfromGA https://github.com/DennisLfromGA :

  • croagh was the name of crouton's branch, written by @dnschneidhttps://github.com/dnschneid,
    that allows multiple distributions to be supported (currently Debian and
    Ubuntu). It was merged a few months back now.
  • chroagh is my own repository (https://github.com/drinkcat/chroagh),
    where I stage branches before pushing them here. The master branch is
    a fork of crouton, with Arch support, and a few other branchs that are not
    pushed to crouton yet. It should be useable, but is a bit outdated
    currently as I haven't backported the latest modifications in crouton (I'm
    waiting for my audio branch to get in before I rebase again).


Reply to this email directly or view it on GitHubhttps://github.com//issues/364#issuecomment-24399405
.

DennyL@GMail

Collaborator

DennisLfromGA commented Sep 13, 2013

@drinkcat, Thanx for clearing that up, I guess I didn't understand exactly
what it was and what David had done with it.

I had downloaded your 'chroagh' repo (7a16b4b) but hadn't installed it and
played with it yet. From reading your comment above '"boot" Arch in a
container, directly from Chrome OS', it sounds a little different from a
'crouton' chroot, can you explain it a little more for me please? I'll wait
until you've rebased again and then give it a whirl.

P.S. I'm due to get my 128GB SSD for my Acer C7 today so I'm excited!

On Fri, Sep 13, 2013 at 10:44 AM, drinkcat notifications@github.com wrote:

@DennisLfromGA https://github.com/DennisLfromGA :

  • croagh was the name of crouton's branch, written by @dnschneidhttps://github.com/dnschneid,
    that allows multiple distributions to be supported (currently Debian and
    Ubuntu). It was merged a few months back now.
  • chroagh is my own repository (https://github.com/drinkcat/chroagh),
    where I stage branches before pushing them here. The master branch is
    a fork of crouton, with Arch support, and a few other branchs that are not
    pushed to crouton yet. It should be useable, but is a bit outdated
    currently as I haven't backported the latest modifications in crouton (I'm
    waiting for my audio branch to get in before I rebase again).


Reply to this email directly or view it on GitHubhttps://github.com//issues/364#issuecomment-24399405
.

DennyL@GMail

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Sep 14, 2013

Collaborator

@DennisLfromGA. First off, the container thing will not be in my next rebase, there is still quite a bit of work to be done, and I need to wait for kernel 3.8 to be pushed on the ARM Chromebook to get some important features. On the other hand, you are still welcome to test ArchLinux ,-)

About containers vs chroot:

A normal chroot just changes the root filesystem of the current process. This is by no means secure (there are easy ways to escape), and does not really isolate processes you run in the chroot from the outside.

Namespaces are far more powerful. It's basically a set of kernel features that allows you to separate a set of process from another, very similar to a virtual machine, but without the overhead of that. You can choose at what level you want to isolate the processes: mount, PID, network, user, etc. (see this article for details: https://lwn.net/Articles/531114/). LXC, systemd-nspawn are tools using those features.

My main reason for trying this out is issue drinkcat#8 by @kdb424. systemd, the init system shipped with Archlinux, is not able to start services, like ssh, in a chroot (unlike upstart used by Ubuntu).

By using a PID namespace, you can start a "proper" init process, with PID 1, and you "boot" the system: you see init starting services, and then you get a login prompt: just like when you boot a regular Linux machine. When you are done with the container, you type "halt", and it shuts down, terminating all the processes in the container. So neat and satisfying ,-)

Using a mount namespace is also useful: no more polluting of the output of mount on Chrome OS with lots of bind mounts. And all the mounts are automatically removed when the container shuts down.

Finally, user namespace allows a normal user (chronos on Chrome OS) to be root inside the chroot. I haven't tested that yet (it needs kernel 3.8), but I think that would mean we would not need to add sudo in front of most crouton commands, and would make sure the the chroot could not change kernel settings (stuff in /proc/sys or /sys). This might not be wanted in all cases, though.

UTS namespace would allow a different hostname in chroot. And network namespace could isolate the chroot from the network. Not quite sure why we would want either of that, but we could do it ,-)

In short, quite a bit of potential I think. Still a lot of work to be done to see exactly what it can bring to crouton, and where are the limitations when using some of the namespaces.

Collaborator

drinkcat commented Sep 14, 2013

@DennisLfromGA. First off, the container thing will not be in my next rebase, there is still quite a bit of work to be done, and I need to wait for kernel 3.8 to be pushed on the ARM Chromebook to get some important features. On the other hand, you are still welcome to test ArchLinux ,-)

About containers vs chroot:

A normal chroot just changes the root filesystem of the current process. This is by no means secure (there are easy ways to escape), and does not really isolate processes you run in the chroot from the outside.

Namespaces are far more powerful. It's basically a set of kernel features that allows you to separate a set of process from another, very similar to a virtual machine, but without the overhead of that. You can choose at what level you want to isolate the processes: mount, PID, network, user, etc. (see this article for details: https://lwn.net/Articles/531114/). LXC, systemd-nspawn are tools using those features.

My main reason for trying this out is issue drinkcat#8 by @kdb424. systemd, the init system shipped with Archlinux, is not able to start services, like ssh, in a chroot (unlike upstart used by Ubuntu).

By using a PID namespace, you can start a "proper" init process, with PID 1, and you "boot" the system: you see init starting services, and then you get a login prompt: just like when you boot a regular Linux machine. When you are done with the container, you type "halt", and it shuts down, terminating all the processes in the container. So neat and satisfying ,-)

Using a mount namespace is also useful: no more polluting of the output of mount on Chrome OS with lots of bind mounts. And all the mounts are automatically removed when the container shuts down.

Finally, user namespace allows a normal user (chronos on Chrome OS) to be root inside the chroot. I haven't tested that yet (it needs kernel 3.8), but I think that would mean we would not need to add sudo in front of most crouton commands, and would make sure the the chroot could not change kernel settings (stuff in /proc/sys or /sys). This might not be wanted in all cases, though.

UTS namespace would allow a different hostname in chroot. And network namespace could isolate the chroot from the network. Not quite sure why we would want either of that, but we could do it ,-)

In short, quite a bit of potential I think. Still a lot of work to be done to see exactly what it can bring to crouton, and where are the limitations when using some of the namespaces.

@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Sep 14, 2013

Collaborator

Thanx @drinkcat for the explanation, I'll read through the article you
mentioned and learned a little more about it. Hopefully, the ARM is not too
far away from 3.8, it looks like we non-ARM users are on 3.8.11. The
namespaces and containers do look promising for crouton though, I tried to
change the hostname in a chroot on crouton and it was a disaster.

On Sat, Sep 14, 2013 at 12:12 AM, drinkcat notifications@github.com wrote:

@DennisLfromGA https://github.com/DennisLfromGA. First off, the
container thing will not be in my next rebase, there is still quite a bit
of work to be done, and I need to wait for kernel 3.8 to be pushed on the
ARM Chromebook to get some important features. On the other hand, you are
still welcome to test ArchLinux ,-)

About containers vs chroot:

A normal chroot just changes the root filesystem of the current process.
This is by no means secure (there are easy ways to escape), and does not
really isolate processes you run in the chroot from the outside.

Namespaces are far more powerful. It's basically a set of kernel features
that allows you to separate a set of process from another, very similar to
a virtual machine, but without the overhead of that. You can choose at what
level you want to isolate the processes: mount, PID, network, user, etc.
(see this article for details: https://lwn.net/Articles/531114/). LXC,
systemd-nspawn are tools using those features.

My main reason for trying this out is issue drinkcat#8https://github.com/drinkcat/chroagh/issues/8by
@kdb424 https://github.com/kdb424. systemd, the init system shipped
with Archlinux, is not able to start services, like ssh, in a chroot
(unlike upstart used by Ubuntu).

By using a PID namespace, you can start a "proper" init process, with PID
1, and you "boot" the system: you see init starting services, and then you
get a login prompt: just like when you boot a regular Linux machine. When
you are done with the container, you type "halt", and it shuts down,
terminating all the processes in the container. So neat and satisfying ,-)

Using a mount namespace is also useful: no more polluting of the output of
mount on Chrome OS with lots of bind mounts. And all the mounts are
automatically removed when the container shuts down.

Finally, user namespace allows a normal user (chronos on Chrome OS) to be
root inside the chroot. I haven't tested that yet (it needs kernel 3.8),
but I think that would mean we would not need to add sudo in front of
most crouton commands, and would make sure the the chroot could not change
kernel settings (stuff in /proc/sys or /sys). This might not be wanted in
all cases, though.

UTS namespace would allow a different hostname in chroot. And network
namespace could isolate the chroot from the network. Not quite sure why we
would want either of that, but we could do it ,-)

In short, quite a bit of potential I think. Still a lot of work to be done
to see exactly what it can bring to crouton, and where are the limitations
when using some of the namespaces.


Reply to this email directly or view it on GitHubhttps://github.com//issues/364#issuecomment-24436430
.

DennyL@GMail

Collaborator

DennisLfromGA commented Sep 14, 2013

Thanx @drinkcat for the explanation, I'll read through the article you
mentioned and learned a little more about it. Hopefully, the ARM is not too
far away from 3.8, it looks like we non-ARM users are on 3.8.11. The
namespaces and containers do look promising for crouton though, I tried to
change the hostname in a chroot on crouton and it was a disaster.

On Sat, Sep 14, 2013 at 12:12 AM, drinkcat notifications@github.com wrote:

@DennisLfromGA https://github.com/DennisLfromGA. First off, the
container thing will not be in my next rebase, there is still quite a bit
of work to be done, and I need to wait for kernel 3.8 to be pushed on the
ARM Chromebook to get some important features. On the other hand, you are
still welcome to test ArchLinux ,-)

About containers vs chroot:

A normal chroot just changes the root filesystem of the current process.
This is by no means secure (there are easy ways to escape), and does not
really isolate processes you run in the chroot from the outside.

Namespaces are far more powerful. It's basically a set of kernel features
that allows you to separate a set of process from another, very similar to
a virtual machine, but without the overhead of that. You can choose at what
level you want to isolate the processes: mount, PID, network, user, etc.
(see this article for details: https://lwn.net/Articles/531114/). LXC,
systemd-nspawn are tools using those features.

My main reason for trying this out is issue drinkcat#8https://github.com/drinkcat/chroagh/issues/8by
@kdb424 https://github.com/kdb424. systemd, the init system shipped
with Archlinux, is not able to start services, like ssh, in a chroot
(unlike upstart used by Ubuntu).

By using a PID namespace, you can start a "proper" init process, with PID
1, and you "boot" the system: you see init starting services, and then you
get a login prompt: just like when you boot a regular Linux machine. When
you are done with the container, you type "halt", and it shuts down,
terminating all the processes in the container. So neat and satisfying ,-)

Using a mount namespace is also useful: no more polluting of the output of
mount on Chrome OS with lots of bind mounts. And all the mounts are
automatically removed when the container shuts down.

Finally, user namespace allows a normal user (chronos on Chrome OS) to be
root inside the chroot. I haven't tested that yet (it needs kernel 3.8),
but I think that would mean we would not need to add sudo in front of
most crouton commands, and would make sure the the chroot could not change
kernel settings (stuff in /proc/sys or /sys). This might not be wanted in
all cases, though.

UTS namespace would allow a different hostname in chroot. And network
namespace could isolate the chroot from the network. Not quite sure why we
would want either of that, but we could do it ,-)

In short, quite a bit of potential I think. Still a lot of work to be done
to see exactly what it can bring to crouton, and where are the limitations
when using some of the namespaces.


Reply to this email directly or view it on GitHubhttps://github.com//issues/364#issuecomment-24436430
.

DennyL@GMail

@alexanderkyte

This comment has been minimized.

Show comment
Hide comment
@alexanderkyte

alexanderkyte Sep 16, 2013

Have you considered something like docker? It wraps the lxc subsystem in a pretty nice way.

alexanderkyte commented Sep 16, 2013

Have you considered something like docker? It wraps the lxc subsystem in a pretty nice way.

@TreverN

This comment has been minimized.

Show comment
Hide comment
@TreverN

TreverN Sep 22, 2013

I'm trying to get docker going on my Google I/O Stumpy's.

Docker wants a 3.8 kernel. Looks like Pixel's and Samsung 550's run a 3.8 kernel as of 7/22/2013, but not Stumpy yet.

  1. Anyone on a Pixel or Sammy 550 know if docker with crouton/Ubuntu "just works"? I'm very new to playing with Docker and LXC so I could be naive here...
  2. Anyone know if Chrome OS Beta or Dev is running a 3.8 kernel on Stumpy? Or does anyone know when 3.8 kernel will come to hardware (if it will) other than Pixel's and 550s?

Thanks...

Later: Answered #2 myself, dev channel is using 3.8.11. Will report back when I've answered #1...

TreverN commented Sep 22, 2013

I'm trying to get docker going on my Google I/O Stumpy's.

Docker wants a 3.8 kernel. Looks like Pixel's and Samsung 550's run a 3.8 kernel as of 7/22/2013, but not Stumpy yet.

  1. Anyone on a Pixel or Sammy 550 know if docker with crouton/Ubuntu "just works"? I'm very new to playing with Docker and LXC so I could be naive here...
  2. Anyone know if Chrome OS Beta or Dev is running a 3.8 kernel on Stumpy? Or does anyone know when 3.8 kernel will come to hardware (if it will) other than Pixel's and 550s?

Thanks...

Later: Answered #2 myself, dev channel is using 3.8.11. Will report back when I've answered #1...

@alexanderkyte

This comment has been minimized.

Show comment
Hide comment
@alexanderkyte

alexanderkyte Sep 23, 2013

The Samsung arm chromebook still appears to be on 3.4.

On Sun, Sep 22, 2013 at 12:50 AM, TreverN notifications@github.com wrote:

I'm trying to get docker going on my Google I/O Stumpy's.

Docker wants a 3.8 kernel. Looks like Pixel's and Samsung 550's run a 3.8
kernel as of 7/22/2013, but not Stumpy yet.

Anyone on a Pixel or Sammy 550 know if docker with crouton/Ubuntu
"just works"? I'm very new to playing with Docker and LXC so I could be
naive here...
2.

Anyone know if Chrome OS Beta or Dev is running a 3.8 kernel on
Stumpy? Or does anyone know when 3.8 kernel will come to hardware (if it
will) other than Pixel's and 550s?

Thanks...


Reply to this email directly or view it on GitHubhttps://github.com//issues/364#issuecomment-24876085
.

alexanderkyte commented Sep 23, 2013

The Samsung arm chromebook still appears to be on 3.4.

On Sun, Sep 22, 2013 at 12:50 AM, TreverN notifications@github.com wrote:

I'm trying to get docker going on my Google I/O Stumpy's.

Docker wants a 3.8 kernel. Looks like Pixel's and Samsung 550's run a 3.8
kernel as of 7/22/2013, but not Stumpy yet.

Anyone on a Pixel or Sammy 550 know if docker with crouton/Ubuntu
"just works"? I'm very new to playing with Docker and LXC so I could be
naive here...
2.

Anyone know if Chrome OS Beta or Dev is running a 3.8 kernel on
Stumpy? Or does anyone know when 3.8 kernel will come to hardware (if it
will) other than Pixel's and 550s?

Thanks...


Reply to this email directly or view it on GitHubhttps://github.com//issues/364#issuecomment-24876085
.

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Sep 24, 2013

Owner

Eventually all devices will be on 3.8, but it will be a while.

Owner

dnschneid commented Sep 24, 2013

Eventually all devices will be on 3.8, but it will be a while.

@alexanderkyte

This comment has been minimized.

Show comment
Hide comment
@alexanderkyte

alexanderkyte Sep 24, 2013

Is there an easy way to test out 3.8 on one of the older devices?
On Sep 23, 2013 8:46 PM, "David Schneider" notifications@github.com wrote:

Eventually all devices will be on 3.8, but it will be a while.


Reply to this email directly or view it on GitHubhttps://github.com//issues/364#issuecomment-24967388
.

alexanderkyte commented Sep 24, 2013

Is there an easy way to test out 3.8 on one of the older devices?
On Sep 23, 2013 8:46 PM, "David Schneider" notifications@github.com wrote:

Eventually all devices will be on 3.8, but it will be a while.


Reply to this email directly or view it on GitHubhttps://github.com//issues/364#issuecomment-24967388
.

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Sep 25, 2013

Owner

Switching to dev channel is the easiest, assuming it has 3.8 enabled for dev channel. Otherwise you'd have to compile chromium yourself.

Owner

dnschneid commented Sep 25, 2013

Switching to dev channel is the easiest, assuming it has 3.8 enabled for dev channel. Otherwise you'd have to compile chromium yourself.

@alexanderkyte

This comment has been minimized.

Show comment
Hide comment
@alexanderkyte

alexanderkyte commented Nov 26, 2013

Docker no longer requires a kernel to have aufs compiled into it.

http://blog.docker.io/2013/11/docker-0-7-docker-now-runs-on-any-linux-distribution/

@ccaapton

This comment has been minimized.

Show comment
Hide comment
@ccaapton

ccaapton Dec 30, 2013

It seems that most chromebooks are using kernel >= 3.8. Is there any plan to utilize PID/user/mount namespaces?

BTW, I think the stock wrapper, /sbin/minijail0 is very capable. It seems to support mount(including bind)/network/pid namespaces. But I'm not shure if it can be used by non-root user.

ccaapton commented Dec 30, 2013

It seems that most chromebooks are using kernel >= 3.8. Is there any plan to utilize PID/user/mount namespaces?

BTW, I think the stock wrapper, /sbin/minijail0 is very capable. It seems to support mount(including bind)/network/pid namespaces. But I'm not shure if it can be used by non-root user.

@jpw1116

This comment has been minimized.

Show comment
Hide comment
@jpw1116

jpw1116 Dec 30, 2013

Hmm. I have been checking daily for weeks for any updates pushed down the pipe but my Samsung Snowy (ARM v7) is still at 3.4.0. I'm hesitant to go upstream with associated risk.

jpw1116 commented Dec 30, 2013

Hmm. I have been checking daily for weeks for any updates pushed down the pipe but my Samsung Snowy (ARM v7) is still at 3.4.0. I'm hesitant to go upstream with associated risk.

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm Dec 30, 2013

Contributor

Yes, stable on the ARM is still 3.4. I've been battling the dev channel and crouton for awhile, so yesterday I power washed, and reverted to stable, so far crouton, with chromium, and xfce targets on default precise release are working very well.

Contributor

tedm commented Dec 30, 2013

Yes, stable on the ARM is still 3.4. I've been battling the dev channel and crouton for awhile, so yesterday I power washed, and reverted to stable, so far crouton, with chromium, and xfce targets on default precise release are working very well.

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Jan 1, 2014

Collaborator

It looks like ARM may get 3.8 soon, I see kernel 3.8.11 being built in the Chromium OS builders:
http://build.chromium.org/p/chromiumos/builders/daisy%20full/builds/6104/steps/BuildPackages/logs/stdio
So it looks like it's just a matter of time until 3.8 appears on the dev channel (if it's not already there).

Collaborator

drinkcat commented Jan 1, 2014

It looks like ARM may get 3.8 soon, I see kernel 3.8.11 being built in the Chromium OS builders:
http://build.chromium.org/p/chromiumos/builders/daisy%20full/builds/6104/steps/BuildPackages/logs/stdio
So it looks like it's just a matter of time until 3.8 appears on the dev channel (if it's not already there).

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm Jan 1, 2014

Contributor

Yes, I think you're right @drinkcat - I had to powerwash and revert to stable, as even the most basic crouton functions weren't working on the dev channel. After reverting to stable, crouton (xfce, chromium) on precise works well. I expect that the dev channel will be upgraded soon, as there were a multitude of other issues, such as extension flags not being preserved, and random crashes, (more than usual) ... I wonder what the beta channel is like ? I'm surprised at the lack of testing on ARM systems, as it's by far the most popular platform for the Chromebooks, from the data I"ve seen.

Contributor

tedm commented Jan 1, 2014

Yes, I think you're right @drinkcat - I had to powerwash and revert to stable, as even the most basic crouton functions weren't working on the dev channel. After reverting to stable, crouton (xfce, chromium) on precise works well. I expect that the dev channel will be upgraded soon, as there were a multitude of other issues, such as extension flags not being preserved, and random crashes, (more than usual) ... I wonder what the beta channel is like ? I'm surprised at the lack of testing on ARM systems, as it's by far the most popular platform for the Chromebooks, from the data I"ve seen.

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Jan 1, 2014

Owner

Dev channel is testing.

Owner

dnschneid commented Jan 1, 2014

Dev channel is testing.

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm Jan 1, 2014

Contributor

right. But basic functionality, IMHO, such as extensions and flags still working, ctrl-keys in crosh behaving, not crashing frequently, should generally be supported in a dev channel. Again, IMHO.

Contributor

tedm commented Jan 1, 2014

right. But basic functionality, IMHO, such as extensions and flags still working, ctrl-keys in crosh behaving, not crashing frequently, should generally be supported in a dev channel. Again, IMHO.

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm Jan 3, 2014

Contributor

@dnschneid and all: I apologize for complaining about my issues with the Dev channel. I should be grateful that for almost a year, I was able to function ok with Crouton while running in it, and shouldn't have taken that for granted.

Thank you for retaining Crouton support for those of us on the Samsung ARM, whose stable channel is kernel 3.4.0 and may be so for a while.

Crouton has probably been the most useful software ever for Chromebook users. Thanks David, Drinkcat, and all Crouton developers.

Contributor

tedm commented Jan 3, 2014

@dnschneid and all: I apologize for complaining about my issues with the Dev channel. I should be grateful that for almost a year, I was able to function ok with Crouton while running in it, and shouldn't have taken that for granted.

Thank you for retaining Crouton support for those of us on the Samsung ARM, whose stable channel is kernel 3.4.0 and may be so for a while.

Crouton has probably been the most useful software ever for Chromebook users. Thanks David, Drinkcat, and all Crouton developers.

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Jan 3, 2014

Owner

@tedm it sounds like beta channel would be ideal for you; it's a pretty happy medium between stability and previewing new features.

Owner

dnschneid commented Jan 3, 2014

@tedm it sounds like beta channel would be ideal for you; it's a pretty happy medium between stability and previewing new features.

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm Jan 3, 2014

Contributor

Yeah, beta would probably be fine to move to for me, and also since USB sticks, and catching up, aren't needed to change channels anymore on the arm, just powerwashes, it's now simpler to change channels.

If the desktop environments, or the clipboard extensions are ARM ready, I'm ready to test those.

Contributor

tedm commented Jan 3, 2014

Yeah, beta would probably be fine to move to for me, and also since USB sticks, and catching up, aren't needed to change channels anymore on the arm, just powerwashes, it's now simpler to change channels.

If the desktop environments, or the clipboard extensions are ARM ready, I'm ready to test those.

@air

This comment has been minimized.

Show comment
Hide comment
@air

air Jan 14, 2014

On my Acer C720 Chromebook (reports kernel 3.8.11 with uname -r), I have the docker 0.7.5 daemon running in a crouton chroot with Ubuntu raring. I'm using

sudo docker -d -b none

However I can't yet start a container. Current error is

$ sudo docker run -i -t ubuntu /bin/bash
WARNING: IPv4 forwarding is disabled.
lxc-start: No such file or directory - failed to create '/sys/fs/cgroup/cpu/lxc' directory
lxc-start: failed to spawn '6e7d451def231c2eb1f6ec84fbdac605f69d9a799d196135fb82f49ee187997c'
[error] commands.go:2458 Error getting size: bad file descriptor

air commented Jan 14, 2014

On my Acer C720 Chromebook (reports kernel 3.8.11 with uname -r), I have the docker 0.7.5 daemon running in a crouton chroot with Ubuntu raring. I'm using

sudo docker -d -b none

However I can't yet start a container. Current error is

$ sudo docker run -i -t ubuntu /bin/bash
WARNING: IPv4 forwarding is disabled.
lxc-start: No such file or directory - failed to create '/sys/fs/cgroup/cpu/lxc' directory
lxc-start: failed to spawn '6e7d451def231c2eb1f6ec84fbdac605f69d9a799d196135fb82f49ee187997c'
[error] commands.go:2458 Error getting size: bad file descriptor
@air

This comment has been minimized.

Show comment
Hide comment
@air

air Jan 14, 2014

The issue appears to be that ChromeOS can see the mounts under /sys/fs/cgroup, but the chroot OS cannot. In ChromeOS:

chronos@localhost / $ mount|grep cgroup
none on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
chronos@localhost / $ ls -l /sys/fs/cgroup
total 0
drwxr-xr-x 4 root root 0 Jan 14 14:29 cpu
drwxr-xr-x 2 root root 0 Jan 14 14:29 freeze

Whereas in Ubuntu raring chroot:

(raring)air@localhost:~/dev$ mount|grep cgroup
(raring)air@localhost:~/dev$ ls -l /sys/fs/cgroup
total 0

I see that /usr/local/chroots/raring/proc is empty, so I assume the chroot inherits the mounts from ChromeOS.

@dnschneid, sorry for my ignorance - could take a moment to explain why the cpu and freezer mounts under cgroup don't make it into the chroot? Hopefully this isn't a blocker for the whole Docker approach.

air commented Jan 14, 2014

The issue appears to be that ChromeOS can see the mounts under /sys/fs/cgroup, but the chroot OS cannot. In ChromeOS:

chronos@localhost / $ mount|grep cgroup
none on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
chronos@localhost / $ ls -l /sys/fs/cgroup
total 0
drwxr-xr-x 4 root root 0 Jan 14 14:29 cpu
drwxr-xr-x 2 root root 0 Jan 14 14:29 freeze

Whereas in Ubuntu raring chroot:

(raring)air@localhost:~/dev$ mount|grep cgroup
(raring)air@localhost:~/dev$ ls -l /sys/fs/cgroup
total 0

I see that /usr/local/chroots/raring/proc is empty, so I assume the chroot inherits the mounts from ChromeOS.

@dnschneid, sorry for my ignorance - could take a moment to explain why the cpu and freezer mounts under cgroup don't make it into the chroot? Hopefully this isn't a blocker for the whole Docker approach.

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Jan 16, 2014

Owner

@air: /sys isn't mounted recursively, nor is it mounted shared such that new mounts will appear inside the chroot.
Try doing something similar to the /media mount in enter-chroot. You'd probably want chroot /sys to be a slave mount of the system /sys, so you'd --make-rshared /sys, then --rbind it in, then --make-rslave the chroot's /sys.

Owner

dnschneid commented Jan 16, 2014

@air: /sys isn't mounted recursively, nor is it mounted shared such that new mounts will appear inside the chroot.
Try doing something similar to the /media mount in enter-chroot. You'd probably want chroot /sys to be a slave mount of the system /sys, so you'd --make-rshared /sys, then --rbind it in, then --make-rslave the chroot's /sys.

@air

This comment has been minimized.

Show comment
Hide comment
@air

air Jan 16, 2014

Thanks @dnschneid, I patched my enter-chroot to set up a slaved /sys space:

# Bind-mount /sys recursively in order to get working cgroups
echo "Mounting /sys recursively"
mount --make-rshared /sys
mount --rbind /sys "$CHROOT/sys"
mount --make-rslave /sys "$CHROOT/sys"

This works - inside the chroot we can now see /sys/fs/cgroup/cpu and all the contents. We no longer fail on the filesystem error.

This brings us to the next error, a 'device busy' from lxc-start:

(raring)air@localhost:~/dev$ sudo docker run -i -t ubuntu /bin/bash 
WARNING: IPv4 forwarding is disabled.
lxc-start: Device or resource busy - failed to mount a new instance of '/dev/pts'
lxc-start: failed to setup the new pts instance
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn '6e282af6df4d902fcf7bf26aed756d354f99a0ddcde718bb3a72593bf80da32b'
[error] commands.go:2458 Error getting size: bad file descriptor

I'd like to run lxc-checkconfig but this currently returns

Kernel configuration not found at /proc/config.gz; searching...
lxc-checkconfig: unable to retrieve kernel configuration
Try recompiling with IKCONFIG_PROC, installing the kernel headers,
or specifying the kernel configuration path with:
  CONFIG=<path> lxc-checkconfig

So next step is perhaps to sanity check that LXC is capable of running anything. Any advice appreciated : )

air commented Jan 16, 2014

Thanks @dnschneid, I patched my enter-chroot to set up a slaved /sys space:

# Bind-mount /sys recursively in order to get working cgroups
echo "Mounting /sys recursively"
mount --make-rshared /sys
mount --rbind /sys "$CHROOT/sys"
mount --make-rslave /sys "$CHROOT/sys"

This works - inside the chroot we can now see /sys/fs/cgroup/cpu and all the contents. We no longer fail on the filesystem error.

This brings us to the next error, a 'device busy' from lxc-start:

(raring)air@localhost:~/dev$ sudo docker run -i -t ubuntu /bin/bash 
WARNING: IPv4 forwarding is disabled.
lxc-start: Device or resource busy - failed to mount a new instance of '/dev/pts'
lxc-start: failed to setup the new pts instance
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn '6e282af6df4d902fcf7bf26aed756d354f99a0ddcde718bb3a72593bf80da32b'
[error] commands.go:2458 Error getting size: bad file descriptor

I'd like to run lxc-checkconfig but this currently returns

Kernel configuration not found at /proc/config.gz; searching...
lxc-checkconfig: unable to retrieve kernel configuration
Try recompiling with IKCONFIG_PROC, installing the kernel headers,
or specifying the kernel configuration path with:
  CONFIG=<path> lxc-checkconfig

So next step is perhaps to sanity check that LXC is capable of running anything. Any advice appreciated : )

@air

This comment has been minimized.

Show comment
Hide comment
@air

air Jan 17, 2014

So lxc-checkconfig isn't going to work because it's looking for kernel headers. For example it attempts this file read (found with strace), /lib/modules/3.8.11/build/.config. If this was ordinary Ubuntu (not in a chroot) we would just apt-get install linux-headers-generic and the 3.8.11 package would get placed in that location.

However with ChromeOS as the host, we are running a non-Ubuntu kernel 3.8.11, from Google. Ubuntu does not have headers for non-Ubuntu kernels, so apt-get is not going to help.

It does appear possible to get ChromeOS kernel headers by building them, but it looks a bit hairy: http://superuser.com/questions/657845/cannot-install-3-4-linux-headers-on-acer-c7-chromebook-running-chrubuntu-12-04

I will give up on lxc-checkconfig for now.

air commented Jan 17, 2014

So lxc-checkconfig isn't going to work because it's looking for kernel headers. For example it attempts this file read (found with strace), /lib/modules/3.8.11/build/.config. If this was ordinary Ubuntu (not in a chroot) we would just apt-get install linux-headers-generic and the 3.8.11 package would get placed in that location.

However with ChromeOS as the host, we are running a non-Ubuntu kernel 3.8.11, from Google. Ubuntu does not have headers for non-Ubuntu kernels, so apt-get is not going to help.

It does appear possible to get ChromeOS kernel headers by building them, but it looks a bit hairy: http://superuser.com/questions/657845/cannot-install-3-4-linux-headers-on-acer-c7-chromebook-running-chrubuntu-12-04

I will give up on lxc-checkconfig for now.

@air

This comment has been minimized.

Show comment
Hide comment
@air

air Jan 20, 2014

OK, so I didn't give up quite yet : ) Here's the output of CONFIG=/usr/src/linux-headers-3.8.11/.config lxc-checkconfigon a fresh chroot (with no cgroup binding yet - observe 'required' below):

--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: missing

--- Control groups ---
Cgroup: enabled
Cgroup namespace: required
Cgroup device: missing
Cgroup sched: enabled
Cgroup cpu account: missing
Cgroup memory controller: missing
Cgroup cpuset: missing

--- Misc ---
Veth pair device: enabled
Macvlan: missing
Vlan: missing
File capabilities: enabled

To get the magic .config file I
built the kernel headers as described in the crouton wiki. Note that I didn't bother making the linux-image, just the headers. This gets you the file linux-headers-3.8.11_3.8.11-10.00.Custom_amd64.deb which you install with dpkg.

air commented Jan 20, 2014

OK, so I didn't give up quite yet : ) Here's the output of CONFIG=/usr/src/linux-headers-3.8.11/.config lxc-checkconfigon a fresh chroot (with no cgroup binding yet - observe 'required' below):

--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: missing

--- Control groups ---
Cgroup: enabled
Cgroup namespace: required
Cgroup device: missing
Cgroup sched: enabled
Cgroup cpu account: missing
Cgroup memory controller: missing
Cgroup cpuset: missing

--- Misc ---
Veth pair device: enabled
Macvlan: missing
Vlan: missing
File capabilities: enabled

To get the magic .config file I
built the kernel headers as described in the crouton wiki. Note that I didn't bother making the linux-image, just the headers. This gets you the file linux-headers-3.8.11_3.8.11-10.00.Custom_amd64.deb which you install with dpkg.

@air

This comment has been minimized.

Show comment
Hide comment
@air

air Jan 20, 2014

You don't have to fully build the Linux headers to get the config file to check against. The only step you need is make oldconfig as described in the wiki (only takes a few seconds versus many minutes for the headers). This generates a .config at which you can point lxc-checkconfig.

It looks like the LXC tool is just checking flags in the config. So e.g. Multiple /dev/pts instances: missing is just reporting that in the config, # CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set.

Could someone more expert comment on what this means, maybe @ccaapton or @dnschneid? My interpretation here is that features required for LXC are simply not compiled into the ChromeOS kernel (3.8 branch); so LXC cannot function on Chromebooks. Is that correct?

air commented Jan 20, 2014

You don't have to fully build the Linux headers to get the config file to check against. The only step you need is make oldconfig as described in the wiki (only takes a few seconds versus many minutes for the headers). This generates a .config at which you can point lxc-checkconfig.

It looks like the LXC tool is just checking flags in the config. So e.g. Multiple /dev/pts instances: missing is just reporting that in the config, # CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set.

Could someone more expert comment on what this means, maybe @ccaapton or @dnschneid? My interpretation here is that features required for LXC are simply not compiled into the ChromeOS kernel (3.8 branch); so LXC cannot function on Chromebooks. Is that correct?

@perpen

This comment has been minimized.

Show comment
Hide comment
@perpen

perpen May 31, 2015

This pm I got an archlinux/systemd chroot running using nsinit, with mount/ipc/uts/pid namespaces. nsinit is a utility which comes with libcontainer, the low-level lib docker uses to create containers.
I am running a custom kernel but looking at the config for the standard Chrome OS kernel it seems to have all the basic namespacing stuff enabled - so I am not expecting problems with a vanilla crouton system.
I'm going on hols soon but after that I'll try making a PoC replacement for the current chroot mechanism.

perpen commented May 31, 2015

This pm I got an archlinux/systemd chroot running using nsinit, with mount/ipc/uts/pid namespaces. nsinit is a utility which comes with libcontainer, the low-level lib docker uses to create containers.
I am running a custom kernel but looking at the config for the standard Chrome OS kernel it seems to have all the basic namespacing stuff enabled - so I am not expecting problems with a vanilla crouton system.
I'm going on hols soon but after that I'll try making a PoC replacement for the current chroot mechanism.

@ccaapton

This comment has been minimized.

Show comment
Hide comment
@ccaapton

ccaapton Jun 3, 2015

@perpen Did you try nsinit in unprivileged mode, aka uid_map/gid_map stuff? I'm quite interested in running everything without root. I tried nsinit a couple of times with the stock kernel(C720 on 3.8.11) without luck.

Currently I'm running everything unprivileged with "unshare -Umpf" on stock kernel with some custom scripts(pivot_root etc). Most stuff works, including Xserver, but it is kind of adhoc.

ccaapton commented Jun 3, 2015

@perpen Did you try nsinit in unprivileged mode, aka uid_map/gid_map stuff? I'm quite interested in running everything without root. I tried nsinit a couple of times with the stock kernel(C720 on 3.8.11) without luck.

Currently I'm running everything unprivileged with "unshare -Umpf" on stock kernel with some custom scripts(pivot_root etc). Most stuff works, including Xserver, but it is kind of adhoc.

@bendavis78

This comment has been minimized.

Show comment
Hide comment
@bendavis78

bendavis78 Jun 6, 2015

@perpen, could you post the container.json you used with nsinit?

bendavis78 commented Jun 6, 2015

@perpen, could you post the container.json you used with nsinit?

@olofj

This comment has been minimized.

Show comment
Hide comment
@olofj

olofj Jun 11, 2015

Hi,

Just a quick heads up here about recent changes in the Chrome OS kernel. We've enabled some of the needed options to run Docker/LXC on R45 (current ToT).

We've only enabled this on kernel versions 3.14 and 3.18. Container support isn't deemed solid in kernels before that, so unfortunately those platforms won't see it enabled.

For reference, the platforms running the 3.14 kernel are Rockchip, the 2015 Chromebook Pixel and other Broadwell-based Chromebooks.

olofj commented Jun 11, 2015

Hi,

Just a quick heads up here about recent changes in the Chrome OS kernel. We've enabled some of the needed options to run Docker/LXC on R45 (current ToT).

We've only enabled this on kernel versions 3.14 and 3.18. Container support isn't deemed solid in kernels before that, so unfortunately those platforms won't see it enabled.

For reference, the platforms running the 3.14 kernel are Rockchip, the 2015 Chromebook Pixel and other Broadwell-based Chromebooks.

@Watney

This comment has been minimized.

Show comment
Hide comment
@Watney

Watney Jun 11, 2015

kaboom@olofj you're da bomb!

Watney commented Jun 11, 2015

kaboom@olofj you're da bomb!

@mathuin

This comment has been minimized.

Show comment
Hide comment
@mathuin

mathuin Jun 15, 2015

Is there any chance that these kernel versions will trickle down to current ARM-based Chromebooks?

mathuin commented Jun 15, 2015

Is there any chance that these kernel versions will trickle down to current ARM-based Chromebooks?

@olofj

This comment has been minimized.

Show comment
Hide comment
@olofj

olofj Jun 15, 2015

Is there any chance that these kernel versions will trickle down to
current ARM-based Chromebooks?

There are no plans to update to newer kernels on existing platforms. But
that's off topic for this thread.

Note that the recently introduced RK3288-based Chromebooks run 3.14.

olofj commented Jun 15, 2015

Is there any chance that these kernel versions will trickle down to
current ARM-based Chromebooks?

There are no plans to update to newer kernels on existing platforms. But
that's off topic for this thread.

Note that the recently introduced RK3288-based Chromebooks run 3.14.

@perpen

This comment has been minimized.

Show comment
Hide comment
@perpen

perpen Jun 18, 2015

@olofj I'm really excited about your news, can't wait to try it!

@ccaapton no I didn't try uid remapping, I suppose we could remap chronos to root but I'm not sure about the benefit? I would quite like being able to load modules from the container for example (although I didn't test that).
Did you get xiwi working? That's where I got stuck, as iirc the chroot-side process was trying to communicate with the chrome side via /proc/<pid>/maps, which obv. doesn't work with the pid namespace.

@bendavis78 for the container config I have been using you can have a look at https://github.com/perpen/chromeos-nsinit. As I said earlier I did not test nsinit with the vanilla kernel, so if you try it please let me know the result.

perpen commented Jun 18, 2015

@olofj I'm really excited about your news, can't wait to try it!

@ccaapton no I didn't try uid remapping, I suppose we could remap chronos to root but I'm not sure about the benefit? I would quite like being able to load modules from the container for example (although I didn't test that).
Did you get xiwi working? That's where I got stuck, as iirc the chroot-side process was trying to communicate with the chrome side via /proc/<pid>/maps, which obv. doesn't work with the pid namespace.

@bendavis78 for the container config I have been using you can have a look at https://github.com/perpen/chromeos-nsinit. As I said earlier I did not test nsinit with the vanilla kernel, so if you try it please let me know the result.

@tonyxue

This comment has been minimized.

Show comment
Hide comment
@tonyxue

tonyxue Jun 19, 2015

Contributor

@olofj That's a good news. And it's nice to see you show up here to tell us that. :)

Contributor

tonyxue commented Jun 19, 2015

@olofj That's a good news. And it's nice to see you show up here to tell us that. :)

@wenlock

This comment has been minimized.

Show comment
Hide comment
@wenlock

wenlock Jun 27, 2015

wondering if anyone has written a howto for this yet? with latest docker, here is how far i get

sudo docker -d --storage-driver=vfs --iptables=false -g ~/data/docker
WARN[0000] You are running linux kernel version 3.8.11, which might be unstable running docker. Please upgrade your kernel to 3.10.0.
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
WARN[0000] Running modprobe bridge nf_nat failed with message: , error: exit status 1
WARN[0000] Your kernel does not support cgroup memory limit: mountpoint for memory not found
FATA[0000] Error mounting devices cgroup: mountpoint for devices not found

Any ideas on how to solve the cgroup mount error?

and with -D output

sudo docker -d --storage-driver=vfs --iptables
=false -g ~/data/docker -D
DEBU[0000] Registering GET, /containers/{name:.}/top
DEBU[0000] Registering GET, /containers/{name:.
}/stats
DEBU[0000] Registering GET, /info
DEBU[0000] Registering GET, /version
DEBU[0000] Registering GET, /containers/ps
DEBU[0000] Registering GET, /images/get
DEBU[0000] Registering GET, /images/{name:.}/get
DEBU[0000] Registering GET, /images/{name:.
}/history
DEBU[0000] Registering GET, /images/{name:.}/json
DEBU[0000] Registering GET, /ping
DEBU[0000] Registering GET, /events
DEBU[0000] Registering GET, /images/json
DEBU[0000] Registering GET, /containers/{name:.
}/changes
DEBU[0000] Registering GET, /containers/{name:.
}/logs
DEBU[0000] Registering GET, /exec/{id:.}/json
DEBU[0000] Registering GET, /containers/{name:.
}/json
DEBU[0000] Registering GET, /containers/{name:.}/attach/ws
DEBU[0000] Registering GET, /images/search
DEBU[0000] Registering GET, /containers/json
DEBU[0000] Registering GET, /containers/{name:.
}/export
DEBU[0000] Registering POST, /build
DEBU[0000] Registering POST, /containers/{name:.}/wait
DEBU[0000] Registering POST, /containers/{name:.
}/attach
DEBU[0000] Registering POST, /containers/{name:.}/copy
DEBU[0000] Registering POST, /containers/{name:.
}/exec
DEBU[0000] Registering POST, /exec/{name:.}/start
DEBU[0000] Registering POST, /auth
DEBU[0000] Registering POST, /images/create
DEBU[0000] Registering POST, /images/load
DEBU[0000] Registering POST, /images/{name:.
}/push
DEBU[0000] Registering POST, /images/{name:.}/tag
DEBU[0000] Registering POST, /containers/{name:.
}/pause
DEBU[0000] Registering POST, /containers/{name:.}/rename
DEBU[0000] Registering POST, /commit
DEBU[0000] Registering POST, /containers/{name:.
}/restart
DEBU[0000] Registering POST, /exec/{name:.}/resize
DEBU[0000] Registering POST, /containers/{name:.
}/unpause
DEBU[0000] Registering POST, /containers/{name:.}/kill
DEBU[0000] Registering POST, /containers/{name:.
}/start
DEBU[0000] Registering POST, /containers/{name:.}/stop
DEBU[0000] Registering POST, /containers/{name:.
}/resize
DEBU[0000] Registering POST, /containers/create
DEBU[0000] Registering DELETE, /containers/{name:._}
DEBU[0000] Registering DELETE, /images/{name:.*}
DEBU[0000] Registering OPTIONS,
WARN[0000] You are running linux kernel version 3.8.11, which might be unstable running docker. Please upgrade your kernel to 3.10.0.
DEBU[0000] [graphdriver] trying provided driver "vfs"
DEBU[0000] Using graph driver vfs
DEBU[0000] Using default logging driver json-file
DEBU[0000] Creating images graph
DEBU[0000] Restored 0 elements
DEBU[0000] Creating repository list
DEBU[0000] docker group found. gid: 999
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
WARN[0000] Running modprobe bridge nf_nat failed with message: , error: exit status 1
DEBU[0000] /sbin/iptables, [--wait -t nat -D PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT -m addrtype --dst-type LOCAL ! --dst 127.0.0.0/8 -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D PREROUTING]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT]
DEBU[0000] /sbin/iptables, [--wait -t nat -F DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -X DOCKER]
WARN[0000] Your kernel does not support cgroup memory limit: mountpoint for memory not found
FATA[0000] Error mounting devices cgroup: mountpoint for devices not found

I've been using docker in virtualbox on my chrombook for a bit, and would love to be able to move out of virtualbox.

sudo docker version
Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64

wenlock commented Jun 27, 2015

wondering if anyone has written a howto for this yet? with latest docker, here is how far i get

sudo docker -d --storage-driver=vfs --iptables=false -g ~/data/docker
WARN[0000] You are running linux kernel version 3.8.11, which might be unstable running docker. Please upgrade your kernel to 3.10.0.
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
WARN[0000] Running modprobe bridge nf_nat failed with message: , error: exit status 1
WARN[0000] Your kernel does not support cgroup memory limit: mountpoint for memory not found
FATA[0000] Error mounting devices cgroup: mountpoint for devices not found

Any ideas on how to solve the cgroup mount error?

and with -D output

sudo docker -d --storage-driver=vfs --iptables
=false -g ~/data/docker -D
DEBU[0000] Registering GET, /containers/{name:.}/top
DEBU[0000] Registering GET, /containers/{name:.
}/stats
DEBU[0000] Registering GET, /info
DEBU[0000] Registering GET, /version
DEBU[0000] Registering GET, /containers/ps
DEBU[0000] Registering GET, /images/get
DEBU[0000] Registering GET, /images/{name:.}/get
DEBU[0000] Registering GET, /images/{name:.
}/history
DEBU[0000] Registering GET, /images/{name:.}/json
DEBU[0000] Registering GET, /ping
DEBU[0000] Registering GET, /events
DEBU[0000] Registering GET, /images/json
DEBU[0000] Registering GET, /containers/{name:.
}/changes
DEBU[0000] Registering GET, /containers/{name:.
}/logs
DEBU[0000] Registering GET, /exec/{id:.}/json
DEBU[0000] Registering GET, /containers/{name:.
}/json
DEBU[0000] Registering GET, /containers/{name:.}/attach/ws
DEBU[0000] Registering GET, /images/search
DEBU[0000] Registering GET, /containers/json
DEBU[0000] Registering GET, /containers/{name:.
}/export
DEBU[0000] Registering POST, /build
DEBU[0000] Registering POST, /containers/{name:.}/wait
DEBU[0000] Registering POST, /containers/{name:.
}/attach
DEBU[0000] Registering POST, /containers/{name:.}/copy
DEBU[0000] Registering POST, /containers/{name:.
}/exec
DEBU[0000] Registering POST, /exec/{name:.}/start
DEBU[0000] Registering POST, /auth
DEBU[0000] Registering POST, /images/create
DEBU[0000] Registering POST, /images/load
DEBU[0000] Registering POST, /images/{name:.
}/push
DEBU[0000] Registering POST, /images/{name:.}/tag
DEBU[0000] Registering POST, /containers/{name:.
}/pause
DEBU[0000] Registering POST, /containers/{name:.}/rename
DEBU[0000] Registering POST, /commit
DEBU[0000] Registering POST, /containers/{name:.
}/restart
DEBU[0000] Registering POST, /exec/{name:.}/resize
DEBU[0000] Registering POST, /containers/{name:.
}/unpause
DEBU[0000] Registering POST, /containers/{name:.}/kill
DEBU[0000] Registering POST, /containers/{name:.
}/start
DEBU[0000] Registering POST, /containers/{name:.}/stop
DEBU[0000] Registering POST, /containers/{name:.
}/resize
DEBU[0000] Registering POST, /containers/create
DEBU[0000] Registering DELETE, /containers/{name:._}
DEBU[0000] Registering DELETE, /images/{name:.*}
DEBU[0000] Registering OPTIONS,
WARN[0000] You are running linux kernel version 3.8.11, which might be unstable running docker. Please upgrade your kernel to 3.10.0.
DEBU[0000] [graphdriver] trying provided driver "vfs"
DEBU[0000] Using graph driver vfs
DEBU[0000] Using default logging driver json-file
DEBU[0000] Creating images graph
DEBU[0000] Restored 0 elements
DEBU[0000] Creating repository list
DEBU[0000] docker group found. gid: 999
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
WARN[0000] Running modprobe bridge nf_nat failed with message: , error: exit status 1
DEBU[0000] /sbin/iptables, [--wait -t nat -D PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT -m addrtype --dst-type LOCAL ! --dst 127.0.0.0/8 -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D PREROUTING]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT]
DEBU[0000] /sbin/iptables, [--wait -t nat -F DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -X DOCKER]
WARN[0000] Your kernel does not support cgroup memory limit: mountpoint for memory not found
FATA[0000] Error mounting devices cgroup: mountpoint for devices not found

I've been using docker in virtualbox on my chrombook for a bit, and would love to be able to move out of virtualbox.

sudo docker version
Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64

@vevmesteren

This comment has been minimized.

Show comment
Hide comment
@vevmesteren

vevmesteren Nov 8, 2015

Given that there was no answer since June 27th I guess we shouldn't be holding our breath for LXC to come to life inside a crouton chroot? No major architectural overhaul planned by chance. Will use chroot to code but will probably need to lxc-start my containers on a seperate box...can't give up on the sheer speed this chrome os chroot combo offers...

vevmesteren commented Nov 8, 2015

Given that there was no answer since June 27th I guess we shouldn't be holding our breath for LXC to come to life inside a crouton chroot? No major architectural overhaul planned by chance. Will use chroot to code but will probably need to lxc-start my containers on a seperate box...can't give up on the sheer speed this chrome os chroot combo offers...

@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Jun 21, 2016

Collaborator

An interesting question has been posed in the 'Chromium OS Discuss forum' - Docker support in kernel.
Since it may depend on kernel 3.10+, it won't work on a lot of the older Chromebooks but it'll be interesting to see what the Developers say about it.

Collaborator

DennisLfromGA commented Jun 21, 2016

An interesting question has been posed in the 'Chromium OS Discuss forum' - Docker support in kernel.
Since it may depend on kernel 3.10+, it won't work on a lot of the older Chromebooks but it'll be interesting to see what the Developers say about it.

@cat-turner

This comment has been minimized.

Show comment
Hide comment
@cat-turner

cat-turner Nov 21, 2016

Did anyone get this working? I have chrome book pixel, which is supposedly supported by the update. I am on the beta channel, do I have to get on the dev channel for this? I can
t seem to find a way to get it working.

cat-turner commented Nov 21, 2016

Did anyone get this working? I have chrome book pixel, which is supposedly supported by the update. I am on the beta channel, do I have to get on the dev channel for this? I can
t seem to find a way to get it working.

@HLFH

This comment has been minimized.

Show comment
Hide comment
@HLFH

HLFH Nov 21, 2016

In fact, Chrome OS is an obsolete platform. Google gave up on developers a long time ago. Let's see what it will be with the Andromeda project. But IMHO, you will lose less time by migrating to Linux/macOS/Windows platforms.

HLFH commented Nov 21, 2016

In fact, Chrome OS is an obsolete platform. Google gave up on developers a long time ago. Let's see what it will be with the Andromeda project. But IMHO, you will lose less time by migrating to Linux/macOS/Windows platforms.

@cat-turner

This comment has been minimized.

Show comment
Hide comment
@cat-turner

cat-turner Nov 21, 2016

@HLFH bummer, I really liked working in it. It's been good. I got by working on c9 and crouton crust for a while but now I need to get real work done. Welp, guess I'm going with Linux. I'm diving into Linux Mint on my old PC.

cat-turner commented Nov 21, 2016

@HLFH bummer, I really liked working in it. It's been good. I got by working on c9 and crouton crust for a while but now I need to get real work done. Welp, guess I'm going with Linux. I'm diving into Linux Mint on my old PC.

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid
Owner

dnschneid commented Nov 21, 2016

[citation needed]

@cat-turner

This comment has been minimized.

Show comment
Hide comment
@cat-turner

cat-turner Nov 21, 2016

I thought this is their way of getting developers to use their google cloud platform? I get it, but I can't pay into that. Maybe if their next chromebook/andromedia-like machine included X years of cloud support on it, but that still doesn't address the problem of dev needs being met secondarily. It's getting in the way of my work trying to find work around, but it's part of the dev life I suppose.

cat-turner commented Nov 21, 2016

I thought this is their way of getting developers to use their google cloud platform? I get it, but I can't pay into that. Maybe if their next chromebook/andromedia-like machine included X years of cloud support on it, but that still doesn't address the problem of dev needs being met secondarily. It's getting in the way of my work trying to find work around, but it's part of the dev life I suppose.

@HLFH

This comment has been minimized.

Show comment
Hide comment
@HLFH

HLFH Nov 21, 2016

@dnschneid Chrome Dev Editor is discontinued. No Arch Linux support for Crouton. And apparently, Google gave up not only on developers but also on the American people: Eric Schmidt & Google were supporting the globalist Clinton: we've seen a lot of people showing evidence that Google Search was biased in favor of Hillary Clinton during the Democratic Party presidential primaries, and during the US presidential election.

HLFH commented Nov 21, 2016

@dnschneid Chrome Dev Editor is discontinued. No Arch Linux support for Crouton. And apparently, Google gave up not only on developers but also on the American people: Eric Schmidt & Google were supporting the globalist Clinton: we've seen a lot of people showing evidence that Google Search was biased in favor of Hillary Clinton during the Democratic Party presidential primaries, and during the US presidential election.

@fwip

This comment has been minimized.

Show comment
Hide comment
@fwip

fwip Nov 21, 2016

I think that this is not the appropriate forum for your political complaints.

fwip commented Nov 21, 2016

I think that this is not the appropriate forum for your political complaints.

@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Nov 21, 2016

Collaborator

Chrome Dev Editor is discontinued. No Arch Linux support for Crouton. ≠ Chrome OS is an obsolete platform

Collaborator

DennisLfromGA commented Nov 21, 2016

Chrome Dev Editor is discontinued. No Arch Linux support for Crouton. ≠ Chrome OS is an obsolete platform

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Nov 21, 2016

Owner

I was mostly just disappointed that no political candidate made a platform of pushing a timeline for crouton to use containers, and that nobody in the media commented on the candidates' preferred proportion of salad to croutons. Priorities, people!

Owner

dnschneid commented Nov 21, 2016

I was mostly just disappointed that no political candidate made a platform of pushing a timeline for crouton to use containers, and that nobody in the media commented on the candidates' preferred proportion of salad to croutons. Priorities, people!

@vevmesteren

This comment has been minimized.

Show comment
Hide comment
@vevmesteren

vevmesteren Nov 21, 2016

The media conspirators just didn't pay attention. LOCK THEM UP!

image

vevmesteren commented Nov 21, 2016

The media conspirators just didn't pay attention. LOCK THEM UP!

image

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm Nov 22, 2016

Contributor

I don't see the big deal about lxc containers. Few chromebooks are powerful enough to really use containers and VMs IMHO. On an i7 desktop with 16GB of RAM, I use docker and core os, and virtualbox, but I wouldn't see a big use of these on chromebooks.

I'm waiting for my Toshiba 2 to be able to run Android apps. It's not a deal killer if it doesn't, as this doesn't have a touch screen.

I read that Trump (uggh) uses a Samsung phone, but his staffers use iphones. I am not sure what I'm going to get after my Nexus 6, but probably not the Pixel, just too pricey. I like the security of the iphones, but not a big apple fan either.

Contributor

tedm commented Nov 22, 2016

I don't see the big deal about lxc containers. Few chromebooks are powerful enough to really use containers and VMs IMHO. On an i7 desktop with 16GB of RAM, I use docker and core os, and virtualbox, but I wouldn't see a big use of these on chromebooks.

I'm waiting for my Toshiba 2 to be able to run Android apps. It's not a deal killer if it doesn't, as this doesn't have a touch screen.

I read that Trump (uggh) uses a Samsung phone, but his staffers use iphones. I am not sure what I'm going to get after my Nexus 6, but probably not the Pixel, just too pricey. I like the security of the iphones, but not a big apple fan either.

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm Nov 22, 2016

Contributor

re: arch - I got my Pine64 1.2Ghz / 1GB computer, only like 6 months after I paid for it... anyways, I was bummed that there was little Arch support for it, as that is what I would want to. But a BSP and version called Longsheep ubuntu loaded right up, and works fine. It's at work now as a dedicated nInvaders character based game system. Not bad for $19.00.

Contributor

tedm commented Nov 22, 2016

re: arch - I got my Pine64 1.2Ghz / 1GB computer, only like 6 months after I paid for it... anyways, I was bummed that there was little Arch support for it, as that is what I would want to. But a BSP and version called Longsheep ubuntu loaded right up, and works fine. It's at work now as a dedicated nInvaders character based game system. Not bad for $19.00.

@tonyxue

This comment has been minimized.

Show comment
Hide comment
@tonyxue

tonyxue Nov 29, 2016

Contributor

Uh, this long and old thread pops up again.
I'd say Chrome OS isn't obsolete at all. Manufacturers are still building better and higher-end chromebooks.

Containers probably won't be possible on chromebooks in the short run as the hardware limitations and, more importantly, if containers are directly available on chromebook one day, we probably won't need crouton any more.

Contributor

tonyxue commented Nov 29, 2016

Uh, this long and old thread pops up again.
I'd say Chrome OS isn't obsolete at all. Manufacturers are still building better and higher-end chromebooks.

Containers probably won't be possible on chromebooks in the short run as the hardware limitations and, more importantly, if containers are directly available on chromebook one day, we probably won't need crouton any more.

@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Nov 29, 2016

Collaborator

@tonyxue,

I don't want to add too much more to this old thread but some recent development has added some fuel to it, inadvertantly maybe.

Containers probably won't be possible on chromebooks in the short run as the hardware limitations

In fact ARC++ is Android apps (Google Play) in a container on CrOS and it works extremely well, my Dell Chromebook 13 uses it almost flawlessly. I say almost because 'nougat' hasn't hit yet which allows resizing windows and such.

and, more importantly, if containers are directly available on chromebook one day, we probably won't need crouton any more.

Agree, probably not using chroots but hopefully something similar in a container.

Just my 2 cents,
-DennisL

Collaborator

DennisLfromGA commented Nov 29, 2016

@tonyxue,

I don't want to add too much more to this old thread but some recent development has added some fuel to it, inadvertantly maybe.

Containers probably won't be possible on chromebooks in the short run as the hardware limitations

In fact ARC++ is Android apps (Google Play) in a container on CrOS and it works extremely well, my Dell Chromebook 13 uses it almost flawlessly. I say almost because 'nougat' hasn't hit yet which allows resizing windows and such.

and, more importantly, if containers are directly available on chromebook one day, we probably won't need crouton any more.

Agree, probably not using chroots but hopefully something similar in a container.

Just my 2 cents,
-DennisL

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment