LXC containers?

[kzahel]

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]

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]

@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]

@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]

@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]

@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]

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]

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

[TreverN]

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]

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]

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

[alexanderkyte]

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]

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]

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]

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]

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]

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]

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]

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]

Dev channel is testing.

[tedm]

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]

@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]

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

[tedm]

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]

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]

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]

@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]

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]

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]

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]

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?

[bendavis78]

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

[olofj]

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]

kaboom — @olofj you're da bomb!

[mathuin]

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

[olofj]

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]

@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]

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

[sfc-gh-eraigosa]

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]

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]

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]

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]

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]

@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]

[citation needed]

[cat-turner]

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]

@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]

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

[DennisLfromGA]

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

[dnschneid]

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]

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

[tedm]

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]

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]

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]

@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