On Thursday 2021-09-02 11:27, Martin Wilck wrote:

On Thu, 2021-09-02 at 11:15 +0200, Frans de Boer wrote:

...

 If I do the following:    if test -r <some file>; then echo ok; fi  Then the reply is 'ok' under normal x86_64 TW.   [...]It is blocking me from compiling programs under aarch64 because the configure script is using these tests. If I change the ´-r´ flag within configure into a ´-s´, everything does work well.

Well, test -s and test -r are very different things.

Not only that. test and test are different! I had a debugging session on IRC not too long ago involving configure and test inside a docker namespace, with a surprising result: [root@46d397eef00e /]# cat /etc/redhat-release Fedora release 34 (Thirty Four) [root@46d397eef00e /]# /bin/test -x / ; echo $? 0 [root@46d397eef00e /]# test -x / ; echo $? 1 Tracing revealed that one is using faccessat(2), the other is using access(2), which pointed to syscall filtering being the culprit. Even though qemu does not filter, it may need to emulate/passthru, and that slope is sooo slippery.

On Thu, 02 Sep 2021, 11:15:00 +0200, Frans de Boer wrote:

...

It took me some time, but somehow bash is not behaving as expected within a qemu-aarch64 chroot jail.

If I do the following:   if test -r <some file>; then echo ok; fi Then the reply is 'ok' under normal x86_64 TW. Please show all details about <some file> within the chroot. The "-r" flag checks "FILE exists and read permission is granted". I used <some file> because you can pick /*ANY*/ file with their read

On 9/2/21 11:35, Manfred Hollstein wrote: permission set. Of course I checked that.

...

However, when I started a chroot jail using qemu-aarch64 the reply stays empty. Only when I execute   if test !  -r <some file>; then echo ok; fi the response is 'ok'. And <some file> is always the same.

I start the jail with the next command: /usr/bin/qemu-aarch64 -strace -cpu cortex-a53 -L /newroot  /newroot/usr/sbin/ chroot  "/newroot" \   /usr/bin/env -i \     HOME=/root \     TERM="$TERM" \     PS1='(lfs chroot) \u:\w\$ ' \     PS4='(${BASH_SOURCE}:${LINENO}: ${FUNCNAME[0]} - [${SHLVL},$ {BASH_SUBSHELL}, $?] ' \     PATH=/usr/bin:/usr/sbin \     /usr/bin/bash --login +h

Also, I copied a static version of qemu-aarch64 and qemu_binfmt into /newroot/ usr/bin - I also tried my own compiled version of qemu-aarch64-static, with the same result. Programs run, but bash seems to have this specific issue with the -r test. Other flags I tested -f, -s, -x etc. are working correctly. These flags don't check the _read_ permission for the executing user. I never said that it would. And as a bonus, it is all at UID 0 level. The -r flags is the only flag which - I presume - really does a reading test, while others test availability and some file flags. Maybe binfmt is to blame??

It is blocking me from compiling programs under aarch64 because the configure script is using these tests. If I change the ´-r´ flag within configure into a ´-s´, everything does work well.

Regards, Frans. HTH, cheers.

l8er manfred --- Frans

On 9/3/21 22:14, Frans de Boer wrote:

On 9/3/21 22:02, Frans de Boer wrote:

...

...

On Thu, 02 Sep 2021, 11:15:00 +0200, Frans de Boer wrote:

...

It took me some time, but somehow bash is not behaving as expected within a qemu-aarch64 chroot jail.

If I do the following:   if test -r <some file>; then echo ok; fi Then the reply is 'ok' under normal x86_64 TW. Please show all details about <some file> within the chroot. The "-r" flag checks "FILE exists and read permission is granted". I used <some file> because you can pick /*ANY*/ file with their read

On 9/2/21 11:35, Manfred Hollstein wrote: permission set. Of course I checked that.

...

...

However, when I started a chroot jail using qemu-aarch64 the reply stays empty. Only when I execute   if test !  -r <some file>; then echo ok; fi the response is 'ok'. And <some file> is always the same.

I start the jail with the next command: /usr/bin/qemu-aarch64 -strace -cpu cortex-a53 -L /newroot  /newroot/usr/sbin/ chroot  "/newroot" \   /usr/bin/env -i \     HOME=/root \     TERM="$TERM" \     PS1='(lfs chroot) \u:\w\$ ' \     PS4='(${BASH_SOURCE}:${LINENO}: ${FUNCNAME[0]} - [${SHLVL},$ {BASH_SUBSHELL}, $?] ' \     PATH=/usr/bin:/usr/sbin \     /usr/bin/bash --login +h

