# About the Multi CPU Architecture category

**URL:** <https://travis-ci.community/t/about-the-multi-cpu-architecture-category/5336>\
**Category:** Multi CPU Architecture\
**Created:** [October 7, 2019, 2:56pm UTC](https://travis-ci.community/t/about-the-multi-cpu-architecture-category/5336 "2019-10-07T14:56:51Z")\
**Posts on this page:** 8\
**Page:** 2

<div class="post-metadata">

**Author:** ![Yikun](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/yikun/32/3297_2.png) [@Yikun](https://travis-ci.community/u/Yikun)\
**Post date:** [December 2, 2019, 9:27am UTC](https://travis-ci.community/t/about-the-multi-cpu-architecture-category/5336/21 "2019-12-02T09:27:46Z")

</div>

Hi, this is wanderful! It’s greate to have aarch64 support in Travis.

I try to test it for Apache Storm, but I found a swapon related problem on the aarch64 arch, I do the same thing with x86:

```
sudo dd if=/dev/zero of=/swapfile.img bs=4096 count=1M
sudo chmod 0600 /swapfile.img
sudo mkswap /swapfile.img
sudo swapon /swapfile.img

```

but I got the “swapon: /swapfile.img: skipping - it appears to have holes.”.

After some investigation, I found that the filesystem of aarch64 in travis is “shiftfs”[2], but the x86 is “ext4”[3].

So do we have some way to set the file system to ext4 in travis aarch64 arch? or any idea on how to do swapon in current travis aarch64 arch?

[1] [https://travis-ci.org/Yikun/arm-openlab-test/jobs/619518155#L81](https://travis-ci.org/Yikun/arm-openlab-test/jobs/619518155#L81)  
[2] [https://travis-ci.org/Yikun/arm-openlab-test/jobs/619518155#L59](https://travis-ci.org/Yikun/arm-openlab-test/jobs/619518155#L59)  
[3] [https://travis-ci.org/Yikun/arm-openlab-test/jobs/619518159#L218](https://travis-ci.org/Yikun/arm-openlab-test/jobs/619518159#L218)

---

<div class="post-metadata">

**Author:** ![Michal](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/michal/32/2848_2.png) [@Michal](https://travis-ci.community/u/Michal)\
**Post date:** [January 8, 2020, 6:03pm UTC](https://travis-ci.community/t/about-the-multi-cpu-architecture-category/5336/22 "2020-01-08T18:03:14Z")

</div>

@illume

This one was, as it appears, by design - until the job reaches ‘cancellable’ state, the cancel button should not appear.  
Some fixes were done on refreshing the view and while job is reaching the ‘cancellable’ state, pending icon/animation should appear now.

---

<div class="post-metadata">

**Author:** ![Michal](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/michal/32/2848_2.png) [@Michal](https://travis-ci.community/u/Michal)\
**Post date:** [January 8, 2020, 6:06pm UTC](https://travis-ci.community/t/about-the-multi-cpu-architecture-category/5336/23 "2020-01-08T18:06:06Z")

</div>

Hi @Yikun!

Thanks for testing arm out and the report! Would you mind moving it as a thread to the [https://travis-ci.community/c/environments/multi-cpu-arch/96](https://travis-ci.community/c/environments/multi-cpu-arch/96) ? This would help to keep question and answers organized for searches.

On file system change - I am afraid it’s nothing you can do from `.travis.yml` . Keeping such a thread open may allow other users to see if they have demand for the same feature.

---

<div class="post-metadata">

**Author:** ![Michal](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/michal/32/2848_2.png) [@Michal](https://travis-ci.community/u/Michal)\
**Post date:** [January 8, 2020, 6:08pm UTC](https://travis-ci.community/t/about-the-multi-cpu-architecture-category/5336/24 "2020-01-08T18:08:07Z")

</div>

Hi @nigelhorne

Thanks for testing out Arm builds! If the issue persists, would you mind to move it as a thread to [https://travis-ci.community/c/environments/multi-cpu-arch/96](https://travis-ci.community/c/environments/multi-cpu-arch/96) and provide link to the build job that actually resulted in that failure? Not much can be done on the error message itself.

---

<div class="post-metadata">

**Author:** ![Michal](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/michal/32/2848_2.png) [@Michal](https://travis-ci.community/u/Michal)\
**Post date:** [January 8, 2020, 6:11pm UTC](https://travis-ci.community/t/about-the-multi-cpu-architecture-category/5336/25 "2020-01-08T18:11:07Z")

</div>

Hi @mjnovice

Thanks for testing!  
Java setup may be still missing, so if a Java packet needed, please install relevant package in `before_install` step and make sure environmental variables are set correctly.

---

<div class="post-metadata">

**Author:** ![piponazo](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/piponazo/32/4765_2.png) [@piponazo](https://travis-ci.community/u/piponazo)\
**Post date:** [June 10, 2020, 6:29am UTC](https://travis-ci.community/t/about-the-multi-cpu-architecture-category/5336/27 "2020-06-10T06:29:27Z")

</div>

Hi all!

First of all, thank you for this great addition to travis-ci. It is really useful for open source software maintainers ❤.

I would like to share that I noticed something that made me some headaches as a maintainer of a C++ project. The CMake version used in the ARM64 and AMD64 images seems to be different:

- ARM64 images uses: cmake version 3.5.1
- AMD64 images uses: cmake version 3.12.4

Why this difference? CMake is the main configuration system used by C++ projects nowadays, and it would avoid issues to have the same version in both images.

Best regards,  
Luis

---

<div class="post-metadata">

**Author:** ![bkimminich](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/bkimminich/32/2114_2.png) [@bkimminich](https://travis-ci.community/u/bkimminich)\
**Post date:** [June 12, 2020, 10:12pm UTC](https://travis-ci.community/t/about-the-multi-cpu-architecture-category/5336/28 "2020-06-12T22:12:11Z")

</div>

+1 for the fact that `arm64` builds are offered. For my project [https://travis-ci.com/github/bkimminich/juice-shop](https://travis-ci.com/github/bkimminich/juice-shop) they work fine for running an `npm install` of a not-so-small project. All good there!

-1 when trying to build a Docker image on `arm64`. A job doing a `docker build` and `push` that takes \<10min on `amd64` is continually running into timeouts on `arm64`. Sometimes I get a timeout before the `docker build` is even starting. Sometimes it gets into the build part but then starves at some point.

I could live with `arm64` builds being 10 times slower than `amd64` as long as I end up with a successfully built and published Docker image. But even `travis_wait` didn’t do the trick for me. As mentioned, the timeout occurs sometimes even before any of my scripts has been launched.

Are there any performance improvements planned for `arm64`? Or at least doing x3 on the default timeout? The way it works now, I can’t use it unfortunately, but I really would love to avoid a CI/CD setup with two providers. I had that in the past, but when Travis-CI introduced Windows jobs, I dropped my extra AppVeyor jobs in favor of it.

(see [https://github.com/bkimminich/juice-shop/issues/1404](https://github.com/bkimminich/juice-shop/issues/1404) for some more information)

---

<div class="post-metadata">

**Author:** ![native-api](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/native-api/32/430_2.png) [@native-api](https://travis-ci.community/u/native-api)\
**Post date:** [October 23, 2020, 11:55pm UTC](https://travis-ci.community/t/about-the-multi-cpu-architecture-category/5336/29 "2020-10-23T23:55:21Z")

</div>



[Previous page](https://travis-ci.community/t/about-the-multi-cpu-architecture-category/5336.md?page=1)
