[OSSTEST PATCH v2 0/6] stretch fallout: run 32-bit builds on 64-bit Linux

[OSSTEST PATCH v2 0/6] stretch fallout: run 32-bit builds on 64-bit Linux

[Ian Jackson]

My previous attempt failed because many build systems look at uname
and end up confused about the architecture.  In this v2 of the series,
I take countermeasures.

Ian Jackson (6):
  ts-syslog-server: --no-stdin option
  sg-run-job, ts-host-install: New --build option
  mg-repro-setup: Fix runvar adjustment shell syntax
  Debian: preferred arch: Honour LinuxKernPreferredArchInfo
  Debian: preferred arch: Apply setarch to sshd
  builds: Run i386 builds on amd64 kernels

 Osstest/Debian.pm | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 mg-repro-setup    |  2 +-
 sg-run-job        |  2 +-
 ts-host-install   |  9 +++++++++
 ts-syslog-server  | 10 +++++++++-
 5 files changed, 67 insertions(+), 3 deletions(-)

-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 0/6] stretch fallout: run 32-bit builds on 64-bit Linux

[Ian Jackson]

My previous attempt failed because many build systems look at uname
and end up confused about the architecture.  In this v2 of the series,
I take countermeasures.

Ian Jackson (6):
  ts-syslog-server: --no-stdin option
  sg-run-job, ts-host-install: New --build option
  mg-repro-setup: Fix runvar adjustment shell syntax
  Debian: preferred arch: Honour LinuxKernPreferredArchInfo
  Debian: preferred arch: Apply setarch to sshd
  builds: Run i386 builds on amd64 kernels

 Osstest/Debian.pm | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 mg-repro-setup    |  2 +-
 sg-run-job        |  2 +-
 ts-host-install   |  9 +++++++++
 ts-syslog-server  | 10 +++++++++-
 5 files changed, 67 insertions(+), 3 deletions(-)

-- 
2.11.0


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

[OSSTEST PATCH 1/6] ts-syslog-server: --no-stdin option

[Ian Jackson]

