[Arm-dev] Gigabyte MP30-AR0

Mon Mar 14 16:56:49 UTC 2016
Gordan Bobic <gordan at redsleeve.org>

On 2016-03-14 15:00, Gordan Bobic wrote:
> On 2016-03-01 22:32, Michael Howard wrote:
>> On 01/03/2016 22:26, Richard W.M. Jones wrote:
>>> On Mon, Feb 29, 2016 at 03:20:03PM +0000, Michael Howard wrote:
>>>> Just to let you know, I can't get this to work. aarch64 is supposed
>>>> to be binary compatible, with the correct libraries installed, but
>>>> I'm thinking the cpu isn't.
>>>> 
>>>> All I get is 'cannot execute binary file: Exec format error',
>>>> regardless  of what I try.
>>> As I understand it the problem is page size - 64K was chosen by
>>> Red Hat for aarch64, where as 4K is the norm on armv7.
>>> 
>>> Anyway, you can run a 32 bit VM and it works well -- in fact a lot
>>> faster than regular 32 bit armv7 hardware.
>>> 
>> 
>> Yes, with CONFIG_ARM64_4K_PAGES=y and CONFIG_COMPAT=y, 32 bit binaries 
>> run fine.
> 
> I built a kernel with these options enabled, but chrooting into an
> armv5tel subtree segfaults immediately. :-(
> 
> # grep -E "CONFIG_COMPAT=|CONFIG_ARM64_4K_PAGES=" /boot/config-4.4.5
> CONFIG_ARM64_4K_PAGES=y
> CONFIG_COMPAT=y
> 
> # chroot /orcone/docker/rsel6/
> Segmentation fault
> 
> The chroot is armv5tel soft-float, which I think should work.
> Oddly, I see no mention of a segfault in dmesg or in /var/log/messages
> on the host...
> 
> # strace chroot /orcone/docker/media/
> execve("/sbin/chroot", ["chroot", "/orcone/docker/media/"], [/* 18 vars 
> */]) = 0
> brk(0)                                  = 0x153eb000
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7f98108000
> faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such
> file or directory)
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=23876, ...}) = 0
> mmap(NULL, 23876, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f98102000
> close(3)                                = 0
> openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
> read(3,
> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\270\r\2\0\0\0\0\0"...,
> 832) = 832
> fstat(3, {st_mode=S_IFREG|0755, st_size=1801536, ...}) = 0
> mmap(NULL, 1528796, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
> 0) = 0x7f97f66000
> mprotect(0x7f980c2000, 65536, PROT_NONE) = 0
> mmap(0x7f980d2000, 24576, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15c000) = 0x7f980d2000
> mmap(0x7f980d8000, 13276, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f980d8000
> close(3)                                = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7f98101000
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7f98100000
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7f980ff000
> mprotect(0x7f980d2000, 16384, PROT_READ) = 0
> mprotect(0x41f000, 4096, PROT_READ)     = 0
> mprotect(0x7f9810b000, 4096, PROT_READ) = 0
> munmap(0x7f98102000, 23876)             = 0
> brk(0)                                  = 0x153eb000
> brk(0x1540c000)                         = 0x1540c000
> brk(0)                                  = 0x1540c000
> openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) 
> = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=109669264, ...}) = 0
> mmap(NULL, 109669264, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f916cf000
> close(3)                                = 0
> chroot("/orcone/docker/media/")         = 0
> chdir("/")                              = 0
> execve("/bin/bash", ["/bin/bash", "-i"], [/* 18 vars */]) = 
> -1053305918634065933
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
> +++ killed by SIGSEGV +++
> Segmentation fault
> 
> 
> What am I doing differently?

Just to make sure we are as much on the same page as possible, here
is the minimal chroot I am trying:
http://ftp.redsleeve.org/pub/el6-staging/rootfs/rsel6-minimal.tar.xz

Built from the latest RedSleeve 6 binaries using:
yum --installroot=/some/path install @core

Can you extract that into an empty folder and chroot into it
from your aarch64 CentOS 7 install? Does it work for you or
does it segfault?

If it works for you, any chance you could post your kernel
config somewhere? It's the only thing I can think of that
could plausibly be causeing the discrepancy (I am on 4.4.5
and IIRC you were on 4.5rc).

Gordan