Also, I copied a static version of qemu-aarch64 and qemu_binfmt into /newroot/ usr/bin - I also tried my own compiled version of qemu-aarch64-static, with the same result. Programs run, but bash seems to have this specific issue with the -r test. Other flags I tested -f, -s, -x etc. are working correctly. These flags don't check the _read_ permission for the executing user. I never said that it would. And as a bonus, it is all at UID 0 level. The -r flags is the only flag which - I presume - really does a reading test, while others test availability and some file flags. Maybe binfmt is to blame??

It is blocking me from compiling programs under aarch64 because the configure script is using these tests. If I change the ´-r´ flag within configure into a ´-s´, everything does work well.

Regards, Frans. HTH, cheers.

l8er manfred --- Frans Okay, after many more tests I still have problems with the -r and -x flags. Maybe some untested flags too. Just tested additional -a, -d, -e, -f, -s flags. They work. I found the -r and -x tests in configure and Makefiles and probably others too.

I trow the towel into the ring as far as building a new system image from scratch which differ from the building host and using qemu-xxxx and qemu-xxxx-binfmt. As far as I now understand, you need to have a running target system in order to build a new system image. Qemu can't help there.

How does OpenSuse build images for systems other then x86_64?

--- Frans. Tried the same with ppc64, same bad results.

Frans -- A: Yes, just like that A: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant?

Continue top-posting...( See remarks below. Frans. On 9/6/21 10:20, Guillaume Gardet wrote:

Hi, openSUSE builds natively for aarch64, armv6/7, etc. inside a qemu KVM. That implies that you already have a bootable environment for arm etc.? Also, you can build inside a full qemu (non-KVM, so slowly). Using qemu without KVM is slow indeed. However, to my knowledge, here you need a bootable environment also?

Guillaume *From:* Frans de Boer *Sent:* 03 September 2021 22:14 *To:* factory@lists.opensuse.org *Subject:* Re: aarch64: test -r with bash issue On 9/3/21 22:02, Frans de Boer wrote: On 9/2/21 11:35, Manfred Hollstein wrote: On Thu, 02 Sep 2021, 11:15:00 +0200, Frans de Boer wrote: It took me some time, but somehow bash is not behaving as expected within a qemu-aarch64 chroot jail. If I do the following:   if test -r <some file>; then echo ok; fi Then the reply is 'ok' under normal x86_64 TW. Please show all details about <some file> within the chroot. The "-r" flag checks "FILE exists and read permission is granted". I used <some file> because you can pick */ANY/* file with their read permission set. Of course I checked that. However, when I started a chroot jail using qemu-aarch64 the reply stays empty. Only when I execute   if test !  -r <some file>; then echo ok; fi the response is 'ok'. And <some file> is always the same. I start the jail with the next command: /usr/bin/qemu-aarch64 -strace -cpu cortex-a53 -L /newroot  /newroot/usr/sbin/ chroot  "/newroot" \   /usr/bin/env -i \     HOME=/root \     TERM="$TERM" \     PS1='(lfs chroot) \u:\w\$ ' \     PS4='(${BASH_SOURCE}:${LINENO}: ${FUNCNAME[0]} - [${SHLVL},$ {BASH_SUBSHELL}, $?] ' \     PATH=/usr/bin:/usr/sbin \     /usr/bin/bash --login +h Also, I copied a static version of qemu-aarch64 and qemu_binfmt into /newroot/ usr/bin - I also tried my own compiled version of qemu-aarch64-static, with the same result. Programs run, but bash seems to have this specific issue with the -r test. Other flags I tested -f, -s, -x etc. are working correctly. These flags don't check the _read_ permission for the executing user. I never said that it would. And as a bonus, it is all at UID 0 level. The -r flags is the only flag which - I presume - really does a reading test, while others test availability and some file flags. Maybe binfmt is to blame?? It is blocking me from compiling programs under aarch64 because the configure script is using these tests. If I change the ´-r´ flag within configure into a ´-s´, everything does work well. Regards, Frans. HTH, cheers. l8er manfred --- Frans Okay, after many more tests I still have problems with the -r and -x flags. Maybe some untested flags too. Just tested additional -a, -d, -e, -f, -s flags. They work. I found the -r and -x tests in configure and Makefiles and probably others too.

I trow the towel into the ring as far as building a new system image from scratch which differ from the building host and using qemu-xxxx and qemu-xxxx-binfmt. As far as I now understand, you need to have a running target system in order to build a new system image. Qemu can't help there.

How does OpenSuse build images for systems other then x86_64?

--- Frans.

-- A: Yes, just like that A: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant?