sfdisk, latest fixes break ppc64

sfdisk, latest fixes break ppc64

[Ruediger Meier]

Hi,

the latest sfdisk fixes 2928068a..a53e37f9 seem to break ppc64

test sfdisk/gpt:
[  431s]                 : read-dump                   .../home/abuild/rpmbuild/BUILD/util-linux-2.26.git227.2cb28/tests/ts/sfdisk/gpt: line 96: 15657 Aborted                 
$TS_CMD_SFDISK --list -o START,END,SIZE,UUID,TYPE,NAME ${TS_DEVICE} >> $TS_OUTPUT 2>&1
[  431s]                 : write-dump                  ... FAILED (sfdisk/gpt-write-dump)
....
[  438s] --- /home/abuild/rpmbuild/BUILD/util-linux-2.26.git227.2cb28/tests/expected/sfdisk/gpt-read-dump       2015-04-21 09:37:08.855755828 +0000
[  438s] +++ /home/abuild/rpmbuild/BUILD/util-linux-2.26.git227.2cb28/tests/output/sfdisk/gpt-read-dump 2015-04-21 10:02:53.610000012 +0000
[  438s] @@ -25,15 +25,4 @@
[  438s]  The partition table has been altered.
[  438s]  Calling ioctl() to re-read partition table.
[  438s]  Syncing disks.
[  438s] -Disk <removed>: 50 MiB, 52428800 bytes, 102400 sectors
[  438s] -Units: sectors of 1 * 512 = 512 bytes
[  438s] -Sector size (logical/physical): 512 bytes / 4096 bytes
[  438s] -I/O size (minimum/optimal): 4096 bytes / 32768 bytes
[  438s] -Disklabel type: gpt
[  438s] -Disk identifier: <removed>
[  438s] -
[  438s] -Start    End Size UUID                                 Type             Name
[  438s] - 2048   8191   3M 4DD6948A-44F8-4E6C-8BDC-064F740704F8 Linux root (x86)
[  438s] - 8192  14335   3M 44B51DEF-5F04-465A-91AA-2889A62D8E49 Linux filesystem
[  438s] -14336  20479   3M 643E1D0D-BC02-4CED-B83B-86121062858F Linux filesystem
[  438s] -20480 102399  40M D2A29B0A-FDEE-40C3-9BAE-B9FA782C986C Linux filesystem GPT is the best
[  438s] +sfdisk: libfdisk/src/label.c:175: fdisk_label_get_field: Assertion `id > 0' failed.
[  438s] --- /home/abuild/rpmbuild/BUILD/util-linux-2.26.git227.2cb28/tests/expected/sfdisk/gpt-write-dump      2015-04-21 09:37:08.869755975 +0000
[  438s] +++ /home/abuild/rpmbuild/BUILD/util-linux-2.26.git227.2cb28/tests/output/sfdisk/gpt-write-dump        2015-04-21 10:02:53.680000012 +0000
[  438s] @@ -2,8 +2,8 @@
[  438s]  label-id: 3B8559DB-33AF-43E9-BEFC-C331D829B539
[  438s]  device: <removed>
[  438s]  unit: sectors
[  438s] -first-lba: 2048
[  438s] -last-lba: 102366
[  438s] +first-lba: 2251799813685248
[  438s] +last-lba: 16037037897601253376
[  438s]
[  438s]  <removed>1 : start=        2048, size=        6144, type=44479540-F297-41B2-9AF7-D131D5F0458A, uuid=4DD6948A-44F8-4E6C-8BDC-064F740704F8
[  438s]  <removed>2 : start=        8192, size=        6144, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=44B51DEF-5F04-465A-91AA-2889A62D8E49
[  438s] + sudo -E ./mount
[  438s] + sudo -E cat /proc/mounts
[  438s] + sudo -E cat /etc/mtab
[  438s] + sudo -E ./losetup --all
[  438s] + md5sum /tmp/mount2_mount /tmp/mount2_proc /tmp/mount2_etc
[  438s] e692b5dd6e7daa7ac1fc6e43d2d8d7b0  /tmp/mount2_mount
[  438s] 5ea7870d46476a3d72a8ee2c26a50842  /tmp/mount2_proc
[  438s] b6abaf8ac1486439f8418d2b2c8c7c5c  /tmp/mount2_etc
[  438s] + diff -u /tmp/mount1_mount /tmp/mount2_mount
[  438s] + diff -u /tmp/mount1_etc /tmp/mount2_etc
[  438s] + diff -u /tmp/mount1_proc /tmp/mount2_proc
[  438s] + diff -u /tmp/losetup1 /tmp/losetup2
[  438s] + exit 1
[  438s] error: Bad exit status from /var/tmp/rpm-tmp.M8JOAg (%check)
[  438s]
[  438s]
[  438s] RPM build errors:
[  438s]     Bad exit status from /var/tmp/rpm-tmp.M8JOAg (%check)
[  438s] ### WATCHDOG MARKER START ###
[  440s] reboot: Power down
[  440s] ### WATCHDOG MARKER END ###


cu,
Rudi

Re: sfdisk, latest fixes break ppc64

[Karel Zak]

On Tue, Apr 21, 2015 at 12:34:26PM +0200, Ruediger Meier wrote:
> the latest sfdisk fixes 2928068a..a53e37f9 seem to break ppc64

The latest changes in sfdisk only shows stupid LE/BE bugs we have in GPT
code. The problem should be fixed now.

It seems I have to compile and tests on Big Endian (ppc and s390)
more often, because we have no enough users who test it.

    Karel

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

Re: sfdisk, latest fixes break ppc64

[Ruediger Meier]

On Wednesday 22 April 2015, Karel Zak wrote:
> On Tue, Apr 21, 2015 at 12:34:26PM +0200, Ruediger Meier wrote:
> > the latest sfdisk fixes 2928068a..a53e37f9 seem to break ppc64
>
> The latest changes in sfdisk only shows stupid LE/BE bugs we have in
> GPT code. The problem should be fixed now.

Thanks!

> It seems I have to compile and tests on Big Endian (ppc and s390)
> more often, because we have no enough users who test it.

Hehe I've set up the next build farm already (no auto push yet):
https://build.opensuse.org/package/show/home:rudi_m:ul-all/ul-plain

These are very different (sometimes strange) hosts. Xen, kvm, real
machines ... with or without sudo, module support, etc. The build
hosts may even change between rebuilds. Sometimes they are under heavy
load. Most issues are fixed now so I guess 2.26.2 will be a good one :)

There are still some random failures sometimes like this:

             : resize                      ... FAILED (sfdisk/gpt-resize)
....
[  604s] --- /home/abuild/rpmbuild/BUILD/util-linux-2.26.git233.01aa/tests/expected/sfdisk/gpt-resize	2015-04-22 06:40:45.002363998 +0000
[  604s] +++ /home/abuild/rpmbuild/BUILD/util-linux-2.26.git233.01aa/tests/output/sfdisk/gpt-resize	2015-04-22 10:22:27.514581956 +0000
[  604s] @@ -1,3 +1,4 @@
[  604s] +Re-reading the partition table failed.: Device or resource busy
[  604s]  Checking that no-one is using this disk right now ... OK
[  604s]  
[  604s]  Disk <removed>: 50 MiB, 52428800 bytes, 102400 sectors
[  604s] @@ -20,4 +21,5 @@
[  604s]  
[  604s]  The partition table has been altered.
[  604s]  Calling ioctl() to re-read partition table.
[  604s] +The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).
[  604s]  Syncing disks.


cu,
Rudi

Re: sfdisk, latest fixes break ppc64

[Karel Zak]

On Wed, Apr 22, 2015 at 12:42:18PM +0200, Ruediger Meier wrote:
> On Wednesday 22 April 2015, Karel Zak wrote:
> > On Tue, Apr 21, 2015 at 12:34:26PM +0200, Ruediger Meier wrote:
> > > the latest sfdisk fixes 2928068a..a53e37f9 seem to break ppc64
> >
> > The latest changes in sfdisk only shows stupid LE/BE bugs we have in
> > GPT code. The problem should be fixed now.
> 
> Most issues are fixed now so I guess 2.26.2 will be a good one :)

 I hope so:-) Next time it would be nice to detect and fix such bugs
 in major release or in .1  ... we need a way how to motivate users to
 use -rc releases (t-shits, beers? ;-)

> There are still some random failures sometimes like this:
> 
>              : resize                      ... FAILED (sfdisk/gpt-resize)
> ....
> [  604s] --- /home/abuild/rpmbuild/BUILD/util-linux-2.26.git233.01aa/tests/expected/sfdisk/gpt-resize	2015-04-22 06:40:45.002363998 +0000
> [  604s] +++ /home/abuild/rpmbuild/BUILD/util-linux-2.26.git233.01aa/tests/output/sfdisk/gpt-resize	2015-04-22 10:22:27.514581956 +0000
> [  604s] @@ -1,3 +1,4 @@
> [  604s] +Re-reading the partition table failed.: Device or resource busy
> [  604s]  Checking that no-one is using this disk right now ... OK
> [  604s]  
> [  604s]  Disk <removed>: 50 MiB, 52428800 bytes, 102400 sectors
> [  604s] @@ -20,4 +21,5 @@
> [  604s]  
> [  604s]  The partition table has been altered.
> [  604s]  Calling ioctl() to re-read partition table.
> [  604s] +The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).
> [  604s]  Syncing disks.

Yes, I know about it, but I'm able to reproduce this only on ppc, add
"sleep 10" to the test fixes the problem, so I guess that "udevadm
settle" is not so reliable on ppc.

Note that I'm working on new resize code, so this test will go away
and it will be replaced with separated "resize" test script.

    Karel

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

Re: sfdisk, latest fixes break ppc64

[Ruediger Meier]

On Wednesday 22 April 2015, Karel Zak wrote:
> On Wed, Apr 22, 2015 at 12:42:18PM +0200, Ruediger Meier wrote:
> > On Wednesday 22 April 2015, Karel Zak wrote:
> > > On Tue, Apr 21, 2015 at 12:34:26PM +0200, Ruediger Meier wrote:
> > > > the latest sfdisk fixes 2928068a..a53e37f9 seem to break ppc64
> > >
> > > The latest changes in sfdisk only shows stupid LE/BE bugs we have
> > > in GPT code. The problem should be fixed now.
> >
> > Most issues are fixed now so I guess 2.26.2 will be a good one :)
>
>  I hope so:-) Next time it would be nice to detect and fix such bugs
>  in major release or in .1  ... we need a way how to motivate users
> to use -rc releases (t-shits, beers? ;-)

Hehe, maybe the only way is like we have it right now. 2.xx and 2.xx.1 
are the real rc1 and rc2. The distributors have to learn to use 2.xx.2 
only ;)

> > There are still some random failures sometimes like this:
> >              : resize                      ... FAILED
> >              : (sfdisk/gpt-resize)

> Yes, I know about it, but I'm able to reproduce this only on ppc, add
> "sleep 10" to the test fixes the problem, so I guess that "udevadm
> settle" is not so reliable on ppc.

Yes, I've also made many experiments about this.

For example currently I'am always using
  export BLKID_CONF="/dev/null"

to avoid arbitrary /etc/blkid.conf from build hosts. This makes sure 
that you always use "EVALUATE=scan" and it seems to fix 
random "blkdiscard" failures.

And I've also tried something like this partially succesful:

@@ -497,10 +497,14 @@ function ts_device_deinit {
 }
 
 function ts_uuid_by_devname {
+	echo change > /sys/block/$(basename $1)/uevent
+	udevadm settle
 	echo $($TS_CMD_BLKID -p -s UUID -o value $1)
 }
 
 function ts_label_by_devname {
+	echo change > /sys/block/$(basename $1)/uevent
+	udevadm settle
 	echo $($TS_CMD_BLKID -p -s LABEL -o value $1)
 }

cu,
Rudi

Re: sfdisk, latest fixes break ppc64

[Bernhard Voelker]

On 04/22/2015 04:20 PM, Ruediger Meier wrote:
> On Wednesday 22 April 2015, Karel Zak wrote:
>>   I hope so:-) Next time it would be nice to detect and fix such bugs
>>   in major release or in .1  ... we need a way how to motivate users
>> to use -rc releases (t-shits, beers? ;-)
>
> Hehe, maybe the only way is like we have it right now. 2.xx and 2.xx.1
> are the real rc1 and rc2. The distributors have to learn to use 2.xx.2
> only ;)

Isn't there a cross-platform CI system somewhere?
... okay, http://build.opensuse.org/ is one, but it usually
doesn't track upstream changes.  There's also things like
Hydra (http://hydra.nixos.org/) ... but this only seems to
cover i686 and x86_64.

Have a nice day,
Berny

Re: sfdisk, latest fixes break ppc64

[Karel Zak]

On Wed, Apr 22, 2015 at 04:50:39PM +0200, Bernhard Voelker wrote:
> On 04/22/2015 04:20 PM, Ruediger Meier wrote:
> >On Wednesday 22 April 2015, Karel Zak wrote:
> >>  I hope so:-) Next time it would be nice to detect and fix such bugs
> >>  in major release or in .1  ... we need a way how to motivate users
> >>to use -rc releases (t-shits, beers? ;-)
> >
> >Hehe, maybe the only way is like we have it right now. 2.xx and 2.xx.1
> >are the real rc1 and rc2. The distributors have to learn to use 2.xx.2
> >only ;)
> 
> Isn't there a cross-platform CI system somewhere?
> ... okay, http://build.opensuse.org/ is one, but it usually
> doesn't track upstream changes.  There's also things like
> Hydra (http://hydra.nixos.org/) ... but this only seems to
> cover i686 and x86_64.

We already use 

    https://drone.io/github.com/karelzak/util-linux

and

    https://travis-ci.org/karelzak/util-linux

both connected to github, but for ppc64 and s390 I use machines in Red
Hat labs and during -rc1 I usually use Coverity analyzer.

It's also possible to use Fedora/Suse build farms, but we don't
execute all the tests (especially tests where is necessary root perms)
by default. 

Anyway, this is no problem, the problem is real life testing.
Fortunately, I can push unstable stuff to Fedora Rawhide :)

    Karel

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

Re: sfdisk, latest fixes break ppc64

[Ruediger Meier]

On Wednesday 22 April 2015 at 17:46, you wrote:
> We already use
>
>     https://drone.io/github.com/karelzak/util-linux
>
> and
>
>     https://travis-ci.org/karelzak/util-linux
>
> both connected to github, but for ppc64 and s390 I use machines in
> Red Hat labs and during -rc1 I usually use Coverity analyzer.
>
> It's also possible to use Fedora/Suse build farms, but we don't
> execute all the tests (especially tests where is necessary root
> perms) by default.

You can get root permission there with such a trick "root4abuild" rpm
https://build.opensuse.org/package/view_file/home:rudi_m/root4abuild/root4abuild.spec?expand=1

BTW we could also add some more non-root tests. For example it's very 
easy to duplicate most *fdisk checks to use simple files additionally 
to loop devices only.

> Anyway, this is no problem, the problem is real life testing.
> Fortunately, I can push unstable stuff to Fedora Rawhide :)


cu,
Rudi

Re: sfdisk, latest fixes break ppc64

[Ruediger Meier]

On Wednesday 22 April 2015, Bernhard Voelker wrote:
> On 04/22/2015 04:20 PM, Ruediger Meier wrote:
> > On Wednesday 22 April 2015, Karel Zak wrote:
> >>   I hope so:-) Next time it would be nice to detect and fix such
> >> bugs in major release or in .1  ... we need a way how to motivate
> >> users to use -rc releases (t-shits, beers? ;-)
> >
> > Hehe, maybe the only way is like we have it right now. 2.xx and
> > 2.xx.1 are the real rc1 and rc2. The distributors have to learn to
> > use 2.xx.2 only ;)
>
> Isn't there a cross-platform CI system somewhere?
> ... okay, http://build.opensuse.org/ is one, but it usually
> doesn't track upstream changes.

I would push it from git daily when the build and test runs always 
stable. My major problem on OBS is that we don't always have the right 
kernel modules installed.

> There's also things like 
> Hydra (http://hydra.nixos.org/) ... but this only seems to
> cover i686 and x86_64.

Our drone.io and travis-ci.org setup for x86_64 is already not bad
but a bit poor ... old ubuntu, no loop devices, no systemd. If hydra has 
more features then we could also try this.

Another thing would be gcc build farm. I have ssh login there and there 
are some interesting archs. We could set up some build cronjobs. But we 
can't be root there.
https://gcc.gnu.org/wiki/CompileFarm

BTW I've heard that Debian has also some exotic developer machines where 
one could ask for login.

cu,
Rudi