On 2016-03-14 17:13, Michael Howard wrote:
> 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.
Thanks, most appreciated. You may want to re-download, as I literally
just replaced with tar ball with a more compressed version. If that
happened
during your download, what you get may end up being corrupted (check
whether
it matches the md5 checksum).
Gordan