Ubuntu 15.10!

[s5bug]

Ubuntu 15.10 is being "released". Support would be nice 😸

[1rocketdude]

probably same challenges as 15.04. That whole systemd thing. Would be great, but someone smarter than I needs to attack it.

[s5bug]

Um... what systemd thing... 😕

[bdshaffer73]

Anyone know if there's foreseeable support for 15.10, or do we have to wait for the next LTS release?

[tonyxue]

It is the systemd matter. Systemd requires its PID to be 1 but we cannot do that for a chroot as we have Chrome OS already started with its init process occupying PID1.

The foreseeable support is when Chrome OS update all stable version kernels to 3.8. Only unstable channel of some hardware is on 3.8 right now. 3.8 provides PID Namespace and we can create a separate PID namespace which everything starts with PID 1 for the chroot. Then systemd would work.

However, if that's happening , we probably don't even need chroot anymore.

If you are interested in PID namespace, see the pull request: https://marc.info/?l=linux-kernel&m=135526066121436&w=2

[s5bug]

Whoah. How would you NOT need a chroot? My mouth is permanently open right
now. I have my chrome book on dev channel, so HOW would I do that?
On Nov 2, 2015 11:19 AM, "Tony Xue" [email protected] wrote:

It is the systemd matter. Systemd requires its PID to be 1 but we cannot
do that for a chroot as we have Chrome OS already started with its init
process occupying PID1.

The foreseeable support is when Chrome OS update all stable version
kernels to 3.8. Only unstable channel of some hardware is on 3.8 right now.
3.8 provides PID Namespace which we can create a separate PID namespace
which everything starts with PID 1 for the chroot. Then systemd would work.

However, if that's happening , we don't even need chroot anymore.

If you are interested in PID namespace, see the pull request:
https://marc.info/?l=linux-kernel&m=135526066121436&w=2

—
Reply to this email directly or view it on GitHub
#1817 (comment).

[bdshaffer73]

Thanks @tonyxue! I'm curious as to how Chrome OS works.. I've been wanting to move to Chrubuntu to overcome some of the limitations of the Chrome kernel but it sounds that's even harder, and I have no idea why.

[bdshaffer73]

@tonyxue Just read through that pull request.. That was way over my head but I think I got the gist of the message, agreeing with what you said. Still, very advanced work.

[mark-hahn]

How would you NOT need a chroot?

My curiosity is set on stun also.

On Mon, Nov 2, 2015 at 5:24 PM, bdshaffer73 [email protected]
wrote:

@tonyxue https://github.com/tonyxue Just read through that pull
request.. That was way over my head but I think I got the gist of the
message, agreeing with what you said. Still, very advanced work.

—
Reply to this email directly or view it on GitHub
#1817 (comment).

[dnschneid]

crouton would use containers instead of the chroot command. You still need the same kind of stuff. See #364

[mark-hahn]

I noticed that thread petered out in June. Does this mean there is less
interest in it now?

I have a question. LXC offers greater security through isolation. What is
the practical advantage of this over chroot? It can't be for system
security because once you go into developer mode you chromebook is insecure
by nature.

Also, why would I want to have less access to chromeos? I want to have the
power to do anything I want up to and including screwing everything up. It
is my machine.

On Tue, Nov 3, 2015 at 7:57 AM, David Schneider [email protected]
wrote:

crouton would use containers instead of the chroot command. You still need
the same kind of stuff. See #364
#364

—
Reply to this email directly or view it on GitHub
#1817 (comment).

[tonyxue]

I noticed that thread petered out in June. Does this mean there is less
interest in it now?

I think it's more of now we're waiting for 3.8 to be universal.

I have a question. LXC offers greater security through isolation. What is
the practical advantage of this over chroot? It can't be for system
security because once you go into developer mode you chromebook is insecure
by nature.

You have a more isolated environment so if you have a ubuntu installed, things work more like they do in a 'direct' ubuntu environment. I believe it would be more helpful when you're building up development environments. I personally believe it would be more or less similar to the usage of Vagrant as people want a completely independent and isolated dev environment that can be configured in the same standard quickly and can be destroyed easily.

Also, why would I want to have less access to chromeos?

Well, I don't think chroot will be then completely gone. So if you want the connection between two environments, you can still use chroot.

[mark-hahn]

Thanks. Makes sense.

On Tue, Nov 3, 2015 at 12:21 PM, Tony Xue [email protected] wrote:

I noticed that thread petered out in June. Does this mean there is less
interest in it now?

I think it's more of now we're waiting for 3.8 to be universal.

I have a question. LXC offers greater security through isolation. What is
the practical advantage of this over chroot? It can't be for system
security because once you go into developer mode you chromebook is insecure
by nature.

You have a more isolated environment so if you have a ubuntu installed,
things work more like they do in a 'direct' ubuntu environment. I believe
it would be more helpful when you're building up development environments.
I personally believe it would be more or less similar to the usage of
Vagrant as people want a completely independent and isolated dev
environment that can be configured in the same standard quickly and can be
destroyed easily.

Also, why would I want to have less access to chromeos?

Well, I don't think chroot will be then completely gone. So if you want
the connection between two environments, you can still use chroot.

—
Reply to this email directly or view it on GitHub
#1817 (comment).

[1rocketdude]

having ChromeOS and a distinct linux environment that is switchable using the Vulcan death grip is the magic of crouton. My hope is that 15.04 or 16.04 is supported. I'm willing to be the guinea pig. I may need a new Chromebook as I doubt kernel 3.8 will ever be ported to a lumpy chromebook.

thanks for all the great tools. Makes life enjoyable.

[bdshaffer73]

having ChromeOS and a distinct linux environment that is switchable using the Vulcan death grip is the magic of crouton.

I agree, although emphasis on "distinct". I'm finding it difficult to add persistent configurations that are specific to my setup. So far, it seems having a standalone installation inside a sandbox would solve my issues. Unfortunately, I have no idea how to do that, but Crouton is pretty close to it.

thanks for all the great tools. Makes life enjoyable.

Agreed!

[mmoren]

One can get Wily with systemd to work using PID namespacing. A kernel with CONFIG_PID_NS is required. I don't know how common this is, but kernel 3.14 on my 2015 Pixel has it.

Something like jchroot is needed to perform the PID namespace change. When we have that, we can start systemd inside a wily root as pid 1:

sudo mount-chroot wily
sudo jchroot /run/crouton/mnt/stateful_partition/crouton/chroots/wily /bin/systemd

Unfortunately, when running the second command, the touchpad or keyboard stops working. Possibly #1994 happens. I work around it by running these in a VT following them by a sudo restart ui, but I
guess plugging in an external mouse should work as well.

With this running in one window, we can open another and enter the chroot:

sudo nsenter -t $(pidof systemd) -p -m -u -r

In there, a pretty "complete" Wily is running, with systemd for starting and stopping services etc. We can even cleanly shut down the chroot by running systemctl poweroff. After stopping everything systemd exits, allowing one to run unmount-chroot wily without hassle.

[s5bug]

@sn0e I noticed sometimes when I'm creating a new chroot I can only use my touchpad and nothing else (laptop keyboard, external keyboards/mice) and I have to use the onscreen keyboard. Possibly linked?

[mmoren]

@firestar115 I've since found out that it does not happen if all systemd-udev* services are masked (disabled) before entering the chroot. I've worked a bit more on this and added it to enter-chroot in PR #2474

[dnschneid]

I think this is duplicate with the xenial stuff.