-
Notifications
You must be signed in to change notification settings - Fork 40
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
make user failed on MacBook Pro with Apple M1 chipset #40
Comments
This looks like your user does not have permission to build docker images. It might have to be in the Have you been able to build/run any other docker images like the ones from the getting-started guide at docker? |
It's OK with my docker environment.robbie.wu@MBFVFG30ELQ6LW seL4-CAmkES-L4v-dockerfiles % docker run -d -p 80:80 docker/getting-started |
It's also OK to build a getting-started images:robbie.wu@MBFVFG30ELQ6LW GettingStarted % vscode app Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them A tool to scan your images Options: Testing getting-started... Package manager: apk ✓ Tested 38 dependencies for known vulnerabilities, no vulnerable paths found. For more free scans that keep your images secure, sign up to Snyk at https://dockr.ly/3ePqVcp |
Interesting. Does |
Ok, I was able to reproduce the problem, and it appears specific to docker buildkit on the M1. The following worked for me as a workaround:
(and then |
I'm not sure how well docker works yet on the M1, at least when running x86 containers. Last time I checked, support for that was experimental and I had plenty of crashes from docker when I tried, but there is hope that things have improved significantly in since then. |
It does NOT work for me.robbie.wu@MBFVFG30ELQ6LW seL4-CAmkES-L4v-dockerfiles % docker run -ti --entrypoint bash trustworthysystems/sel4 |
it does NOT work for me too.robbie.wu@MBFVFG30ELQ6LW seL4-CAmkES-L4v-dockerfiles % export DOCKER_BUILDLOT=0
|
Sorry, autocorrect typo. It should be
|
So this one looks successful to me, but the deciding bit would be the next line after this. For me it is:
i.e. if you see that, at that point you are inside the docker container. |
still does not work.robbie.wu@MBFVFG30ELQ6LW seL4-CAmkES-L4v-dockerfiles % export DOCKER_BUILDKIT=0
Removing intermediate container ea8a1e164d5d |
I think the issue is the base image, which is for linux/amd64, could you try to provide the Dockerfile from the universal image? |
Error processing tar file(exit status 1): write /var/log/lastlog: no
space left on device
This implies your computer may have run out of disk space.
Try clearing out some of the images listed under `docker image ls`
|
We do not support building on ARM host machines, so I don't think we can build that image. The amd64 image does work for me on the M1, though.
Well spotted, I think this is correct. Looking at the rest of the trace, the build is proceeding as expected and got over the initial problem. I think we're close to getting it to work. |
Yes, "./build.sh -b sel4 -r -v" does NOT work.
Cannot get any clue. robbie.wu@MBFVFG30ELQ6LW log % df -h |
looks like there should be space available. Maybe it is the docker container volume that is out of space, not the host. I'm assuming you're using Docker Desktop on the Mac. Could you open the preferences of Docker Desktop, and in the Resources panel increase the Disk image size to something very large (200GB) and then try (I would leave CPU on 2 and memory should not need more than 8GB) |
Still container is out of space. robbie.wu@MBFVFG30ELQ6LW seL4-CAmkES-L4v-dockerfiles % make user
|
Hm, getting towards the end of my docker knowledge. It's using cached images, so it might not pick up on the new size yet. https://stackoverflow.com/questions/30604846/docker-error-no-space-left-on-device suggests to run
|
still container is out space。 |
I'm out of ideas for now. Might try to precisely duplicate your settings later and see if that also runs out of space for me. @LukeMondy do you have an idea what could be going on? |
Oh, actually: looking at your screenshot of the resources panel, it does say 198.1 GB of 200 GB used, so it is extremely close to full even with 200GB. Try increasing it all the way. |
when entering into the container, it hung at the "chmod -R ug+rw /home/robbie.wu" for more than 3 minutes, then got the out of space error, maybe the container was crashing repeatedly, tried to capture the crash dumps. |
Still strange that it crashes, but I don't really have many more options to try. Does the smaller
|
It does not work too.
|
Any update about this issue? Does the error happen only for @robbiewu008 or can somebody else reproduce this? |
I have the same problem. The difference is that i use the debian through Parallels Desktop to simulate on my m1 pro. I get the warning |
This sounds like a different problem. Are you saying you are also getting the same out-of-disk-space error afterwards? |
I was able to get applications building by compiling the Docker containers for an ARM host, but I had issues specifically with For the emulation route, using this
|
I was able to compile the containers for ARM. If there is sufficient interest I can push up a branch with some admittedly ugly changes. |
I'd be interested to at least look at the necessary changes. Maybe we can make them less ugly. Do these changes break the x86 build or do we get images for both architectures? |
I am able to compile for x86 and ARM! I opened an issue in musllibc here For the seL4 kernel, I only needed to make this change (I know the code is a bit outdated, but it was the same when I pulled the camkes-manifest fresh)
For whatever reason, the I forked the repo and pushed a branch here. Some of the changes are necessary, others aren't, especially if/when the fixes for The biggest trick was updating the packages for an Arm host, but I found the right combination eventually. I'd love to get everything mainlined, as I think the M1 Mac is a popular software development platform |
This bit I can explain: inside the container, the host is Linux, not Apple, so it wouldn't set that variable there. But the |
That makes sense. I was a bit confused because Please let me know if you need any help or if you want me to make a PR on |
@lsf37 Any update? I noticed there were a lot of MacBook users at the Summit, so just wondering if the Docker container will officially support M1 Macs anytime soon |
@Ivan-Velickovic was working on M1 support for the containers and got most of it working apart from Haskell stack. @Ivan-Velickovic any update on that? |
Yeah, I had to pull down a tarball since the Haskell install script didn't support ARM hosts. |
No, I couldn't figure out. It seems like other people also have this issue (e.g commercialhaskell/stack#5734) but there seems to be no resolution. It's probably better to go with @chrisguikema changes to get an ARM container working rather than adding another layer of software to do x86 to ARM translation. |
I also made a PR in the seL4 kernel repo to address to x86 cross-compiler issue. @Ivan-Velickovic are you seeing the issue with
|
When I use your patch to get an ARM image (chrisguikema@144bfe1), I still get an x86_64 Linux container. Not sure what's going on. |
Just to clarify, you aren't pulling down prebuilts from Dockerhub, right? Specifying the |
Hi, are there any news regarding the best practises in building seL4 on Apple Silicon Macs? I think we'd all hope to be able to do fully native > docker arm image > docker x86 image (performance wise on the mac), however right now I'm struggling with even running the sel4test example on docker x86 images. They build (with some tweaks to the Makefile), but running Oddly, compiling for an arm target in the x86 docker container seems to run the tests fine. If I then run I've also noticed that things seem to compile fine (natively on M1) by just adapting the date parameter of touch to |
What is the specific error you're seeing with compiling the Docker containers for ARM? |
Sorry @chrisguikema, I was in the wrong branch! All compiling fine now. Although I do see the same thing as @Ivan-Velickovic, although docker metadata reports an arm image, all the binaries inside are x86 and Out of curiosity I ran this (very anecdotal, not at all scientific) benchmark: Compile and simulate
I'd be curious to see if maybe this is related the ARM images still having x86 binaries. |
Interesting. Here is my
|
Ah, I built it again from a fresh docker installation and it probably cleared whatever cache was pulling an x86 base image. I have updated the table with the new figures (much better!) The new results show a massive improvement in using the ARM images. Simulating time is almost on part with native, and compile time is only about 5x slower (when using Apple virt), as opposed to 7x. |
#65 is adding ARM64 variants of all of the base images we have. It's not a full multi-arch image yet that you can pull from docker hub, but you should now be able to build native containers for Apple Silicon as well as the the normal Intel/AMD containers. Multi-arch images will be the next step once this works properly in CI. |
The text was updated successfully, but these errors were encountered: