[PATCH] tests: fix fdisk/bsd for alpha

[PATCH] tests: fix fdisk/bsd for alpha

[Ruediger Meier]

From: Ruediger Meier <ruediger.meier@ga-group.nl>

There are special __alpha__ ifdefs in libfdisk/src/bsd.c
Regarding 565964a9 and a80886e9.

BTW it was a bad idea to use md5sum. In case of failure it
would be much easier to debug hexdump diffs. Now it's nearly
impossible to collect all these exotic hexdumps.

CC: Andreas Henriksson <andreas@fatal.se>
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
---
 tests/ts/fdisk/bsd | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/tests/ts/fdisk/bsd b/tests/ts/fdisk/bsd
index cd7a6c6..347c0d0 100755
--- a/tests/ts/fdisk/bsd
+++ b/tests/ts/fdisk/bsd
@@ -51,7 +51,7 @@ function fdisk_bsd_offset_and_byte_order_clean
 		local md5_bsdimg1_LE_0_64="2e1cee529cb59c9341afef0443f196a1"
 		local md5_bsdimg2_LE_0_64="b5c121c2091b2ff26b880551feac7112"
 
-        if [ $BYTE_ORDER = "BE" ] ; then
+	if [ $BYTE_ORDER = "BE" ] ; then
 		# BSD_LABELSECTOR = 0, BSD_LABELOFFSET = 64
 		sed -i \
 		-e "s/c2273b52976351db75596c47c10b0725/$md5_bsdimg1_LE_0_64/" \
@@ -69,6 +69,15 @@ function fdisk_bsd_offset_and_byte_order_clean
 		-e "s/6d760d7a8ef33b27cc6e27f1e8807d48/$md5_bsdimg1_LE_0_64/" \
 		-e "s/3739c7959adb42693a69edb7a99914e8/$md5_bsdimg2_LE_0_64/" \
 		"$TS_OUTPUT"
+
+		# special case for alpha
+		if grep -q "78a922a80361cb73049bced72e0f8f1d" $TS_OUTPUT; then
+			sed -i \
+				-e "s/78a922a80361cb73049bced72e0f8f1d/$md5_bsdimg1_LE_0_64/" \
+				-e "s/fc2803672a0643ffe46da325629616fc/$md5_bsdimg2_LE_0_64/" \
+				-e 's/\(3 *Version 7 *8 *\)ext2  /\1MS-DOS/' \
+				"$TS_OUTPUT"
+		fi
 	fi
 }
 
-- 
1.8.4.5

Re: [PATCH] tests: fix fdisk/bsd for alpha

[Karel Zak]

On Wed, Mar 16, 2016 at 01:40:44AM +0100, Ruediger Meier wrote:
> BTW it was a bad idea to use md5sum. In case of failure it
> would be much easier to debug hexdump diffs. Now it's nearly
> impossible to collect all these exotic hexdumps.

 I'll try to prepare a new test with hexdump, PPC[64] LE/BE should 
 not be a problem. The rest we can gather later.

> CC: Andreas Henriksson <andreas@fatal.se>
> Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
> ---
>  tests/ts/fdisk/bsd | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)

 Applied, thanks.

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH] tests: fix fdisk/bsd for alpha

[Karel Zak]

On Wed, Mar 16, 2016 at 12:37:41PM +0100, Karel Zak wrote:
> On Wed, Mar 16, 2016 at 01:40:44AM +0100, Ruediger Meier wrote:
> > BTW it was a bad idea to use md5sum. In case of failure it
> > would be much easier to debug hexdump diffs. Now it's nearly
> > impossible to collect all these exotic hexdumps.
> 
>  I'll try to prepare a new test with hexdump, PPC[64] LE/BE should 
>  not be a problem. The rest we can gather later.

 Done, the last missing is Aplha (with special fields in the label...). 
 
 The original md5 based test is still in the tree to make a way how to
 verify Alpha output. Maybe it's overkill and we can remove the test.
 Not sure.

 Test it, try it, send patches ;)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH] tests: fix fdisk/bsd for alpha

[Ruediger Meier]

On Wednesday 16 March 2016, Karel Zak wrote:
> On Wed, Mar 16, 2016 at 12:37:41PM +0100, Karel Zak wrote:
> > On Wed, Mar 16, 2016 at 01:40:44AM +0100, Ruediger Meier wrote:
> > > BTW it was a bad idea to use md5sum. In case of failure it
> > > would be much easier to debug hexdump diffs. Now it's nearly
> > > impossible to collect all these exotic hexdumps.
> >
> >  I'll try to prepare a new test with hexdump, PPC[64] LE/BE should
> >  not be a problem. The rest we can gather later.
>
>  Done, the last missing is Aplha (with special fields in the
> label...).

Thanks! I was really to lazy to refactor this one.

