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. I hope this is useful to someone else. On Sat, Jan 26, 2019 at 8:08 PM Gordan Bobic <gordan at redsleeve.org> wrote: > I did a bit more digging, and rebuilding 4.9.153 with CONFIG_COMPAT and a > few related options, had an effect - no longer do I get "exec format error" > - now it just outright segfaults. > 4.4.172 works perfectly. > > I'm using clean mainline kernels with no additional patches. > > chrooting to aarch64 chroots works. > > > On Sat, Jan 26, 2019 at 6:07 PM Stephen John Smoogen <smooge at gmail.com> > wrote: > >> >> >> On Sat, 26 Jan 2019 at 18:45, Gordan Bobic <gordan at redsleeve.org> wrote: >> >>> Yes, they are "wrong", but not "WRONG!". >>> >>> As I (possibly poorly) explained, I'm running on an aarch64 machine, but >>> am trying to run armv5tel and armv7hl chroots. >>> I just dug out an old kernel I was using (4.4.72) and I can now chroot >>> just fine. >>> >>> So it's something that changed in the kernel, but I'm not sure what else >>> it could be other than the page size (which I already checked). >>> >>> I'm going to build the latest 4.4.172 with my 4.4.72 config and see if >>> that works. If it does, I'll try to make oldconfig that on 4.9.153 and try >>> again, see if that breaks things again. I was just hoping there might be an >>> option I missed in 4.9 that enables/disables downward compatibility. >>> >>> >> The places I have seen where this breaks before was >> * it works on only specific aarch64 devices >> * it works but only after you update the firmware to a newer vendor >> version (because the kernel expects that to fix something else) >> * it is a regression and needs to be fixed. >> >> [The first one was where someone remembered it working but forgot they >> were working on XYZ box and then replicated in ABC and found the arch >> didn't have that.] >> >> I am expecting it is going to be 3... but I would check on 2 also. >> >> >> >>> Gordan >>> >>> On Sat, Jan 26, 2019 at 5:41 PM Stephan GUILLOUX < >>> stephan.guilloux at free.fr> wrote: >>> >>>> Wrong architecture binaries, in the chroot'ed folder ? >>>> >>>> What do you get with: >>>> >>>> file <chroot>/bin/bash >>>> >>>> On 26-Jan-19 17:49, Gordan Bobic wrote: >>>> > It's been so long since I last had to do this, that it looks like a >>>> > kernel update somewhere along the way broke this for me. :-( >>>> > >>>> > What happens now: >>>> > >>>> > # chroot rs7 >>>> > chroot: failed to run command ‘/bin/bash’: Exec format error >>>> > >>>> > I could have sworn that this was all I needed to make this work last >>>> time: >>>> > # grep 4K_PAGES config-4.9.153-1.el7.centos.aarch64 >>>> > CONFIG_ARM64_4K_PAGES=y >>>> > # CONFIG_ARM64_64K_PAGES is not set >>>> > >>>> > Unfortunately, now trying to chroot into either hard-float or >>>> > soft-float chroot results in the exec format error. >>>> > >>>> > Looking at time stamps of various things, I had this working with >>>> > 4.4.70, but have since switched to 4.9.x kernels. Any thoughts on >>>> what >>>> > changed between 4.4 and 4.9 would be most appreciated. >>>> > >>>> > What am I missing? >>>> > >>>> > _______________________________________________ >>>> > Arm-dev mailing list >>>> > Arm-dev at centos.org >>>> > https://lists.centos.org/mailman/listinfo/arm-dev >>>> _______________________________________________ >>>> Arm-dev mailing list >>>> Arm-dev at centos.org >>>> https://lists.centos.org/mailman/listinfo/arm-dev >>>> >>> _______________________________________________ >>> Arm-dev mailing list >>> Arm-dev at centos.org >>> https://lists.centos.org/mailman/listinfo/arm-dev >>> >> >> >> -- >> Stephen J Smoogen. >> >> _______________________________________________ >> Arm-dev mailing list >> Arm-dev at centos.org >> https://lists.centos.org/mailman/listinfo/arm-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20190127/c490dc56/attachment-0006.html>