On 14/03/2016 16:56, Gordan Bobic wrote:
> 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).
Downloading now but it will be a couple of hours before I can check it out.
--
Mike Howard