>  The original md5 based test is still in the tree to make a way how
> to verify Alpha output. Maybe it's overkill and we can remove the
> test. Not sure.
>
>  Test it, try it, send patches ;)

Hehe, maybe the only alpha machine on this planet is this Debian build 
host:
https://buildd.debian.org/status/package.php?p=util-linux&suite=experimental

We can wait until Adreas updates the package and copy/paste it from the 
log like I've got that md5sum;)


BTW there are only two more test failures left on sparc:

FAILED (fdisk/id)
--- /<<PKGBUILDDIR>>/tests/expected/fdisk/id
+++ /<<PKGBUILDDIR>>/tests/output/fdisk/id
@@ -1,3 +1,5 @@
 Initialize empty image
 Create MBR with ID=0x1
-Disk identifier: 0x00000001
 Create MBR with ID=0x2
-Disk identifier: 0x00000002


FAILED (fdisk/mbr-nondos-mode)
--- /<<PKGBUILDDIR>>/tests/expected/fdisk/mbr-nondos-mode
+++ /<<PKGBUILDDIR>>/tests/output/fdisk/mbr-nondos-mode
@@ -1,189 +1,203 @@
 Initialize empty image
 8f4e33f3dc3e414ff94e5fb6905cba8c mbr-nondos-mode.img
 Create new DOS partition table
-4e23561dcb81678bb1bd678722c7cbb7 mbr-nondos-mode.img
+8f4e33f3dc3e414ff94e5fb6905cba8c mbr-nondos-mode.img


And we could disable setarch's uname26 test because
# glibc requires kernel >= 3.0, thus setarch --uname-2.6 fails
# on platforms without VDSO

cu,
Rudi

Re: [PATCH] tests: fix fdisk/bsd for alpha

[Karel Zak]

On Wed, Mar 16, 2016 at 04:27:10PM +0100, Ruediger Meier wrote:
> And we could disable setarch's uname26 test because
> # glibc requires kernel >= 3.0, thus setarch --uname-2.6 fails
> # on platforms without VDSO

OK, added exception for sparc.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH] tests: fix fdisk/bsd for alpha

[Ruediger Meier]

On Thursday 17 March 2016, Karel Zak wrote:
> On Wed, Mar 16, 2016 at 04:27:10PM +0100, Ruediger Meier wrote:
> > And we could disable setarch's uname26 test because
> > # glibc requires kernel >= 3.0, thus setarch --uname-2.6 fails
> > # on platforms without VDSO
>
> OK, added exception for sparc.

I don't fully understand the real problem. See also this Debian package 
comment:
 "Apparently glibc does not support 2.6 personality on some
  architectures when built to require newer kernels (e.g. >= 3.2).
  See https://bugs.debian.org/806911"

Couldn't we tell setarch at build time that uname26 will not work with 
the used glibc?

On openSUSE 13.2,arm7vl and on that debian,sparc machine we see this 
diff:

 Switching on STICKY_TIMEOUTS.
 Switching on ADDR_LIMIT_3GB.
 Switching on UNAME26.
-success
+FATAL: kernel too old

Where does the "FATAL" message come from? Is it printed directly by 
glibc? If yes then we could use it to skip the test. (Allthough the 
kernel is not really too old but probably something is too new or just 
different.)

But on openSUSE 13.2 arm6vl and aarch64 I don't get this last "FATAL" 
message but a segfault instead! Is there something we could do in 
setarch to avoid this segfault? (These arm6vl and aarch64 machines seem 
to run differently as "qemu_user_space_build").

BTW the test works fine on openSUSE 13.1 and 42.1. (newer and older than 
13.2).

cu,
Rudi

Re: [PATCH] tests: fix fdisk/bsd for alpha

[Karel Zak]

On Thu, Mar 17, 2016 at 10:52:49PM +0100, Ruediger Meier wrote:
> On Thursday 17 March 2016, Karel Zak wrote:
> > On Wed, Mar 16, 2016 at 04:27:10PM +0100, Ruediger Meier wrote:
> > > And we could disable setarch's uname26 test because
> > > # glibc requires kernel >= 3.0, thus setarch --uname-2.6 fails
> > > # on platforms without VDSO
> >
> > OK, added exception for sparc.
> 
> I don't fully understand the real problem. See also this Debian package 
> comment:
>  "Apparently glibc does not support 2.6 personality on some
>   architectures when built to require newer kernels (e.g. >= 3.2).
>   See https://bugs.debian.org/806911"
> 
> Couldn't we tell setarch at build time that uname26 will not work with 
> the used glibc?

Is there any way how to detect it? Do we really want it?

I don't like if userspace utils want to be more smart than kernel or 
any abstraction layers in libc -- in many case is better to strerror() 
+ exit() than #ifdef or if() in code based on kernel or libc version. 

The code is possible to compile, the rest is about the real environment 
where the util is executed. I guess you can update kernel or libc without
ABI break.