Useful when running on a tty interactively.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 ts-syslog-server | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/ts-syslog-server b/ts-syslog-server
index 1234bb7d..06a07adf 100755
--- a/ts-syslog-server
+++ b/ts-syslog-server
@@ -28,6 +28,13 @@ use Socket qw(PF_INET SOCK_DGRAM INADDR_ANY
 
 tsreadconfig();
 
+our $use_stdin = 1;
+
+if (@ARGV && $ARGV[0] eq '--no-stdin') {
+    $use_stdin = 0;
+    shift @ARGV;
+}
+
 die if @ARGV && $ARGV[0] =~ m/^-/;
 
 logm("starting syslog server ...");
@@ -42,7 +49,8 @@ $myaddr = inet_ntoa($myaddr);
 
 store_runvar('syslog_server',"$myaddr:$port");
 
-my @fhs = qw(S STDIN);
+my @fhs = qw(S);
+push @fhs, qw(STDIN) if $use_stdin;
 
 foreach my $fh (@fhs) {
     my $fl = fcntl($fh, F_GETFL, 0) // die $!;
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH 1/6] ts-syslog-server: --no-stdin option

[Ian Jackson]

Useful when running on a tty interactively.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 ts-syslog-server | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/ts-syslog-server b/ts-syslog-server
index 1234bb7d..06a07adf 100755
--- a/ts-syslog-server
+++ b/ts-syslog-server
@@ -28,6 +28,13 @@ use Socket qw(PF_INET SOCK_DGRAM INADDR_ANY
 
 tsreadconfig();
 
+our $use_stdin = 1;
+
+if (@ARGV && $ARGV[0] eq '--no-stdin') {
+    $use_stdin = 0;
+    shift @ARGV;
+}
+
 die if @ARGV && $ARGV[0] =~ m/^-/;
 
 logm("starting syslog server ...");
@@ -42,7 +49,8 @@ $myaddr = inet_ntoa($myaddr);
 
 store_runvar('syslog_server',"$myaddr:$port");
 
-my @fhs = qw(S STDIN);
+my @fhs = qw(S);
+push @fhs, qw(STDIN) if $use_stdin;
 
 foreach my $fh (@fhs) {
     my $fl = fcntl($fh, F_GETFL, 0) // die $!;
-- 
2.11.0


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

[OSSTEST PATCH 2/6] sg-run-job, ts-host-install: New --build option

[Ian Jackson]

Used to specify that the host will be used for building.  Currently
has no effect.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 sg-run-job      | 2 +-
 ts-host-install | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/sg-run-job b/sg-run-job
index 56b6384a..7c58d4ba 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -734,7 +734,7 @@ proc allocate-build-host {ostype} {
 }
 proc prepare-build-host-linux {} {
     global jobinfo
-    run-ts broken host-install(*) ts-host-install-twice
+    run-ts broken host-install(*) ts-host-install-twice + --build
     run-ts . host-build-prep ts-xen-build-prep
 }
 
diff --git a/ts-host-install b/ts-host-install
index 4213c3a2..7094559f 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -41,6 +41,7 @@ while (@ARGV and $ARGV[0] =~ m/^-/) {
 	$poweron_test_only= 1;
     } elsif  (m/^--rescue$/) {
 	$xopts{RescueMode}= 1;
+    } elsif  (m/^--build$/) {
     } else {
 	die "$_ $!";
     }
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH 2/6] sg-run-job, ts-host-install: New --build option

[Ian Jackson]

Used to specify that the host will be used for building.  Currently
has no effect.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 sg-run-job      | 2 +-
 ts-host-install | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/sg-run-job b/sg-run-job
index 56b6384a..7c58d4ba 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -734,7 +734,7 @@ proc allocate-build-host {ostype} {
 }
 proc prepare-build-host-linux {} {
     global jobinfo
-    run-ts broken host-install(*) ts-host-install-twice
+    run-ts broken host-install(*) ts-host-install-twice + --build
     run-ts . host-build-prep ts-xen-build-prep
 }
 
diff --git a/ts-host-install b/ts-host-install
index 4213c3a2..7094559f 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -41,6 +41,7 @@ while (@ARGV and $ARGV[0] =~ m/^-/) {
 	$poweron_test_only= 1;
     } elsif  (m/^--rescue$/) {
 	$xopts{RescueMode}= 1;
+    } elsif  (m/^--build$/) {
     } else {
 	die "$_ $!";
     }
-- 
2.11.0


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

[OSSTEST PATCH 3/6] mg-repro-setup: Fix runvar adjustment shell syntax

[Ian Jackson]

-r would fail with a bash syntax error.  This bug has existed ever
since this feature was introduced.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 mg-repro-setup | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mg-repro-setup b/mg-repro-setup
index 37ccb59d..6ed4d85e 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -108,7 +108,7 @@ adjrunvar () {
 for arg in "${adjustsets[@]}"; do
 	case "$arg" in
 	!*|^*)	delrunvar "${arg#?}"		;;
-	*=*)	adjrunvar "${arg%%=*}" "{$arg#*=}"	;;
+	*=*)	adjrunvar "${arg%%=*}" "${arg#*=}"	;;
 	*)	bad-adjuistset-pattern			;;
 	esac
 done
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH 3/6] mg-repro-setup: Fix runvar adjustment shell syntax

[Ian Jackson]

-r would fail with a bash syntax error.  This bug has existed ever
since this feature was introduced.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 mg-repro-setup | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mg-repro-setup b/mg-repro-setup
index 37ccb59d..6ed4d85e 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -108,7 +108,7 @@ adjrunvar () {
 for arg in "${adjustsets[@]}"; do
 	case "$arg" in
 	!*|^*)	delrunvar "${arg#?}"		;;
-	*=*)	adjrunvar "${arg%%=*}" "{$arg#*=}"	;;
+	*=*)	adjrunvar "${arg%%=*}" "${arg#*=}"	;;
 	*)	bad-adjuistset-pattern			;;
 	esac
 done
-- 
2.11.0


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

[OSSTEST PATCH 4/6] Debian: preferred arch: Honour LinuxKernPreferredArchInfo

[Ian Jackson]

