I think 14.04 is closer to 2.12 than 16.04

I think it's not that important for AArch64 specifically, it's more something we have to careful with for x86

@alessandrogario so .. flags.cmake or glbals.cmake ? 🙂

I copied the packages generated from the a1.metal instance to my rpi3! Terminal output in the reply

BTW. Is it worth doing a "release" with the aarch64 support ?

There's a request in place to give you AWS creds, @seph what's the status ?

I have re-built the 4.6.0 packages from scratch; they were initially uploaded in #core but it appears they never ended up linked in the osquery.io page. I'll take a look at how to upload them there so we can update them

BPF-based eventing will however not be perfect 😞 I'm sure there's something wrong in the kernel, as the problem can be easily reproduced with BCC

@alessandrogario were you able to figure out how to upload 4.6?

I feel like I’m jousting at windmills. but https://github.com/directionless/osquery/runs/2104618800?check_suite_focus=true ran on a self hosted arm64 machine. (no where near automated, very manual in my terminal windows)

Hey folks, my name is Luqi and I work at Apple with several other folks on osquery efforts. We're very interested in seeing official support of osquery on ARM become a reality and my understanding is that you folks are very much interested in it as well. We recently learned that folks at AWS are willing to provide engineering resources and compute credits to help with this goal, specifically CI for osquery on ARM. (Thank you AWS for the generous offer!) Would you all be interested in a meeting to discuss how do we make this a reality? I'm in no way familiar with the development process in osquery land but maybe we can target official support of osquery on ARM for 4.8.0 release?

I should have gone to bed an hour ago, but I got an example

ec2-github-runner

integration working with a test-fork of osquery: https://github.com/theopolis/osquery-ci-test/runs/2136674997?check_suite_focus=true this approach wont work for pull requests because of GitHub properly limiting access to secrets from non-collaborators. We might be able to get up and running with this by having these workflow jobs run on the main branch and tags. And we can find a solution for pull requests in the future. To have this work for master is a matter of copying and pasting that PR into

osquery/osquery

and setting the proper secrets.

Hi folks! I know there’s been a lot of interest in the arm64 CI work, and I wanted to give y’all an update on what @theopolis and I have been working on. (In thread)

@theopolis have you all been able to make any progress regarding the first option? I see you are waiting to add secrets here: https://github.com/osquery/osquery/pull/7014

It looks like my original CI workflow had an error causing it to only build the project, and not actually run the tests. I've corrected this in a branch and it looks like some tests are failing. https://github.com/osquery/osquery/runs/2283618080

this looks handy, we can maybe turn it on

@alessandrogario @seph, @David Gibb, and I had a discussion recently and due to security concerns with GitHub Actions we believe the current model will persist. Additionally, the lack of broader control (job start, job queue, etc) via GH APIs is another challenge today. However, based on the above change we can take another look at this.

@alessandrogario had been keeping that initial blog post updated with packages for each release. I can try to find the packages for 4.8.0 and make an update shortly. The plan is to have automation handle this for 4.9.0. One other thing we could use help with is support for the website. I created https://github.com/osquery/osquery-site/issues/207 to track moving from the small "hack" to find arm64 downloads.

but still would appreciate a SHA checksum from an osquery dev

This sounds like a bug

@Nico this has been asked about before (not recently) so there might be some discussion in the Slack history. But, porting to a platform like Android would be almost as big as rewriting osquery. It's not only compiling all of the library dependencies for Android, it also requires rewritten or new virtual tables to collect from platform-specific APIs, and whether it has the permissions necessary to provide useful collection. Then there's the question of how it would run as a daemon on Android. If someone had the time (really, the funding because time is money) to contribute such a large contribution to osquery, it should probably be done incrementally, with a roadmap. It's too early to estimate a timeline, without a roadmap and some dedicated people. But it's definitely more than several months of work.

what about accepting modifications that make Android compilation possible, as long as they don't interfere with things, and we don't make any claim yet that Android is a supported platform?

https://github.com/osquery/osquery/issues/6285 I think this is ready to be closed?

Just wanted to update and say we're on the apt repo and all is well

Hi everyone! I am not sure where to put this. I built Osquery from a Ubuntu/arm64 machine in order to run it on arm64 devices. When the Linux kernel version is equal to 4.9, the binary runs fine. But when the kernel is older, then I get : "FATAL : kernel too old". I gess I have to indicate the kernel version to CMake, but I don't know how. It this normal? And if it is normal, how can we make a binary run with old Linux kernel?

hello.. i am trying to build osquery toolchain for arm (32bit) from the repo https://github.com/osquery/osquery-toolchain; my build machine is aarch64. can someone help about what all things to be changed to build it successfully for arm (32bit)?