On 27/01/2019 13:18, Gordan Bobic wrote: > Figured it out. Two kernel configuration options were in play: > > CONFIG_COMPAT=y > CONFIG_LSM_MMAP_MIN_ADDR=32768 > > Above is what is required to run armv5tel and armv7hl chroots on aarch64. > Default for the latter option is 65535, which prevents 32-bit binaries > from running. Up and running with 4.9.153 now. <snip> For the centos armhfp/armv7hl builds, instead of using chroot'ed env directly on the aarch64 nodes, we just converted those into hypervisors and run armhfp VMs on top. But, as Stephen also pointed out, it unfortunately only works on some aarch64 cpus and not all of them : I realized that when I wanted to use a thunderX node as replacement for a mustang board and couldn't get any armhfp VM to start : then, after some discussion with ARM specialists, they confirm that, per hardware design, the thunderx (and also thunderx2) nodes can't run 32 bits at all, so no way to get armhfp VMs running on that anymore. That means that so far, the only boards on which we can still use the "armhfp VMs on top of aarch64 nodes" build process is on mustang or merlin (so basically X-Gene and X-Gene 2) I've heard also that the new Ampere eMAG should be able to also do that, but unfortunately, haven't verified (no access to such hardware) -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20190128/62aab446/attachment-0006.sig>