Many build systems (including Xen's, and autoconf) use uname to try to
discern the system's architecture.  When running i386 userland on an
amd64 kernel, this gives the wrong answer.  These build systems then
go off and try to do a sort of cross compile thing, and, generally,
fall over.

The uname -m value (which is what is at issue) is an inherited process
property.  Linux provides a utility `setarch' which changes this.  We
need to apply this to all builds; and it is not really convenient to
add an adverbial command to every build via the existing ssh build
shell rune mechanisms.

A fairly simple way to get the right behaviour is to wrap sshd
instead.  sshd doesn't mind what `personality' it sees.  Replacing
/usr/bin/sshd with a wrapper shell script might break
start-stop-daemon's attempts to shut down or restart sshd but we don't
care about that in osstest (certainly not on build installs, where
this feature is to be used).

Nothing uses this yet.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 Osstest/Debian.pm | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index addaaad2..8abd6aed 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1337,6 +1337,7 @@ END
     my $kern_arch_info = $xopts{LinuxKernPreferredArchInfo};
     # LinuxKernPreferredArchInfo contains
     #    Kernel_Debian     the Debian arch for the kernel we would prefer
+    #    Userland_setarch  personality to restore using setarch
     my $kern_arch = $kern_arch_info->{Kernel_Debian};
     if ($kern_arch &&
 	$ho->{Flags}{"arch-$r{arch}"} && !$ho->{Flags}{"arch-$kern_arch"}) {
@@ -1354,10 +1355,16 @@ END
 	$kern_arch = undef;
     }
     if ($kern_arch) {
-	logm("Using $kern_arch kernel for $r{arch} userland");
+	my $setarch = "setarch $kern_arch_info->{Userland_setarch}";
+	logm("Using $kern_arch kernel for $r{arch} userland ($setarch)");
 	preseed_hook_command($ho, 'late_command', $sfx, <<END);
 #!/bin/sh
 set -ex
+cat <<'ENDW' >/target/usr/sbin/sshd.osstest-wrap
+#!/bin/sh
+exec $setarch /usr/sbin/sshd.distrib "\$@"
+ENDW
+chmod a+x /target/usr/sbin/sshd.osstest-wrap
 in-target sh -xec '
     # the $r{arch} kernels end up being the default so shuffle them
     # where update-grub will not find them
@@ -1368,6 +1375,8 @@ in-target sh -xec '
     apt-get update
     apt-get install -f -y linux-image-$kern_arch
     update-grub
+    dpkg-divert --rename /usr/sbin/sshd
+    ln -s sshd.osstest-wrap /usr/sbin/sshd
 '
 END
     }
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

On 25/04/2019 16:50, Ian Jackson wrote:
> Many build systems (including Xen's, and autoconf) use uname to try to
> discern the system's architecture.  When running i386 userland on an
> amd64 kernel, this gives the wrong answer.  These build systems then
> go off and try to do a sort of cross compile thing, and, generally,
> fall over.
>
> The uname -m value (which is what is at issue) is an inherited process
> property.  Linux provides a utility `setarch' which changes this.  We
> need to apply this to all builds; and it is not really convenient to
> add an adverbial command to every build via the existing ssh build
> shell rune mechanisms.
>
> A fairly simple way to get the right behaviour is to wrap sshd
> instead.  sshd doesn't mind what `personality' it sees.  Replacing
> /usr/bin/sshd with a wrapper shell script might break
> start-stop-daemon's attempts to shut down or restart sshd but we don't
> care about that in osstest (certainly not on build installs, where
> this feature is to be used).

What is wrong with setting XEN_TARGET_ARCH=x86_{64,32} ?

This is how all the travis CI jobs work for mixed kernel/userspace, and,
as I note, how the debian packages do this as well.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Andrew Cooper writes ("Re: [Xen-devel] [OSSTEST PATCH 5/6] Debian: preferred arch: Apply setarch to sshd"):
> What is wrong with setting XEN_TARGET_ARCH=x86_{64,32} ?

I considered this.  (Indeed it's what I do in my own ad-hoc builds on
my workstation.)  But:

Firstly it would involve maintenance of yet another mapping of
architecture names.  I have mostly avoided this - although it is
creeping in with some of these special cases, I don't need a complete
table, only the names of busted architectures and their fixed ones.

Secondly, it does not work for autoconf.  For autoconf I would have to
pass --host= or --build= or something and I would have to have the
complete set of autoconf arch names.  autoconf arch names contain the
host OS as well, which makes this even more annoying.

Thirdly, there are probably things other than autoconf and Xen which
foolishly use uname.  I din't want to play whack-a-mole with them.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel