Open brightzheng100 opened 2 years ago
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: https://github.com/weaveworks/footloose/pull/272
Just tried it on my new Mac with M1 chip but failed because of CPU arch:
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?