Nothing sets this yet.

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

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 600f18b1..addaaad2 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1334,6 +1334,44 @@ END
 	preseed_hook_command($ho, 'late_command', $sfx, $cmds);
     });
 
+    my $kern_arch_info = $xopts{LinuxKernPreferredArchInfo};
+    # LinuxKernPreferredArchInfo contains
+    #    Kernel_Debian     the Debian arch for the kernel we would prefer
+    my $kern_arch = $kern_arch_info->{Kernel_Debian};
+    if ($kern_arch &&
+	$ho->{Flags}{"arch-$r{arch}"} && !$ho->{Flags}{"arch-$kern_arch"}) {
+	# We check the flag for $r{arch} because for various reasons
+	# it may not be set.  For example, in standalone mode it is
+	# currently not normally necessary to set any arch hostflags.
+	# In that situation we bet that the kern arch can be used;
+	# this is a good bet because currently this is used for
+	# running amd64 kernels with i386 userland and hosts that can
+	# do only i386 are fairly rare, especially server hosts.
+	# If this causes a problem, setting the i386 host flag will
+	# (somewhat counterintuitively) cause this check to miss
+	# the amd64 host flag
+	logm("NOT using $kern_arch kernel (flags say not supported by host)");
+	$kern_arch = undef;
+    }
+    if ($kern_arch) {
+	logm("Using $kern_arch kernel for $r{arch} userland");
+	preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+in-target sh -xec '
+    # the $r{arch} kernels end up being the default so shuffle them
+    # where update-grub will not find them
+    for f in /boot/vmlinu*; do
+        dpkg-divert --rename --divert "/boot/~disable~\${f##*/}" "\$f"
+    done
+    dpkg --add-architecture $kern_arch
+    apt-get update
+    apt-get install -f -y linux-image-$kern_arch
+    update-grub
+'
+END
+    }
+
     if ( $ho->{Flags}{'need-uboot-bootscr'} ) {
 	my @bootargs = uboot_common_kernel_bootargs($ho);
 
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH 4/6] Debian: preferred arch: Honour LinuxKernPreferredArchInfo

[Ian Jackson]

Nothing sets this yet.

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

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 600f18b1..addaaad2 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1334,6 +1334,44 @@ END
 	preseed_hook_command($ho, 'late_command', $sfx, $cmds);
     });
 
