* [PATCH] tests: fix fdisk/bsd for alpha
@ 2016-03-16 0:40 Ruediger Meier
2016-03-16 11:37 ` Karel Zak
0 siblings, 1 reply; 8+ messages in thread
From: Ruediger Meier @ 2016-03-16 0:40 UTC (permalink / raw)
To: util-linux; +Cc: Andreas Henriksson
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
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] tests: fix fdisk/bsd for alpha
2016-03-16 0:40 [PATCH] tests: fix fdisk/bsd for alpha Ruediger Meier
@ 2016-03-16 11:37 ` Karel Zak
2016-03-16 13:11 ` Karel Zak
0 siblings, 1 reply; 8+ messages in thread
From: Karel Zak @ 2016-03-16 11:37 UTC (permalink / raw)
To: Ruediger Meier; +Cc: util-linux, Andreas Henriksson
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] tests: fix fdisk/bsd for alpha
2016-03-16 11:37 ` Karel Zak
@ 2016-03-16 13:11 ` Karel Zak
2016-03-16 15:27 ` Ruediger Meier
0 siblings, 1 reply; 8+ messages in thread
From: Karel Zak @ 2016-03-16 13:11 UTC (permalink / raw)
To: Ruediger Meier; +Cc: util-linux, Andreas Henriksson
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] tests: fix fdisk/bsd for alpha
2016-03-16 13:11 ` Karel Zak
@ 2016-03-16 15:27 ` Ruediger Meier
2016-03-17 13:33 ` Karel Zak
0 siblings, 1 reply; 8+ messages in thread
From: Ruediger Meier @ 2016-03-16 15:27 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux, Andreas Henriksson
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] tests: fix fdisk/bsd for alpha
2016-03-16 15:27 ` Ruediger Meier
@ 2016-03-17 13:33 ` Karel Zak
2016-03-17 21:52 ` Ruediger Meier
0 siblings, 1 reply; 8+ messages in thread
From: Karel Zak @ 2016-03-17 13:33 UTC (permalink / raw)
To: Ruediger Meier; +Cc: util-linux, Andreas Henriksson
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] tests: fix fdisk/bsd for alpha
2016-03-17 13:33 ` Karel Zak
@ 2016-03-17 21:52 ` Ruediger Meier
2016-03-18 14:36 ` Karel Zak
0 siblings, 1 reply; 8+ messages in thread
From: Ruediger Meier @ 2016-03-17 21:52 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] tests: fix fdisk/bsd for alpha
2016-03-17 21:52 ` Ruediger Meier
@ 2016-03-18 14:36 ` Karel Zak
2016-03-22 11:04 ` Ruediger Meier
0 siblings, 1 reply; 8+ messages in thread
From: Karel Zak @ 2016-03-18 14:36 UTC (permalink / raw)
To: Ruediger Meier; +Cc: util-linux
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] tests: fix fdisk/bsd for alpha
2016-03-18 14:36 ` Karel Zak
@ 2016-03-22 11:04 ` Ruediger Meier
0 siblings, 0 replies; 8+ messages in thread
From: Ruediger Meier @ 2016-03-22 11:04 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-03-22 11:04 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-16 0:40 [PATCH] tests: fix fdisk/bsd for alpha Ruediger Meier
2016-03-16 11:37 ` Karel Zak
2016-03-16 13:11 ` Karel Zak
2016-03-16 15:27 ` Ruediger Meier
2016-03-17 13:33 ` Karel Zak
2016-03-17 21:52 ` Ruediger Meier
2016-03-18 14:36 ` Karel Zak
2016-03-22 11:04 ` Ruediger Meier
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.