The another story is that downstream kernel version says nothing due
to massive backports and number of patches in distributions.

> On openSUSE 13.2,arm7vl and on that debian,sparc machine we see this 
> diff:
> 
>  Switching on STICKY_TIMEOUTS.
>  Switching on ADDR_LIMIT_3GB.
>  Switching on UNAME26.
> -success
> +FATAL: kernel too old
> 
> Where does the "FATAL" message come from? Is it printed directly by 
> glibc? If yes then we could use it to skip the test. (Allthough the 
> kernel is not really too old but probably something is too new or just 
> different.)
> 
> But on openSUSE 13.2 arm6vl and aarch64 I don't get this last "FATAL" 
> message but a segfault instead! Is there something we could do in 
> setarch to avoid this segfault? (These arm6vl and aarch64 machines seem 
> to run differently as "qemu_user_space_build").
> 
> BTW the test works fine on openSUSE 13.1 and 42.1. (newer and older than 
> 13.2).

I think use "FATAL: ..." to skip the test would be good enough. Not
sure about segfault :-) 

Maybe for arms and sparc use TS_KNOWN_FAIL="yes", it does not have 
to be perfect (especially if we know about the issue and it's 
relevant for "old" kernels only).

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH] tests: fix fdisk/bsd for alpha

[Ruediger Meier]

On Friday 18 March 2016, Karel Zak wrote:
> On Thu, Mar 17, 2016 at 10:52:49PM +0100, Ruediger Meier wrote:
> > On Thursday 17 March 2016, Karel Zak wrote:
> > > On Wed, Mar 16, 2016 at 04:27:10PM +0100, Ruediger Meier wrote:
> > > > And we could disable setarch's uname26 test because
> > > > # glibc requires kernel >= 3.0, thus setarch --uname-2.6 fails
> > > > # on platforms without VDSO
> > >
> > > OK, added exception for sparc.
> >
> > I don't fully understand the real problem. See also this Debian
> > package comment:
> >  "Apparently glibc does not support 2.6 personality on some
> >   architectures when built to require newer kernels (e.g. >= 3.2).
> >   See https://bugs.debian.org/806911"
> >
> > Couldn't we tell setarch at build time that uname26 will not work
> > with the used glibc?
>
> Is there any way how to detect it? Do we really want it?
>
> I don't like if userspace utils want to be more smart than kernel or
> any abstraction layers in libc -- in many case is better to
> strerror() + exit() than #ifdef or if() in code based on kernel or
> libc version.
>
> The code is possible to compile, the rest is about the real
> environment where the util is executed. I guess you can update kernel
> or libc without ABI break.
>
> The another story is that downstream kernel version says nothing due
> to massive backports and number of patches in distributions.

I understand. BTW I guess any personality option may have the capability 
to let an arbitrary executed binary fail. The user should know what he 
is doing. We should not stop him from "running" kernel 2.6 with a libc 
which does not support it. Maybe he even wants to use setarch to find 
out what exactly happens in this case.

Moreover the executed binary even does not need to be linked against the 
same libc like our setarch. Actually we would only need to have a 
2.6-compatible test binary rather than /bin/echo.

> > On openSUSE 13.2,arm7vl and on that debian,sparc machine we see
> > this diff:
> >
> >  Switching on STICKY_TIMEOUTS.
> >  Switching on ADDR_LIMIT_3GB.
> >  Switching on UNAME26.
> > -success
> > +FATAL: kernel too old
> >
> > Where does the "FATAL" message come from? Is it printed directly by
> > glibc? If yes then we could use it to skip the test. (Allthough the
> > kernel is not really too old but probably something is too new or
> > just different.)
> >
> > But on openSUSE 13.2 arm6vl and aarch64 I don't get this last
> > "FATAL" message but a segfault instead! Is there something we could
> > do in setarch to avoid this segfault? (These arm6vl and aarch64
> > machines seem to run differently as "qemu_user_space_build").
> >
> > BTW the test works fine on openSUSE 13.1 and 42.1. (newer and older
> > than 13.2).
>
> I think use "FATAL: ..." to skip the test would be good enough. Not
> sure about segfault :-)

I will add some more tests without --uname-2.6 and also handle 
that "kernel too old" message.

Regarding segfault I think it's a good idea to add another verbose 
message to setarch, like "exec command" right before  execvp(). Then we 
will see whether at least our own code survives until this point 
without crashing.

> Maybe for arms and sparc use TS_KNOWN_FAIL="yes", it does not have
> to be perfect (especially if we know about the issue and it's
> relevant for "old" kernels only).

It looks like "setarch $(uname -m) ..." should work on any arch.The 
failed logs we see are only because of --uname-2.6 incompatibility plus 
other problems on "qemu user space" where also many other things do not 
work as expected,


cu,
Rudi