+    my $kern_arch_info = $xopts{LinuxKernPreferredArchInfo};
+    # LinuxKernPreferredArchInfo contains
+    #    Kernel_Debian     the Debian arch for the kernel we would prefer
+    my $kern_arch = $kern_arch_info->{Kernel_Debian};
+    if ($kern_arch &&
+	$ho->{Flags}{"arch-$r{arch}"} && !$ho->{Flags}{"arch-$kern_arch"}) {
+	# We check the flag for $r{arch} because for various reasons
+	# it may not be set.  For example, in standalone mode it is
+	# currently not normally necessary to set any arch hostflags.
+	# In that situation we bet that the kern arch can be used;
+	# this is a good bet because currently this is used for
+	# running amd64 kernels with i386 userland and hosts that can
+	# do only i386 are fairly rare, especially server hosts.
+	# If this causes a problem, setting the i386 host flag will
+	# (somewhat counterintuitively) cause this check to miss
+	# the amd64 host flag
+	logm("NOT using $kern_arch kernel (flags say not supported by host)");
+	$kern_arch = undef;
+    }
+    if ($kern_arch) {
+	logm("Using $kern_arch kernel for $r{arch} userland");
+	preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+in-target sh -xec '
+    # the $r{arch} kernels end up being the default so shuffle them
+    # where update-grub will not find them
+    for f in /boot/vmlinu*; do
+        dpkg-divert --rename --divert "/boot/~disable~\${f##*/}" "\$f"
+    done
+    dpkg --add-architecture $kern_arch
+    apt-get update
+    apt-get install -f -y linux-image-$kern_arch
+    update-grub
+'
+END
+    }
+
     if ( $ho->{Flags}{'need-uboot-bootscr'} ) {
 	my @bootargs = uboot_common_kernel_bootargs($ho);
 
-- 
2.11.0


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

[OSSTEST PATCH 5/6] Debian: preferred arch: Apply setarch to sshd

[Ian Jackson]

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

[Xen-devel] [OSSTEST PATCH 5/6] Debian: preferred arch: Apply setarch to sshd

[Ian Jackson]

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

[OSSTEST PATCH 6/6] builds: Run i386 builds on amd64 kernels

[Ian Jackson]

Most hardware that supports i386 supports amd64 too.  When doing
builds we do need the right userland, but we don't actually care what
the kernel is doing.  With Linux 32-on-64 is good for that.

Especially, there is a kernel regression (evident in the Debian
stretch kernel, but not present in jessie's) where 32-bit Linux
mismanages the memory on hosts with moderately large amounts of
RAM (ie, significantly more RAM than can be addressed at once),
resulting in what amounts to a near-stall of the paging system.  Since
the paging system is used for filesystem writes too, the effect is
that commands run by builds can take totally unreasonable amounts of
time.  Ie, this version of Linux is broken when i386 PAE is needed.

In practice this is causing significant trouble in the Xen Project CI.

This kernel bug probably won't affect our test jobs because
(i) we use our own kernels, so we would probably detect this
regression when switching kernel branches etc. (ii) test jobs
run with a dom0_mem setting which avoids the preconditions for the
particular bug.

CC: Juergen Gross <jgross@suse.com>
CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 ts-host-install | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/ts-host-install b/ts-host-install
index 7094559f..45f04764 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -31,6 +31,7 @@ my $debconf_priority;
 my $poweron_test_only;
 
 our %xopts;
+our $kern_arch_info;
 
 while (@ARGV and $ARGV[0] =~ m/^-/) {
     $_= shift @ARGV;
@@ -42,6 +43,12 @@ while (@ARGV and $ARGV[0] =~ m/^-/) {
     } elsif  (m/^--rescue$/) {
 	$xopts{RescueMode}= 1;
     } elsif  (m/^--build$/) {
+	if ($r{arch} eq 'i386') {
+	    $kern_arch_info = {
+                Kernel_Debian => 'amd64',
+                Userland_setarch => 'i386',
+            };
+	}
     } else {
 	die "$_ $!";
     }
@@ -61,6 +68,7 @@ sub install () {
         ($ho, '',
          DiskDevice => $ho->{DiskDevice},
          Properties => $ho->{Properties},
+	 LinuxKernPreferredArchInfo => $kern_arch_info,
          ExtraPreseed => <<END );
 d-i netcfg/get_hostname string $ho->{Name}
 d-i netcfg/get_ipaddress string $ho->{Ip}
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH 6/6] builds: Run i386 builds on amd64 kernels

[Ian Jackson]

Most hardware that supports i386 supports amd64 too.  When doing
builds we do need the right userland, but we don't actually care what
the kernel is doing.  With Linux 32-on-64 is good for that.

Especially, there is a kernel regression (evident in the Debian
stretch kernel, but not present in jessie's) where 32-bit Linux
mismanages the memory on hosts with moderately large amounts of
RAM (ie, significantly more RAM than can be addressed at once),
resulting in what amounts to a near-stall of the paging system.  Since
the paging system is used for filesystem writes too, the effect is
that commands run by builds can take totally unreasonable amounts of
time.  Ie, this version of Linux is broken when i386 PAE is needed.

In practice this is causing significant trouble in the Xen Project CI.

This kernel bug probably won't affect our test jobs because
(i) we use our own kernels, so we would probably detect this
regression when switching kernel branches etc. (ii) test jobs
run with a dom0_mem setting which avoids the preconditions for the
particular bug.

CC: Juergen Gross <jgross@suse.com>
CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 ts-host-install | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/ts-host-install b/ts-host-install
index 7094559f..45f04764 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -31,6 +31,7 @@ my $debconf_priority;
 my $poweron_test_only;
 
 our %xopts;
+our $kern_arch_info;
 
 while (@ARGV and $ARGV[0] =~ m/^-/) {
     $_= shift @ARGV;
@@ -42,6 +43,12 @@ while (@ARGV and $ARGV[0] =~ m/^-/) {
     } elsif  (m/^--rescue$/) {
 	$xopts{RescueMode}= 1;
     } elsif  (m/^--build$/) {
+	if ($r{arch} eq 'i386') {
+	    $kern_arch_info = {
+                Kernel_Debian => 'amd64',
+                Userland_setarch => 'i386',
+            };
+	}
     } else {
 	die "$_ $!";
     }
@@ -61,6 +68,7 @@ sub install () {
         ($ho, '',
          DiskDevice => $ho->{DiskDevice},
          Properties => $ho->{Properties},
+	 LinuxKernPreferredArchInfo => $kern_arch_info,
          ExtraPreseed => <<END );
 d-i netcfg/get_hostname string $ho->{Name}
 d-i netcfg/get_ipaddress string $ho->{Ip}
-- 
2.11.0


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

Re: [OSSTEST PATCH 6/6] builds: Run i386 builds on amd64 kernels

[Juergen Gross]

On 25/04/2019 17:50, Ian Jackson wrote:
> Most hardware that supports i386 supports amd64 too.  When doing
> builds we do need the right userland, but we don't actually care what
> the kernel is doing.  With Linux 32-on-64 is good for that.
> 
> Especially, there is a kernel regression (evident in the Debian
> stretch kernel, but not present in jessie's) where 32-bit Linux
> mismanages the memory on hosts with moderately large amounts of
> RAM (ie, significantly more RAM than can be addressed at once),
> resulting in what amounts to a near-stall of the paging system.  Since
> the paging system is used for filesystem writes too, the effect is
> that commands run by builds can take totally unreasonable amounts of
> time.  Ie, this version of Linux is broken when i386 PAE is needed.
> 
> In practice this is causing significant trouble in the Xen Project CI.
> 
> This kernel bug probably won't affect our test jobs because
> (i) we use our own kernels, so we would probably detect this
> regression when switching kernel branches etc. (ii) test jobs
> run with a dom0_mem setting which avoids the preconditions for the
> particular bug.
> 
> CC: Juergen Gross <jgross@suse.com>
> CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Paul Durrant <paul.durrant@citrix.com>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Juergen Gross <jgross@suse.com>


Juergen

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

Re: [Xen-devel] [OSSTEST PATCH 6/6] builds: Run i386 builds on amd64 kernels

[Juergen Gross]

On 25/04/2019 17:50, Ian Jackson wrote:
> Most hardware that supports i386 supports amd64 too.  When doing
> builds we do need the right userland, but we don't actually care what
> the kernel is doing.  With Linux 32-on-64 is good for that.
> 
> Especially, there is a kernel regression (evident in the Debian
> stretch kernel, but not present in jessie's) where 32-bit Linux
> mismanages the memory on hosts with moderately large amounts of
> RAM (ie, significantly more RAM than can be addressed at once),
> resulting in what amounts to a near-stall of the paging system.  Since
> the paging system is used for filesystem writes too, the effect is
> that commands run by builds can take totally unreasonable amounts of
> time.  Ie, this version of Linux is broken when i386 PAE is needed.
> 
> In practice this is causing significant trouble in the Xen Project CI.
> 
> This kernel bug probably won't affect our test jobs because
> (i) we use our own kernels, so we would probably detect this
> regression when switching kernel branches etc. (ii) test jobs
> run with a dom0_mem setting which avoids the preconditions for the
> particular bug.
> 
> CC: Juergen Gross <jgross@suse.com>
> CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Paul Durrant <paul.durrant@citrix.com>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Juergen Gross <jgross@suse.com>


Juergen

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

Re: [OSSTEST PATCH 5/6] Debian: preferred arch: Apply setarch to sshd

[Andrew Cooper]

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

Re: [Xen-devel] [OSSTEST PATCH 5/6] Debian: preferred arch: Apply setarch to sshd

[Andrew Cooper]

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

Re: [OSSTEST PATCH 5/6] Debian: preferred arch: Apply setarch to sshd

[Ian Jackson]

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

Re: [Xen-devel] [OSSTEST PATCH 5/6] Debian: preferred arch: Apply setarch to sshd

[Ian Jackson]

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