weaveworks / footloose

Container Machines - Containers that look like Virtual Machines

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Any available images on Mac with M1 chip?

brightzheng100 opened this issue · comments

Just tried it on my new Mac with M1 chip but failed because of CPU arch:

$ footloose create -c ubuntu18.04-1.yaml
INFO[0001] Pulling image: quay.io/footloose/ubuntu18.04 ...
INFO[0019] Creating machine: sandbox-ubuntu-0 ...
INFO[0019] Connecting sandbox-ubuntu-0 to the footloose-cluster network...
FATA[0019] failed to get container id, output did not match: [WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested 580e6f523af29e99d345561137eb3ab2c988da2d45a6e27562fd4d40f447b952]

Before building my own images, just wanted to have a check whether there are some available images for Mac with M1 chip, or arm64/aarch64 arch?

Rebuilt the image with:

FROM arm64v8/ubuntu:18.04
...

And I could spin up the cluster but couldn't ssh into it -- the SSH service was not properly bootstrapped.

$ cat ubuntu18.04-1-arm64.yaml
cluster:
  name: sandbox
  privateKey: cluster-key
machines:
- count: 1
  spec:
    image: brightzheng100/footloose-ubuntu18:arm64
    name: ubuntu-%d
    networks:
    - footloose-cluster
    portMappings:
    - containerPort: 22
    privileged: true
    volumes:
    - type: volume
      destination: /var

$ footloose create -c ubuntu18.04-1-arm64.yaml
$ footloose start -c ubuntu18.04-1-arm64.yaml
$ footloose show -c ubuntu18.04-1-arm64.yaml
NAME               HOSTNAME   PORTS           IP   IMAGE                                     CMD          STATE     BACKEND
sandbox-ubuntu-0   ubuntu-0   0->{22 49154}        brightzheng100/footloose-ubuntu18:arm64   /sbin/init   Running

$ footloose ssh ubuntu-0 -c ubuntu18.04-1-arm64.yaml
kex_exchange_identification: Connection closed by remote host
Connection closed by 127.0.0.1 port 49154
FATA[0000] exit status 255

Of course, since it's just a Docker container, I still could docker exec into it.
While further checking, I realized that the systemd might not be running properly:

$ docker exec -it sandbox-ubuntu-0 bash

root@ubuntu-0:/# systemctl list-units
System has not been booted with systemd as init system (PID 1). Can't operate.

root@ubuntu-0:/# ls /etc/systemd/system/
console-getty.service                  dev-hugepages.mount      multi-user.target.wants        sysinit.target.wants            timers.target.wants
dbus-org.freedesktop.resolve1.service  getty.target.wants       sshd.service                   systemd-tmpfiles-setup.service
default.target                         instana-agent.service.d  sys-fs-fuse-connections.mount  systemd-update-utmp.service

I just figured out the root cause which is related to cgroups compatibility issues.

The workaround is to remove one line of these parameters, like this:

	runArgs := []string{
		"-it",
		"--label", "works.weave.owner=footloose",
		"--label", "works.weave.cluster=" + c.spec.Cluster.Name,
		"--name", name,
		"--hostname", machine.Hostname(),
		"--tmpfs", "/run",
		"--tmpfs", "/run/lock",
		"--tmpfs", "/tmp:exec,mode=777",
		//"-v", "/sys/fs/cgroup:/sys/fs/cgroup:ro",
	}

I'm thinking to dive deeper into cgroups and see whether a PR may make sense.

I believe the cgroup issue you are seeing is fixed with this PR: #272