NetBSD Problem Report #56303
From www@netbsd.org Sun Jul 11 17:07:40 2021
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 56D861A9247
for <gnats-bugs@gnats.NetBSD.org>; Sun, 11 Jul 2021 17:07:40 +0000 (UTC)
Message-Id: <20210711170739.2A71E1A924A@mollari.NetBSD.org>
Date: Sun, 11 Jul 2021 17:07:39 +0000 (UTC)
From: roland.illig@gmx.de
Reply-To: roland.illig@gmx.de
To: gnats-bugs@NetBSD.org
Subject: On a fresh installation, /tmp on sparc64 is not sticky
X-Send-Pr-Version: www-1.0
>Number: 56303
>Category: install
>Synopsis: On a fresh installation, /tmp on sparc64 is not sticky
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: martin
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Jul 11 17:10:01 +0000 2021
>Closed-Date: Fri Aug 20 07:07:15 +0000 2021
>Last-Modified: Tue Oct 25 17:55:01 +0000 2022
>Originator: Roland Illig
>Release: 9.99.86
>Organization:
>Environment:
>Description:
Several releng tests for sparc64 are failing because they cannot create files in /tmp. Andreas Gustafsson already found out:
Immediately after a fresh install of -current/sparc64:
# ls -al /tmp
total 4
drwxr-xr-x 2 root wheel 512 Jul 10 12:54 .
drwxr-xr-x 20 root wheel 512 Jul 10 11:25 ..
cf. i386:
# ls -al /tmp
total 4
drwxrwxrwt 2 root wheel 512 Jul 11 13:18 .
drwxr-xr-x 20 root wheel 512 Jul 11 13:17 ..
In both cases, /tmp is on the root file system, not tmpfs.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: install-manager->martin
Responsible-Changed-By: martin@NetBSD.org
Responsible-Changed-When: Sun, 11 Jul 2021 17:43:06 +0000
Responsible-Changed-Why:
take
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Mon, 12 Jul 2021 12:27:11 +0200
I can not reproduce this - just did a (manual) clean install and ended
up with:
drwxrwxrwt 2 root wheel 512 Jul 12 12:19 /targetroot/tmp/
Anything in anita acting up and accidently modifying it before reboot?
Martin
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Mon, 12 Jul 2021 12:29:58 +0200
Or does it depend on the RAM size passed to qemu?
(this would make sysinst pick different defaults for tmpfs and also might
be a difference to the i386 setup)
Martin
From: Martin Husemann <martin@duskware.de>
To: Andreas Gustafsson <gson@gson.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Mon, 12 Jul 2021 13:56:54 +0200
On Mon, Jul 12, 2021 at 01:49:34PM +0300, Andreas Gustafsson wrote:
> The sparc64 failures and the i386 sucesses are both with 128 MB of
> RAM, which is not enough to cause a tmpfs /tmp to be configured
> in either port.
I tested with 126 MB ram (from sysinst's POV) and could still not reproduce
it.
Just to make sure: this is the install CD being used on sparc64 (e.g. full
grown userland, not a special crunched version of sysinst in a ramdisk
image)?
Also I did only look at the state of the disk after sysinst terminated (and
unmounted the target device) - it also coud be some rc.d script going wild
due to something else missing at first boot.
Martin
From: Andreas Gustafsson <gson@gson.org>
To: martin@netbsd.org
Cc: netbsd-bugs@netbsd.org, roland.illig@gmx.de
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Mon, 12 Jul 2021 13:49:34 +0300
Martin Husemann wrote:
> I can not reproduce this - just did a (manual) clean install and ended
> up with:
>
> drwxrwxrwt 2 root wheel 512 Jul 12 12:19 /targetroot/tmp/
>
> Anything in anita acting up and accidently modifying it before reboot?
I can't think of anything in anita that would do that, but I'm
not saying it's impossible.
> Or does it depend on the RAM size passed to qemu?
> (this would make sysinst pick different defaults for tmpfs and also might
> be a difference to the i386 setup)
The sparc64 failures and the i386 sucesses are both with 128 MB of
RAM, which is not enough to cause a tmpfs /tmp to be configured
in either port. I have not tested a configuration with more RAM
that would cause a tmpfs /tmp to be configured.
--
Andreas Gustafsson, gson@gson.org
From: Andreas Gustafsson <gson@gson.org>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@NetBSD.org
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Mon, 12 Jul 2021 19:08:31 +0300
Martin Husemann wrote:
> I tested with 126 MB ram (from sysinst's POV) and could still not reproduce
> it.
>
> Just to make sure: this is the install CD being used on sparc64 (e.g. full
> grown userland, not a special crunched version of sysinst in a ramdisk
> image)?
It's installing from an install CD image with a command line like this:
qemu-system-sparc64 \
-m 128 \
-drive file=/bracket/sparc64/test/2021.07.02.17.14.36/anita/wd0.img,format=raw,media=disk,snapshot=off \
-nographic \
-boot d \
-drive file=/bracket/sparc64/test/2021.07.02.17.14.36/anita/download/sparc64/NetBSD-9.99.86-sparc64.iso,format=raw,media=cdrom,readonly=on,index=2
> Also I did only look at the state of the disk after sysinst terminated (and
> unmounted the target device) - it also coud be some rc.d script going wild
> due to something else missing at first boot.
That's possible.
I'll try to do a manual qemu install on lyta to see if I can catch
the point where the permissions get changed.
--
Andreas Gustafsson, gson@gson.org
From: Andreas Gustafsson <gson@gson.org>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@NetBSD.org
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Mon, 12 Jul 2021 22:03:33 +0300
Martin Husemann wrote:
> Also I did only look at the state of the disk after sysinst terminated (and
> unmounted the target device) - it also coud be some rc.d script going wild
> due to something else missing at first boot.
I did a manual qemu install on lyta and escaped to a shell by typing
control-z at the "The installation of NetBSD-9.99.86 is now complete"
screen, and /targetroot/tmp had the incorrect 0755 mode at that point.
My current theory is that one of gzip -dc, progress, or tar fails
during the base.tar.xz extraction, specifically after the the
directory /targetroot/tmp has been created but before it has been
chmod'ed to its final mode, and that for some reason, sysinst doesn't
notice the error.
For example, if I escape to a shell during set extraction by typing
control-z, manually kill the gzip -dc process, and exit the shell,
sysinst appears to continue like nothing happened and says all sets
extracted successfully. Can you reproduce this?
--
Andreas Gustafsson, gson@gson.org
From: Roland Illig <roland.illig@gmx.de>
To: gnats-bugs@netbsd.org, martin@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc:
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Mon, 12 Jul 2021 23:01:42 +0200
Am 12.07.2021 um 21:05 schrieb Andreas Gustafsson:
> For example, if I escape to a shell during set extraction by typing
> control-z, manually kill the gzip -dc process, and exit the shell,
> sysinst appears to continue like nothing happened and says all sets
> extracted successfully. Can you reproduce this?
Sounds plausible to me. A simpler reproducer is:
$ cat | head
and in another shell:
$ pkill cat
After that, the pipeline 'cat | head' has exit status 0. If I remember
correctly, progress(1) feeds tar(1), via a pipeline, so that may be the
same scenario. In my example the exit status is 0 because head(1) calls
read(2), which returns 0 without any error, and that is of course
interpreted as EOF.
Roland
From: RVP <rvp@SDF.ORG>
To: Roland Illig <roland.illig@gmx.de>
Cc: gnats-bugs@netbsd.org, martin@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Mon, 12 Jul 2021 22:50:16 +0000 (UTC)
On Mon, 12 Jul 2021, Roland Illig wrote:
> Am 12.07.2021 um 21:05 schrieb Andreas Gustafsson:
>> For example, if I escape to a shell during set extraction by typing
>> control-z, manually kill the gzip -dc process, and exit the shell,
>> sysinst appears to continue like nothing happened and says all sets
>> extracted successfully. Can you reproduce this?
>
> Sounds plausible to me. A simpler reproducer is:
>
> $ cat | head
>
> and in another shell:
> $ pkill cat
>
> After that, the pipeline 'cat | head' has exit status 0. If I remember
> correctly, progress(1) feeds tar(1), via a pipeline, so that may be the
> same scenario. In my example the exit status is 0 because head(1) calls
> read(2), which returns 0 without any error, and that is of course
> interpreted as EOF.
>
Maybe sysinst should do `set -o pipefail' on all its pipelined commands?
-RVP
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Tue, 13 Jul 2021 03:39:43 +0000
On Sun, Jul 11, 2021 at 05:10:01PM +0000, roland.illig@gmx.de wrote:
> Immediately after a fresh install of -current/sparc64:
>
> # ls -al /tmp
> total 4
> drwxr-xr-x 2 root wheel 512 Jul 10 12:54 .
> drwxr-xr-x 20 root wheel 512 Jul 10 11:25 ..
>
> cf. i386:
>
> # ls -al /tmp
> total 4
> drwxrwxrwt 2 root wheel 512 Jul 11 13:18 .
> drwxr-xr-x 20 root wheel 512 Jul 11 13:17 ..
>
> In both cases, /tmp is on the root file system, not tmpfs.
I had this happen, unrepeatably, on an anita run a couple weeks ago on
amd64. Broke everything in all kinds of exciting ways.
It's unlikely that the problem is sparc-specific, but it seems to be
rare.
--
David A. Holland
dholland@netbsd.org
From: Martin Husemann <martin@duskware.de>
To: Andreas Gustafsson <gson@gson.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Tue, 13 Jul 2021 10:18:40 +0200
On Mon, Jul 12, 2021 at 10:03:33PM +0300, Andreas Gustafsson wrote:
> My current theory is that one of gzip -dc, progress, or tar fails
> during the base.tar.xz extraction
Good point, with that little RAM and xz compressed sets (vs. simple
gzip on i386) we are probably on the borderline. We should enable swap
in that case during extraction.
Martin
From: Andreas Gustafsson <gson@gson.org>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@NetBSD.org
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Tue, 13 Jul 2021 11:46:46 +0300
Martin Husemann wrote:
> Good point, with that little RAM and xz compressed sets (vs. simple
> gzip on i386) we are probably on the borderline. We should enable swap
> in that case during extraction.
The minimum supported RAM according to the INSTALL document is 32 MB.
That will probably have to be adjusted regardless, but unless we want
to quadruple it rather than just doubling it, I think we need to
switch back to tar.gz sets.
--
Andreas Gustafsson, gson@gson.org
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Tue, 13 Jul 2021 10:51:55 +0200
OK, so we have two orthogonal issues.
I'll make TINY_RAM_SIZE depend on USE_XZ_SETS (after finding the memory
limit that sets extraction needs and rounding up seriously). This will
enable swap in the sparc64 installation on the test bed.
The other part is that apparently
progress -zf $(set).tar.xz tar --chroot $(path) -xpf -
does not return failure properly. Sounds like a progress(1) or gizp(1)
bug to me.
Martin
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Tue, 13 Jul 2021 10:54:27 +0200
On Tue, Jul 13, 2021 at 08:50:01AM +0000, Andreas Gustafsson wrote:
> The minimum supported RAM according to the INSTALL document is 32 MB.
Yes, but this is unrelated (and we won't have to touch it).
> That will probably have to be adjusted regardless, but unless we want
> to quadruple it rather than just doubling it, I think we need to
> switch back to tar.gz sets.
We can not do that, the ISO just does not fit on a real CD with gzip
and many sparc64 machines did come with CD drives instead of DVD.
Martin
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56303 CVS commit: src/usr.sbin/sysinst
Date: Tue, 13 Jul 2021 09:13:00 +0000
Module Name: src
Committed By: martin
Date: Tue Jul 13 09:13:00 UTC 2021
Modified Files:
src/usr.sbin/sysinst: Makefile.inc defs.h
Log Message:
PR install/56303: when using xz files enable swap during set extraction
if the machine does not have more than 256MB of RAM.
To generate a diff of this commit:
cvs rdiff -u -r1.40 -r1.41 src/usr.sbin/sysinst/Makefile.inc
cvs rdiff -u -r1.70 -r1.71 src/usr.sbin/sysinst/defs.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@netbsd.org
Cc: martin@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
roland.illig@gmx.de
Subject: re: install/56303: On a fresh installation, /tmp on sparc64 is not sticky
Date: Tue, 13 Jul 2021 19:21:11 +1000
> The minimum supported RAM according to the INSTALL document is 32 MB.
> That will probably have to be adjusted regardless, but unless we want
> to quadruple it rather than just doubling it, I think we need to
> switch back to tar.gz sets.
i ran anita against i386 recently with the default of 32
MB ram and i got a crash while extracting sets:
Command: progress -zf /mnt2//i386/binary/sets/base.tgz tar --chroot -x=
pf -
--------------------------------------------------------------------------=
------
99% |********************************** | 162 MiB 938.83 KiB/s 00:0=
0 ETApmap_get_physpage: out of memory
[ 223.8692584] cpu0: Begin traceback...
[ 223.8692584] ?(c0e73f4a,c4d04854,c4d04874,c049bfbd,c0e73f4a,c0d7c404,0,0=
,3,0) at c09ebdd9
[ 223.8692584] ?(c0e73f4a,c0d7c404,0,0,3,0,0,0,314,c4d048b0) at c09ebe83
[ 223.8692584] ?(c157b4c0,c1bd77c0,c0b66400,c19f5200,c4d048bc,14,0,c540000=
0,c18a0400,1) at c049bfbd
[ 223.8692584] ?(c5010000,c5000000,10000,c4d04904,0,ffffffff,ffffffff,1000=
0,601723,c15cf8c4) at c049c067
[ 223.8692584] ?(c15cf8c0,c5000000,10000,0,ffffffff,ffffffff,10000,601723,=
c4d04928,c1bc670c) at c095287e
[ 223.8692584] ?(c15cf8c0,c4d04990,10000,0,ffffffff,ffffffff,10000,601723,=
1,0) at c09538be
i realised that with the 21MB /netbsd GENERIC, there is
even less ram available now than 0.9 days and 16MB ram,
as the kernel wasn't even 1MB:
[ 1.0000000] total memory =3D 32252 KB
[ 1.0000000] avail memory =3D 10076 KB
so we're already well beyond 32MB minimum needed.
.mrg.
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@netbsd.org
Cc: martin@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
roland.illig@gmx.de
Subject: re: install/56303: On a fresh installation, /tmp on sparc64 is not sticky
Date: Tue, 13 Jul 2021 19:29:40 +1000
> The other part is that apparently
>
> progress -zf $(set).tar.xz tar --chroot $(path) -xpf -
>
> does not return failure properly. Sounds like a progress(1) or gizp(1)
> bug to me.
i just tested gzip(1) with RLIMIT_AS set to various values to see
what the failure mode is.
too low, shell can't exec and $? is 1, and prints eg:
Cannot map anonymous memoryCannot allocate memory: Cannot allocate memory
as it begins to be enough to start executing, failure occurs while
mapping shlibs, eg:
gzip: Shared object "libz.so.1" not found
or
/usr/lib/liblzma.so.2: Shared object "libpthread.so.1" not found
eventually gzip itself runs and fails, returning 2:
gzip: malloc failed: Cannot allocate memory
doing similar with progress also gives me either 1 or 2 failures.
i don't think it is either gzip or progress. at least, the normal
methods they could fail seem to be working here.
.mrg.
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Tue, 13 Jul 2021 11:36:21 +0200
On Tue, Jul 13, 2021 at 07:29:40PM +1000, matthew green wrote:
> i don't think it is either gzip or progress. at least, the normal
> methods they could fail seem to be working here.
I verified that all current sets extract fine with
xzcat -M 65M $set > /dev/null
so it is probably the sum of memory used by tar, the decompressor and sysinst
that makes it fail somewhere unexpectedly.
Anyway - next tests should run with swap enabled during installation, let's
see if that avoids the problem.
Martin
From: RVP <rvp@SDF.ORG>
To: gnats-bugs@netbsd.org
Cc: martin@netbsd.org
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Tue, 13 Jul 2021 09:49:54 +0000 (UTC)
On Tue, 13 Jul 2021, Martin Husemann wrote:
> The other part is that apparently
>
> progress -zf $(set).tar.xz tar --chroot $(path) -xpf -
>
> does not return failure properly. Sounds like a progress(1) or gizp(1)
> bug to me.
>
Yeah, there is a bug in progress. Sometimes it won't return an error
status if gzip is dies or is killed in the middle of extraction:
$ ./progress_test.sh /mnt/amd64/binary/sets/*.xz
base.tar.xz
29% |********** | 64460 KiB 20.90 MiB/s 00:07 ETA./usr/bin/sqlite3: Truncated tar archive
tar: Error exit delayed from previous errors.
32% |*********** | 71194 KiB 20.80 MiB/s 00:06 ETA
comp.tar.xz
16% |***** | 92497 KiB 29.91 MiB/s 00:15 ETA./usr/lib/libarchive_p.a: Truncated tar archive
tar: Error exit delayed from previous errors.
17% |***** | 99147 KiB 29.87 MiB/s 00:14 ETA
$
Run progress_test.sh, then `pkill -x gzip' in another window.
---
#!/bin/sh
set -eu -o pipefail
trap 'rm -rf X' 0 1 2 3 15
cd /tmp
for f
do mkdir X
echo "$(basename "$f")"
progress -zf $f tar -C X -xf -
sudo rm -rf X
done
---
This small patch makes progress return the correct exit status:
---START---
--- progress.c.orig 2021-07-13 09:23:10.198335692 +0000
+++ progress.c 2021-07-13 09:21:42.758123880 +0000
@@ -247,6 +247,11 @@
}
close(outpipe[1]);
+ progressmeter(1);
+ signal(SIGPIPE, SIG_DFL);
+
+ free(fb_buf);
+
gzipstat = 0;
cmdstat = 0;
while (pid || gzippid) {
@@ -258,9 +263,6 @@
* error without sending the signal to ourselves :-(
*/
ws = WIFSIGNALED(ws) ? WTERMSIG(ws) : WEXITSTATUS(ws);
-
- if (deadpid != -1 && errno == EINTR)
- continue;
if (deadpid == pid) {
pid = 0;
cmdstat = ws;
@@ -274,10 +276,5 @@
break;
}
- progressmeter(1);
- signal(SIGPIPE, SIG_DFL);
-
- free(fb_buf);
-
exit(cmdstat ? cmdstat : gzipstat);
}
---END---
-RVP
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not sticky
Date: Tue, 13 Jul 2021 16:51:08 +0700
Date: Tue, 13 Jul 2021 08:55:03 +0000 (UTC)
From: Martin Husemann <martin@duskware.de>
Message-ID: <20210713085503.0CA3C1A924C@mollari.NetBSD.org>
| We can not do that, the ISO just does not fit on a real CD with gzip
| and many sparc64 machines did come with CD drives instead of DVD.
It might be time to switch to a multi-cd distribution - it will eventually
be needed anyway, we cannot keep relying on better and better compression
algorithms just happening to be available when we need them, and like it or
not, the system just keeps getting bigger.
I'd expect all would be fine if the base system (everything required to
boot & install, and the required sets) were on one CD, and all the "can
run, kind of, without this" sets (X, comp, doc, text ...) were on another
(or even another two or more as needed).
sysinst could either request mounting of a second cd when needed, or if the
first is being used as root, so cannot be removed, just tell people what to
do to extract any of the remaining sets that they want, after the system is
running - sysinst could even leave a script in /root to do that.
kre
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Tue, 13 Jul 2021 12:12:41 +0200
On Tue, Jul 13, 2021 at 09:55:01AM +0000, Robert Elz wrote:
> It might be time to switch to a multi-cd distribution - it will eventually
> be needed anyway, we cannot keep relying on better and better compression
> algorithms just happening to be available when we need them, and like it or
> not, the system just keeps getting bigger.
I would go a different route: provide two ISO images, one small (easily
fits on CD, does not have any sets on it, but is usefull for recovery
and emergency repair) and one big (requires DVD, has full sets
including debug/xdebug).
The small install CD still can be used w/o much effort to install a system
by either downloading the sets directly onto the target machine, or getting
them e.g. from a local NFS server.
Finding proper names for them and updating the install documentation is
the hardest part. Second hardest part may be space issues on ftp.netbsd.org.
IIRC sysinst already recognizes the missing install sets and just deals
with it, but would need a bit more testing once the real images exist.
Martin
From: Andreas Gustafsson <gson@gson.org>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Tue, 20 Jul 2021 16:14:31 +0300
Martin Husemann wrote:
> Anyway - next tests should run with swap enabled during installation, let's
> see if that avoids the problem.
How can I tell if swap was actually enabled during installation? The
console log from the latest install attempt shows a swap partition
size of zero, so it's not clear to me what the install kernel would
be swapping to:
http://releng.netbsd.org/b5reports/sparc64/2021/2021.07.19.16.31.19/install.log
--
Andreas Gustafsson, gson@gson.org
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56303 CVS commit: src/usr.sbin/sysinst
Date: Tue, 20 Jul 2021 16:41:27 +0000
Module Name: src
Committed By: martin
Date: Tue Jul 20 16:41:27 UTC 2021
Modified Files:
src/usr.sbin/sysinst: bsddisklabel.c
Log Message:
PR 56303: do not borrow from the default swap allocation if we are in
tiny ram conditions and will need to enable swap early.
To generate a diff of this commit:
cvs rdiff -u -r1.58 -r1.59 src/usr.sbin/sysinst/bsddisklabel.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Thu, 22 Jul 2021 18:32:59 +0200
It now seems to properly create a swap partition and extraction
seems to work as intended ... but take too long in the quemu setup.
Could you try with a longer timeout?
Martin
From: Andreas Gustafsson <gson@gson.org>
To: martin@netbsd.org
Cc: gnats-bugs@netbsd.org, roland.illig@gmx.de
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Fri, 23 Jul 2021 10:45:30 +0300
Martin Husemann wrote:
> It now seems to properly create a swap partition and extraction
> seems to work as intended ... but take too long in the quemu setup.
There appears to be a great deal of variability in the amount of time
it takes to complete the install - it sometimes completes in less than
an hour, and sometimes does not complete within the current 3-hour
timeout. This issue predates the present PR and its related commits.
> Could you try with a longer timeout?
Not easily as the timeout is currently hardcoded in anita. I will
put it on the list of things to address in the next anita release.
In any case, installing the version immediately after your latest
sysinst commits did succeed, and is currently running the tests:
http://releng.netbsd.org/b5reports/sparc64/commits-2021.07.html#2021.07.20.16.41.27
--
Andreas Gustafsson, gson@gson.org
From: Andreas Gustafsson <gson@gson.org>
To: martin@netbsd.org
Cc: gnats-bugs@netbsd.org, roland.illig@gmx.de
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Sat, 24 Jul 2021 15:27:46 +0300
Yesterday, I wrote:
> it sometimes completes in less than an hour, and sometimes does not
> complete within the current 3-hour timeout.
To be precise, the current 3-hour timeout resets each time the
extraction of a new set begins, so in the failed installs, a single
set is taking longer than that to extract.
--
Andreas Gustafsson, gson@gson.org
From: Andreas Gustafsson <gson@gson.org>
To: martin@netbsd.org
Cc: gnats-bugs@netbsd.org, roland.illig@gmx.de
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Mon, 26 Jul 2021 12:30:01 +0300
I verified that the swap partition is now actually being swapped on, by
running sysinst manually, escaping to a shell, and running "swapctl -l":
# swapctl -l
Device 1K-blocks Used Avail Capacity Priority
/dev/wd0b 131072 57768 73304 44% 0
However, enabling swap did not appear to fix the problem. On the TNF
testbed, most installation attempts have timed out, but at least this
one installed successfully:
http://releng.netbsd.org/b5reports/sparc64/commits-2021.07.html#2021.07.24.11.39.19
It's still running the tests, but I booted the installed image manually and
its /tmp was still drwxr-xr-x.
Same thing on my own testbed, even though it is configured with 256 MB of RAM:
https://www.gson.org/netbsd/bugs/build/sparc64/commits-2021.07.html#2021.07.23.17.06.37
--
Andreas Gustafsson, gson@gson.org
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Mon, 26 Jul 2021 11:44:58 +0200
On Mon, Jul 26, 2021 at 12:30:01PM +0300, Andreas Gustafsson wrote:
> It's still running the tests, but I booted the installed image manually and
> its /tmp was still drwxr-xr-x.
>
> Same thing on my own testbed, even though it is configured with 256 MB of RAM:
>
> https://www.gson.org/netbsd/bugs/build/sparc64/commits-2021.07.html#2021.07.23.17.06.37
OK, so not memory shortage for the decompression - which would have been
bad luck anyway as our overall usage during that phase should be way lower.
I wonder if this is the same underlying cause (my guess: a tar(1) bug)
that causes PR install/56326, but I have no idea how to catch it
(besides sprinkling some kind of logging into the tar binary).
Martin
From: Andreas Gustafsson <gson@gson.org>
To: martin@netbsd.org
Cc: gnats-bugs@netbsd.org,
roland.illig@gmx.de,
rvp@SDF.ORG
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Mon, 26 Jul 2021 13:20:14 +0300
Martin Husemann wrote:
> I wonder if this is the same underlying cause (my guess: a tar(1) bug)
> that causes PR install/56326, but I have no idea how to catch it
> (besides sprinkling some kind of logging into the tar binary).
Have you looked at rvp's test script and patch? I couldn't reproduce
the problem using the script on -9/amd64, and I don't fully understand
the patch, but this line in progress.c which is removed by the patch
certainly looks wrong because it's testing errno when no error has
occurred:
if (deadpid != -1 && errno == EINTR)
I wonder if changing it to this would be sufficient:
if (deadpid == -1 && errno == EINTR)
--
Andreas Gustafsson, gson@gson.org
From: RVP <rvp@SDF.ORG>
To: Andreas Gustafsson <gson@gson.org>
Cc: martin@netbsd.org, gnats-bugs@netbsd.org, roland.illig@gmx.de,
Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>, vezhlys@gmail.com
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Tue, 27 Jul 2021 05:48:32 +0000 (UTC)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-271137700-1627364913=:9396
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Mon, 26 Jul 2021, Andreas Gustafsson wrote:
> Martin Husemann wrote:
>> I wonder if this is the same underlying cause (my guess: a tar(1) bug)
>> that causes PR install/56326, but I have no idea how to catch it
>> (besides sprinkling some kind of logging into the tar binary).
>
> Have you looked at rvp's test script and patch? I couldn't reproduce
> the problem using the script on -9/amd64, and I don't fully understand
> the patch, but this line in progress.c which is removed by the patch
> certainly looks wrong because it's testing errno when no error has
> occurred:
>
> if (deadpid != -1 && errno == EINTR)
>
> I wonder if changing it to this would be sufficient:
>
> if (deadpid == -1 && errno == EINTR)
>
On Mon, 26 Jul 2021, Izumi Tsutsui wrote:
> Not 100% reproducible, but happens again on 9.2 to 9.2 upgrade:
> ---
> -rwxr-xr-x 1 root wheel 20688364 May 12 13:15 netbsd
> -rwxr-xr-x 1 root wheel 13237760 Jul 26 13:52 netbsd17eUKh
> ---
>
I'm not able to reproduce this on my HW--might have to set up an
i386/Sparc Qemu (instructions welcome) to really chase this down,
but this looks like what happens if the input to tar closes
unexpectedly (or, you do Ctrl-C in the middle of extraction).
As I noted before, the current progress sometimes loses the status
of the gzip command, so, I've modified, and simplified, progress.c
slightly so that it returns a proper exit code every time.
Please try this new version; then we can see what causes tar to
abort mid-stream.
Thanks,
-RVP
--0-271137700-1627364913=:9396
Content-Type: text/plain; charset=US-ASCII; name=progress.c
Content-Transfer-Encoding: BASE64
Content-ID: <ea298b74-f670-1fcd-ec9d-a9a42d7ad47@SDF.ORG>
Content-Description: new progress.c
Content-Disposition: attachment; filename=progress.c
LyoJJE5ldEJTRDogcHJvZ3Jlc3MuYyx2IDEuMjMgMjAyMS8wMS8wNyAxMjow
Mjo1MiBsdWtlbSBFeHAgJCAqLw0KDQovKi0NCiAqIENvcHlyaWdodCAoYykg
MjAwMyBUaGUgTmV0QlNEIEZvdW5kYXRpb24sIEluYy4NCiAqIEFsbCByaWdo
dHMgcmVzZXJ2ZWQuDQogKg0KICogVGhpcyBjb2RlIGlzIGRlcml2ZWQgZnJv
bSBzb2Z0d2FyZSBjb250cmlidXRlZCB0byBUaGUgTmV0QlNEIEZvdW5kYXRp
b24NCiAqIGJ5IEpvaG4gSGF3a2luc29uLg0KICoNCiAqIFJlZGlzdHJpYnV0
aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGgg
b3Igd2l0aG91dA0KICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHBy
b3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zDQogKiBhcmUg
bWV0Og0KICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11
c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQNCiAqICAgIG5vdGljZSwg
dGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlz
Y2xhaW1lci4NCiAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9y
bSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0DQogKiAgICBu
b3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93
aW5nIGRpc2NsYWltZXIgaW4gdGhlDQogKiAgICBkb2N1bWVudGF0aW9uIGFu
ZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJp
YnV0aW9uLg0KICoNCiAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkg
VEhFIE5FVEJTRCBGT1VOREFUSU9OLCBJTkMuIEFORCBDT05UUklCVVRPUlMN
CiAqIGBgQVMgSVMnJyBBTkQgQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJS
QU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRA0KICogVE8sIFRI
RSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBG
SVRORVNTIEZPUiBBIFBBUlRJQ1VMQVINCiAqIFBVUlBPU0UgQVJFIERJU0NM
QUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgRk9VTkRBVElPTiBPUiBD
T05UUklCVVRPUlMNCiAqIEJFIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5E
SVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1INCiAq
IENPTlNFUVVFTlRJQUwgREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJ
TUlURUQgVE8sIFBST0NVUkVNRU5UIE9GDQogKiBTVUJTVElUVVRFIEdPT0RT
IE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsg
T1IgQlVTSU5FU1MNCiAqIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQg
QU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElODQog
KiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVE
SU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKQ0KICogQVJJU0lORyBJTiBB
TlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4g
SUYgQURWSVNFRCBPRiBUSEUNCiAqIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFN
QUdFLg0KICovDQoNCiNpbmNsdWRlIDxzeXMvY2RlZnMuaD4NCiNpZm5kZWYg
bGludA0KX19SQ1NJRCgiJE5ldEJTRDogcHJvZ3Jlc3MuYyx2IDEuMjMgMjAy
MS8wMS8wNyAxMjowMjo1MiBsdWtlbSBFeHAgJCIpOw0KI2VuZGlmCQkJCS8q
IG5vdCBsaW50ICovDQoNCiNpbmNsdWRlIDxzeXMvdHlwZXMuaD4NCiNpbmNs
dWRlIDxzeXMvc3RhdC5oPg0KI2luY2x1ZGUgPHN5cy93YWl0Lmg+DQoNCiNp
bmNsdWRlIDxlcnIuaD4NCiNpbmNsdWRlIDxlcnJuby5oPg0KI2luY2x1ZGUg
PGZjbnRsLmg+DQojaW5jbHVkZSA8aW50dHlwZXMuaD4NCiNpbmNsdWRlIDxs
aW1pdHMuaD4NCiNpbmNsdWRlIDxzaWduYWwuaD4NCiNpbmNsdWRlIDxzdGRp
by5oPg0KI2luY2x1ZGUgPHN0ZGxpYi5oPg0KI2luY2x1ZGUgPHN0cmluZy5o
Pg0KI2luY2x1ZGUgPHRlcm1pb3MuaD4NCiNpbmNsdWRlIDx1bmlzdGQuaD4N
Cg0KI2RlZmluZSBHTE9CQUwJCQkvKiBmb3JjZSBHTE9CQUwgZGVjbHMgaW4g
cHJvZ3Jlc3NiYXIuaCB0byBiZQ0KCQkJCSAqIGRlY2xhcmVkICovDQojaW5j
bHVkZSAicHJvZ3Jlc3NiYXIuaCINCg0Kc3RhdGljIHNzaXplX3QgbWF4d3Jp
dGUoaW50IGZkLCB2b2lkICpidWYsIHNpemVfdCBzaXplKTsNCl9fZGVhZCBz
dGF0aWMgdm9pZCB1c2FnZSh2b2lkKTsNCg0Kc3RhdGljIHZvaWQNCnVzYWdl
KHZvaWQpDQp7DQoJZnByaW50ZihzdGRlcnIsDQoJICAgICJ1c2FnZTogJXMg
Wy1lel0gWy1iIGJ1ZmZlcnNpemVdIFstZiBmaWxlXSBbLWwgbGVuZ3RoXVxu
Ig0KCSAgICAiICAgICAgICUqLnMgWy1wIHByZWZpeF0gY21kIFthcmdzLi4u
XVxuIiwNCgkgICAgZ2V0cHJvZ25hbWUoKSwgKGludCkgc3RybGVuKGdldHBy
b2duYW1lKCkpLCAiIik7DQoJZXhpdChFWElUX0ZBSUxVUkUpOw0KfQ0KDQpp
bnQNCm1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkNCnsNCgljaGFyICpm
Yl9idWY7DQoJY2hhciAqaW5maWxlID0gTlVMTDsNCglwaWRfdCBwaWQgPSAw
LCBnemlwcGlkID0gMDsNCglpbnQgY2gsIGlmZCwgb2ZkLCBvdXRwaXBlWzJd
Ow0KCWludCBnemlwc3RhdCwgY21kc3RhdDsNCglpbnQgZWZsYWcgPSAwLCBs
ZmxhZyA9IDAsIHpmbGFnID0gMDsNCglpbnQgcmMgPSBFWElUX0ZBSUxVUkU7
DQoJc2l6ZV90IGJ1ZmZlcnNpemU7DQoJc3RydWN0IHN0YXQgc3RhdGI7DQoJ
c3RydWN0IHdpbnNpemUgd2luOw0KDQoJc2V0cHJvZ25hbWUoYXJndlswXSk7
DQoNCgkvKiBkZWZhdWx0czogUmVhZCBmcm9tIHN0ZGluLCAwIGZpbGVzaXpl
IChubyBjb21wbGV0aW9uIGVzdGltYXRlKSAqLw0KCWlmZCA9IFNURElOX0ZJ
TEVOTzsNCglmaWxlc2l6ZSA9IDA7DQoJYnVmZmVyc2l6ZSA9IDY0ICogMTAy
NDsNCglwcmVmaXggPSBOVUxMOw0KDQoJd2hpbGUgKChjaCA9IGdldG9wdChh
cmdjLCBhcmd2LCAiYjplZjpsOnA6eiIpKSAhPSAtMSkNCgkJc3dpdGNoIChj
aCkgew0KCQljYXNlICdiJzoNCgkJCWJ1ZmZlcnNpemUgPSAoc2l6ZV90KSBz
dHJzdWZ0b2xsKCJidWZmZXIgc2l6ZSIsIG9wdGFyZywNCgkJCSAgICAwLCBT
U0laRV9NQVgpOw0KCQkJYnJlYWs7DQoJCWNhc2UgJ2UnOg0KCQkJZWZsYWcr
KzsNCgkJCWJyZWFrOw0KCQljYXNlICdmJzoNCgkJCWluZmlsZSA9IG9wdGFy
ZzsNCgkJCWJyZWFrOw0KCQljYXNlICdsJzoNCgkJCWxmbGFnKys7DQoJCQlm
aWxlc2l6ZSA9IHN0cnN1ZnRvbGwoImlucHV0IHNpemUiLCBvcHRhcmcsIDAs
DQoJCQkgICAgTExPTkdfTUFYKTsNCgkJCWJyZWFrOw0KCQljYXNlICdwJzoN
CgkJCXByZWZpeCA9IG9wdGFyZzsNCgkJCWJyZWFrOw0KCQljYXNlICd6JzoN
CgkJCXpmbGFnKys7DQoJCQlicmVhazsNCgkJY2FzZSAnPyc6DQoJCWRlZmF1
bHQ6DQoJCQl1c2FnZSgpOw0KCQkJLyogTk9UUkVBQ0hFRCAqLw0KCQl9DQoJ
YXJnYyAtPSBvcHRpbmQ7DQoJYXJndiArPSBvcHRpbmQ7DQoNCglpZiAoYXJn
YyA8IDEpDQoJCXVzYWdlKCk7DQoNCglpZiAoaW5maWxlICYmIChpZmQgPSBv
cGVuKGluZmlsZSwgT19SRE9OTFksIDApKSA8IDApDQoJCWVycihyYywgIiVz
IiwgaW5maWxlKTsNCg0KCS8qIHN0YXQoKSB0byBnZXQgdGhlIGZpbGVzaXpl
IHVubGVzcyBvdmVycmlkZGVuLCBvciAteiAqLw0KCWlmICghemZsYWcgJiYg
IWxmbGFnICYmIChmc3RhdChpZmQsICZzdGF0YikgPT0gMCkpIHsNCgkJaWYg
KFNfSVNSRUcoc3RhdGIuc3RfbW9kZSkpDQoJCQlmaWxlc2l6ZSA9IHN0YXRi
LnN0X3NpemU7DQoJfQ0KDQoJLyogZ3ppcCAtbCB0aGUgZmlsZSBpZiB3ZSBo
YXZlIHRoZSBuYW1lIGFuZCAteiBpcyBnaXZlbiAqLw0KCWlmICh6ZmxhZyAm
JiAhbGZsYWcgJiYgaW5maWxlICE9IE5VTEwpIHsNCgkJRklMRSAqZ3ppcHNp
emVwaXBlOw0KCQllbnVtIHsgU1ogPSAyNTYgfTsNCgkJY2hhciBidWZbU1pd
LCAqY3AsICpjbWQ7DQoNCgkJLyoNCgkJICogUmVhZCBzZWNvbmQgd29yZCBv
ZiBsYXN0IGxpbmUgb2YgZ3ppcCAtbCBvdXRwdXQuIExvb2tzIGxpa2U6DQoJ
CSAqICUgZ3ppcCAtbCAuLi9ldGMudGd6IA0KCQkgKiAgIGNvbXByZXNzZWQg
dW5jb21wcmVzc2VkICByYXRpbyB1bmNvbXByZXNzZWRfbmFtZQ0KCQkgKiAJ
IDExOTczNyAgICAgICA2OTYzMjAgIDgyLjglIC4uL2V0Yy50YXINCgkJICov
DQoNCgkJaWYgKGFzcHJpbnRmKCZjbWQsICJnemlwIC1sICVzIiwgaW5maWxl
KSA9PSAtMSkNCgkJCWVycihyYywgImFzcHJpbnRmIik7DQoJCWlmICgoZ3pp
cHNpemVwaXBlID0gcG9wZW4oY21kLCAiciIpKSA9PSBOVUxMKQ0KCQkJZXJy
KHJjLCAicmVhZGluZyBjb21wcmVzc2VkIGZpbGUgbGVuZ3RoIik7DQoJCWJ1
ZlswXSA9ICdcMCc7DQoJCXdoaWxlIChmZ2V0cyhidWYsIFNaLCBnemlwc2l6
ZXBpcGUpICE9IE5VTEwpDQoJCSAgICAvKiBFTVBUWSAqLzsNCgkJc3RydG9p
bWF4KGJ1ZiwgJmNwLCAxMCk7DQoJCWZpbGVzaXplID0gc3RydG9pbWF4KGNw
LCBOVUxMLCAxMCk7DQoJCWlmIChwY2xvc2UoZ3ppcHNpemVwaXBlKSA8IDAp
DQoJCQllcnIocmMsICJjbG9zaW5nIGNvbXByZXNzZWQgZmlsZSBsZW5ndGgg
cGlwZSIpOw0KCQlmcmVlKGNtZCk7DQoJfQ0KCS8qIFBpcGUgaW5wdXQgdGhy
b3VnaCBnemlwIC1kYyBpZiAteiBpcyBnaXZlbiAqLw0KCWlmICh6ZmxhZykg
ew0KCQlpbnQgZ3ppcHBpcGVbMl07DQoNCgkJaWYgKHBpcGUoZ3ppcHBpcGUp
IDwgMCkNCgkJCWVycihyYywgImd6aXAgcGlwZSIpOw0KCQlnemlwcGlkID0g
Zm9yaygpOw0KCQlpZiAoZ3ppcHBpZCA8IDApDQoJCQllcnIocmMsICJmb3Jr
IGZvciBnemlwIik7DQoNCgkJaWYgKGd6aXBwaWQpIHsNCgkJCS8qIHBhcmVu
dCAqLw0KCQkJZHVwMihnemlwcGlwZVswXSwgaWZkKTsNCgkJCWNsb3NlKGd6
aXBwaXBlWzBdKTsNCgkJCWNsb3NlKGd6aXBwaXBlWzFdKTsNCgkJfSBlbHNl
IHsNCgkJCWR1cDIoZ3ppcHBpcGVbMV0sIFNURE9VVF9GSUxFTk8pOw0KCQkJ
ZHVwMihpZmQsIFNURElOX0ZJTEVOTyk7DQoJCQljbG9zZShnemlwcGlwZVsw
XSk7DQoJCQljbG9zZShnemlwcGlwZVsxXSk7DQoJCQlpZiAoZXhlY2xwKCJn
emlwIiwgImd6aXAiLCAiLWRjIiwgTlVMTCkpDQoJCQkJZXJyKHJjLCAiZXhl
YygpaW5nIGd6aXAiKTsNCgkJfQ0KCX0NCg0KCS8qIEluaXRpYWxpemUgcHJv
Z3Jlc3NiYXIuYydzIGdsb2JhbCBzdGF0ZSAqLw0KCWJ5dGVzID0gMDsNCglw
cm9ncmVzcyA9IDE7DQoJdHR5b3V0ID0gZWZsYWcgPyBzdGRlcnIgOiBzdGRv
dXQ7DQoNCglpZiAodGNnZXR3aW5zaXplKGZpbGVubyh0dHlvdXQpLCAmd2lu
KSA9PSAtMSkNCgkJdHR5d2lkdGggPSA4MDsNCgllbHNlDQoJCXR0eXdpZHRo
ID0gd2luLndzX2NvbDsNCg0KCWZiX2J1ZiA9IG1hbGxvYyhidWZmZXJzaXpl
KTsNCglpZiAoZmJfYnVmID09IE5VTEwpDQoJCWVycihyYywgIm1hbGxvYyBm
b3IgYnVmZmVyc2l6ZSIpOw0KDQoJaWYgKHBpcGUob3V0cGlwZSkgPCAwKQ0K
CQllcnIocmMsICJvdXRwdXQgcGlwZSIpOw0KCXBpZCA9IGZvcmsoKTsNCglp
ZiAocGlkIDwgMCkNCgkJZXJyKHJjLCAiZm9yayBmb3Igb3V0cHV0IHBpcGUi
KTsNCg0KCWlmIChwaWQgPT0gMCkgew0KCQkvKiBjaGlsZCAqLw0KCQlkdXAy
KG91dHBpcGVbMF0sIFNURElOX0ZJTEVOTyk7DQoJCWNsb3NlKG91dHBpcGVb
MF0pOw0KCQljbG9zZShvdXRwaXBlWzFdKTsNCgkJZXhlY3ZwKGFyZ3ZbMF0s
IGFyZ3YpOw0KCQllcnIocmMsICJjb3VsZCBub3QgZXhlYyAlcyIsIGFyZ3Zb
MF0pOw0KCX0NCg0KCWNsb3NlKG91dHBpcGVbMF0pOw0KCW9mZCA9IG91dHBp
cGVbMV07DQoJc2lnbmFsKFNJR1BJUEUsIFNJR19JR04pOw0KCXByb2dyZXNz
bWV0ZXIoLTEpOw0KCWZvciAoOzspIHsNCgkJc3NpemVfdCBuciA9IHJlYWQo
aWZkLCBmYl9idWYsIGJ1ZmZlcnNpemUpOw0KCQlpZiAobnIgPCAwKSB7DQoJ
CQlpZiAoZXJybm8gPT0gRUlOVFIpDQoJCQkJY29udGludWU7DQoJCQllbHNl
DQoJCQkJYnJlYWs7DQoJCX0gZWxzZSBpZiAobnIgPT0gMCkgew0KCQkJcmMg
PSBFWElUX1NVQ0NFU1M7DQoJCQlicmVhazsNCgkJfSBlbHNlIHsNCgkJCWlm
IChtYXh3cml0ZShvZmQsIGZiX2J1ZiwgbnIpICE9IG5yKSB7DQoJCQkJcHJv
Z3Jlc3NtZXRlcigxKTsNCgkJCQllcnIocmMsICJ3cml0aW5nICV1IGJ5dGVz
IHRvIG91dHB1dCBwaXBlIiwNCgkJCQkJCQkodW5zaWduZWQpIG5yKTsNCgkJ
CX0NCgkJCWJ5dGVzICs9IG5yOw0KCQl9DQoJfQ0KCXByb2dyZXNzbWV0ZXIo
MSk7DQoJZnJlZShmYl9idWYpOw0KCWNsb3NlKG9mZCk7DQoJY2xvc2UoaWZk
KTsNCg0KCWd6aXBzdGF0ID0gMDsNCgljbWRzdGF0ID0gMDsNCgl3aGlsZSAo
cGlkIHx8IGd6aXBwaWQpIHsNCgkJaW50IGRlYWRwaWQ7DQoJCXBpZF90IHdz
Ow0KDQoJCWRlYWRwaWQgPSB3YWl0KCZ3cyk7DQoJCS8qDQoJCSAqIFdlIG5l
ZWQgdG8gZXhpdCB3aXRoIGFuIGVycm9yIGlmIHRoZSBjb21tYW5kIChvciBn
emlwKQ0KCQkgKiBleGl0ZWQgYWJub3JtYWxseS4NCgkJICovDQoJCXdzID0g
V0lGU0lHTkFMRUQod3MpID8gV1RFUk1TSUcod3MpIDogV0VYSVRTVEFUVVMo
d3MpOw0KCQlpZiAoZGVhZHBpZCA9PSBwaWQpIHsNCgkJCXBpZCA9IDA7DQoJ
CQljbWRzdGF0ID0gd3M7DQoJCQljb250aW51ZTsNCgkJfQ0KCQlpZiAoZGVh
ZHBpZCA9PSBnemlwcGlkKSB7DQoJCQlnemlwcGlkID0gMDsNCgkJCWd6aXBz
dGF0ID0gd3M7DQoJCQljb250aW51ZTsNCgkJfQ0KCQlicmVhazsNCgl9DQoN
CglpZiAoY21kc3RhdCkNCgkJZXhpdChjbWRzdGF0KTsNCglpZiAoZ3ppcHN0
YXQpDQoJCWV4aXQoZ3ppcHN0YXQpOw0KCWV4aXQocmMpOw0KfQ0KDQpzdGF0
aWMgc3NpemVfdA0KbWF4d3JpdGUoaW50IGZkLCB2b2lkICpidWYsIHNpemVf
dCBzaXplKQ0Kew0KCWNvbnN0IGNoYXIgKnAgPSBidWY7DQoJc3NpemVfdCBu
d3IgPSAwOw0KCXNzaXplX3QgbjsNCg0KCXdoaWxlIChzaXplID4gMCkgew0K
CQlpZiAoKG4gPSB3cml0ZShmZCwgcCwgc2l6ZSkpID09IC0xKSB7DQoJCQlz
d2l0Y2ggKGVycm5vKSB7DQoJCQljYXNlIEVJTlRSOg0KCQkJY2FzZSBFQUdB
SU46DQojaWYgZGVmaW5lZChFV09VTERCTE9DSykgJiYgRVdPVUxEQkxPQ0sg
IT0gRUFHQUlODQoJCQljYXNlIEVXT1VMREJMT0NLOg0KI2VuZGlmDQoJCQkJ
Y29udGludWU7DQoJCQlkZWZhdWx0Og0KCQkJCXJldHVybiBud3I7DQoJCQl9
DQoJCX0NCgkJcCArPSBuOw0KCQlud3IgKz0gbjsNCgkJc2l6ZSAtPSBuOw0K
CX0NCglyZXR1cm4gbndyOw0KfQ0K
--0-271137700-1627364913=:9396--
From: "Andreas Gustafsson" <gson@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56303 CVS commit: src/usr.bin/progress
Date: Mon, 9 Aug 2021 10:46:39 +0000
Module Name: src
Committed By: gson
Date: Mon Aug 9 10:46:39 UTC 2021
Modified Files:
src/usr.bin/progress: progress.c
Log Message:
Test errno when the return value from wait() indicates an error, not
when it indicates success. PR install/56303.
To generate a diff of this commit:
cvs rdiff -u -r1.23 -r1.24 src/usr.bin/progress/progress.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Fri, 13 Aug 2021 10:40:05 +0200
PR 56359 has been closed as a duplicate of this bug (it notes the same
effect on i386 and vax, both architectures do not use .tar.xz sets).
Martin
From: Andreas Gustafsson <gson@gson.org>
To: gnats-bugs@netbsd.org
Cc: martin@netbsd.org, RVP <rvp@SDF.ORG>, roland.illig@gmx.de, Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>, vezhlys@gmail.com
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Fri, 13 Aug 2021 11:53:02 +0300
Looks like the problem was fixed by my commit of
src/usr.bin/progress/progress.c 1.24, as it has
not recurred on the testbeds since then:
http://releng.netbsd.org/b5reports/sparc64/commits-2021.08.html#2021.08.09.10.46.39
https://www.gson.org/netbsd/bugs/build/sparc64/commits-2021.08.html#2021.08.09.10.46.39
--
Andreas Gustafsson, gson@gson.org
From: Andreas Gustafsson <gson@gson.org>
To: RVP <rvp@SDF.ORG>
Cc: gnats-bugs@netbsd.org, martin@netbsd.org, roland.illig@gmx.de, Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>, vezhlys@gmail.com
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not sticky
Date: Fri, 13 Aug 2021 12:08:36 +0300
RVP,
You wrote:
> As I noted before, the current progress sometimes loses the status
> of the gzip command, so, I've modified, and simplified, progress.c
> slightly so that it returns a proper exit code every time.
>
> Please try this new version; then we can see what causes tar to
> abort mid-stream.
I believe my minimal change of progress.c 1.24 was sufficient to fix
the problem of the present PR. Your suggested changes hint at other
bugs in progress(1) that also ought to be fixed, but a complete
replacement of the entire source file is not the appropriate way to
fix them. Please file a separate PR for each remaining progress(1)
bug, with a patch if possible, but more importantly, with a
description of the problem.
--
Andreas Gustafsson, gson@gson.org
State-Changed-From-To: open->feedback
State-Changed-By: gson@NetBSD.org
State-Changed-When: Fri, 13 Aug 2021 09:55:54 +0000
State-Changed-Why:
Fixed?
From: Andreas Gustafsson <gson@gson.org>
To: gnats-bugs@NetBSD.org
Cc: Martin Husemann <martin@duskware.de>
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not sticky
Date: Tue, 17 Aug 2021 10:10:52 +0300
On July 12, I wrote:
> For example, if I escape to a shell during set extraction by typing
> control-z, manually kill the gzip -dc process, and exit the shell,
> sysinst appears to continue like nothing happened and says all sets
> extracted successfully.
This is no longer the case - performing the same test now causes
sysinst to report errors, as it should:
Status: Command failed
Command: progress -zf /sparc64/binary/sets/kern-GENERIC.tar.xz tar --chroot -xpf -
Hit enter to continue
/netbsd: Truncated tar archive
tar: Error exit delayed from previous errors.
--
Andreas Gustafsson, gson@gson.org
From: "Andreas Gustafsson" <gson@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56303 CVS commit: src/usr.bin/progress
Date: Tue, 17 Aug 2021 07:18:43 +0000
Module Name: src
Committed By: gson
Date: Tue Aug 17 07:18:43 UTC 2021
Modified Files:
src/usr.bin/progress: progress.c
Log Message:
Add missing check for error returns from read(). Found by inspection
while reviewing the changes suggested by RVP in PR install/56303, but
not believed to be the cause of the failure reported in that PR.
To generate a diff of this commit:
cvs rdiff -u -r1.24 -r1.25 src/usr.bin/progress/progress.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: RVP <rvp@SDF.ORG>
To: Andreas Gustafsson <gson@gson.org>
Cc: gnats-bugs@netbsd.org, martin@netbsd.org, roland.illig@gmx.de,
Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>, vezhlys@gmail.com
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Tue, 17 Aug 2021 22:54:28 +0000 (UTC)
On Fri, 13 Aug 2021, Andreas Gustafsson wrote:
> You wrote:
>> As I noted before, the current progress sometimes loses the status
>> of the gzip command, so, I've modified, and simplified, progress.c
>> slightly so that it returns a proper exit code every time.
>>
>> Please try this new version; then we can see what causes tar to
>> abort mid-stream.
>
> I believe my minimal change of progress.c 1.24 was sufficient to fix
> the problem of the present PR. Your suggested changes hint at other
> bugs in progress(1) that also ought to be fixed, but a complete
> replacement of the entire source file is not the appropriate way to
> fix them. Please file a separate PR for each remaining progress(1)
> bug, with a patch if possible, but more importantly, with a
> description of the problem.
>
Sorry for the late reply, but I am a bit bogged down at the moment.
Re: progress.c 1.24: This test which you modified is not needed:
if (deadpid == -1 && errno == EINTR)
continue;
By ths point all read/writes have finished, and `outpipe[1]' has
been closed. So you can stop the progress bar code right after the
`while (1)' loop and no interrupts can occur. This is what my
initial patch did. The subsequent patch is more of the same: dotting
the Is and crossing the Ts--very straight-forward stuff, but I
wanted to ensure that progress(1) exited with a proper error code
everytime.
Hope that helps. Feel free to use any or all of the changes I made.
-RVP
State-Changed-From-To: feedback->closed
State-Changed-By: rillig@NetBSD.org
State-Changed-When: Fri, 20 Aug 2021 07:07:15 +0000
State-Changed-Why:
Looks fixed to me. I only reported this bug based on the log file from the
releng build. That build log currently shows no signs of /tmp being
non-sticky. Instead, it contains:
> lib/libc/sys/t_ptrace_wait
> access_regs_set_unaligned_pc_0x1: [0.208920s] Passed.
> access_regs_set_unaligned_pc_0x3:
> assertion "dc->jump_pc[1] == dc->pc + 4" failed:
> file "/pkg_comp/obj/pkgsrc/emulators/qemu/default/qemu-5.1.0/target/sparc/translate.c",
> line 5860, function "sparc_tr_insn_start"
> pexpect reported EOF - VMM exited unexpectedly
That seems to be an unrelated problem though.
From: Andreas Gustafsson <gson@gson.org>
To: rillig@NetBSD.org
Cc: gnats-bugs@netbsd.org, martin@netbsd.org, roland.illig@gmx.de
Subject: Re: install/56303 (On a fresh installation, /tmp on sparc64 is not sticky)
Date: Fri, 20 Aug 2021 10:16:26 +0300
rillig@NetBSD.org wrote:
> Looks fixed to me. I only reported this bug based on the log file from the
> releng build. That build log currently shows no signs of /tmp being
> non-sticky. Instead, it contains:
>
> > lib/libc/sys/t_ptrace_wait
> > access_regs_set_unaligned_pc_0x1: [0.208920s] Passed.
> > access_regs_set_unaligned_pc_0x3:
> > assertion "dc->jump_pc[1] == dc->pc + 4" failed:
> > file "/pkg_comp/obj/pkgsrc/emulators/qemu/default/qemu-5.1.0/target/sparc/translate.c",
> > line 5860, function "sparc_tr_insn_start"
> > pexpect reported EOF - VMM exited unexpectedly
>
> That seems to be an unrelated problem though.
Yes, that's qemu crashing, which is a bug in qemu rather than NetBSD
by definition.
--
Andreas Gustafsson, gson@gson.org
From: Andreas Gustafsson <gson@gson.org>
To: RVP <rvp@SDF.ORG>
Cc: gnats-bugs@netbsd.org,
martin@netbsd.org,
roland.illig@gmx.de,
Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>,
vezhlys@gmail.com
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not sticky
Date: Fri, 20 Aug 2021 11:04:35 +0300
RVP wrote:
> Re: progress.c 1.24: This test which you modified is not needed:
>
> if (deadpid == -1 && errno == EINTR)
> continue;
>
> By ths point all read/writes have finished, and `outpipe[1]' has
> been closed. So you can stop the progress bar code right after the
> `while (1)' loop and no interrupts can occur. This is what my
> initial patch did.
Closing outpipe[1] eliminates one source of signals, but I don't see
any obvious way of proving that there can be no others.
> The subsequent patch is more of the same: dotting
> the Is and crossing the Ts--very straight-forward stuff, but I
> wanted to ensure that progress(1) exited with a proper error code
> everytime.
And, it appears, to do various unrelated cleanups at the same time.
Don't get me wrong, cleanups are welcome, but lumping them all
together in a single patch, or even a wholesale replacement of the
entire source file, makes them hard to review and to separate into
individual commits with appropriate commit messages.
For example, you are replacing a call to ioctl(TIOCGSIZE) by
tcgetwinsize(), but it is not clear to me _why_ that change is being
made, and no developer should commit changes whose purpose they don't
understand.
--
Andreas Gustafsson, gson@gson.org
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: martin@netbsd.org,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
roland.illig@gmx.de
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Fri, 20 Aug 2021 11:06:51 +0300
--Apple-Mail=_708BD699-E392-4947-AA0B-31E6C39351F9
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii
>
> For example, you are replacing a call to ioctl(TIOCGSIZE) by
> tcgetwinsize(), but it is not clear to me _why_ that change is being
> made, and no developer should commit changes whose purpose they don't
> understand.
That's a good change, replacing a non-portable ioctl call with a posix terms
function call.
christos
--Apple-Mail=_708BD699-E392-4947-AA0B-31E6C39351F9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYR9imwAKCRBxESqxbLM7
Oji+AJ4qwx6bQtVugYiQfcwhPxiKyLQhAQCgipsWcp2JmpJeSPbCPrMWrHDe8xg=
=E6kU
-----END PGP SIGNATURE-----
--Apple-Mail=_708BD699-E392-4947-AA0B-31E6C39351F9--
From: RVP <rvp@SDF.ORG>
To: Andreas Gustafsson <gson@gson.org>
Cc: gnats-bugs@netbsd.org, martin@netbsd.org, roland.illig@gmx.de,
Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>, vezhlys@gmail.com
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Mon, 23 Aug 2021 08:35:14 +0000 (UTC)
On Fri, 20 Aug 2021, Andreas Gustafsson wrote:
> RVP wrote:
>> Re: progress.c 1.24: This test which you modified is not needed:
>>
>> if (deadpid == -1 && errno == EINTR)
>> continue;
>>
>> By ths point all read/writes have finished, and `outpipe[1]' has
>> been closed. So you can stop the progress bar code right after the
>> `while (1)' loop and no interrupts can occur. This is what my
>> initial patch did.
>
> Closing outpipe[1] eliminates one source of signals, but I don't see
> any obvious way of proving that there can be no others.
>
Not sure what you mean here: Only caught signals (ALRM and PIPE--but the
PIPE handler causes a termination) can cause wait() to return an EINTR.
If the progress bar is turned off, and there are no writes, wait() can't
come back with a -1 and EINTR. Which signals are you worried about here?
>> The subsequent patch is more of the same: dotting
>> the Is and crossing the Ts--very straight-forward stuff, but I
>> wanted to ensure that progress(1) exited with a proper error code
>> everytime.
>
> And, it appears, to do various unrelated cleanups at the same time.
> Don't get me wrong, cleanups are welcome, but lumping them all
> together in a single patch, or even a wholesale replacement of the
> entire source file, makes them hard to review and to separate into
> individual commits with appropriate commit messages.
>
The diff is slightly large, but, most of the changes are simple, obvious
ones, and the core logic is practically the same, so hardly a wholesale
replacement...
On Fri, 20 Aug 2021, Christos Zoulas wrote:
> That's a good change, replacing a non-portable ioctl call with a posix
> terms function call.
>
That was the intent, yes.
-RVP
From: Andreas Gustafsson <gson@gson.org>
To: RVP <rvp@SDF.ORG>
Cc: gnats-bugs@netbsd.org,
martin@netbsd.org,
roland.illig@gmx.de,
Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>,
vezhlys@gmail.com,
christos@NetBSD.org
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not sticky
Date: Thu, 26 Aug 2021 18:45:16 +0300
RVP wrote:
> >> Re: progress.c 1.24: This test which you modified is not needed:
> >>
> >> if (deadpid == -1 && errno == EINTR)
> >> continue;
> >>
> >> By ths point all read/writes have finished, and `outpipe[1]' has
> >> been closed. So you can stop the progress bar code right after the
> >> `while (1)' loop and no interrupts can occur. This is what my
> >> initial patch did.
> >
> > Closing outpipe[1] eliminates one source of signals, but I don't see
> > any obvious way of proving that there can be no others.
>
> Not sure what you mean here: Only caught signals (ALRM and PIPE--but the
> PIPE handler causes a termination) can cause wait() to return an EINTR.
> If the progress bar is turned off, and there are no writes, wait() can't
> come back with a -1 and EINTR.
Yes, _if_ the progress bar has been turned off at that point, but that
is not currently the case. It would be the case if we also applied
one of your other changes, moving the progressmeter(1) call to before
the wait() calls, but I don't think that change is a good idea; it
would cause the progress command to indicate that the operation is
complete before the "cmd" has actually finished, and the final
transfer rate estimate would no longer account for the full execution
time of the "cmd".
> The diff is slightly large, but, most of the changes are simple, obvious
> ones, and the core logic is practically the same, so hardly a wholesale
> replacement...
By "wholesale replacement", I was referring to sending a complete
source file as opposed to patches.
> On Fri, 20 Aug 2021, Christos Zoulas wrote:
> > That's a good change, replacing a non-portable ioctl call with a posix
> > terms function call.
>
> That was the intent, yes.
Since Christos supports that change, perhaps you can ask him to commit it.
In any case, it is outside scope of the present (closed) PR.
--
Andreas Gustafsson, gson@gson.org
From: RVP <rvp@SDF.ORG>
To: Andreas Gustafsson <gson@gson.org>
Cc: gnats-bugs@netbsd.org, martin@netbsd.org, roland.illig@gmx.de,
Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>, vezhlys@gmail.com,
christos@NetBSD.org
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Thu, 26 Aug 2021 22:38:37 +0000 (UTC)
On Thu, 26 Aug 2021, Andreas Gustafsson wrote:
> Yes, _if_ the progress bar has been turned off at that point, but that
> is not currently the case. It would be the case if we also applied
> one of your other changes, moving the progressmeter(1) call to before
> the wait() calls, but I don't think that change is a good idea; it
> would cause the progress command to indicate that the operation is
> complete before the "cmd" has actually finished, and the final
> transfer rate estimate would no longer account for the full execution
> time of the "cmd".
>
Should be OK, seeing as the only metrics used for the progress-bar are
`filesize' (even if -1) and `bytes'. Ie. progress(1) mainly deals in the
data it passes through, and not total execution time.
-RVP
From: Andreas Gustafsson <gson@gson.org>
To: RVP <rvp@SDF.ORG>
Cc: Andreas Gustafsson <gson@gson.org>,
gnats-bugs@netbsd.org,
martin@netbsd.org,
roland.illig@gmx.de,
Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>,
vezhlys@gmail.com,
christos@NetBSD.org
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Fri, 27 Aug 2021 09:39:59 +0300
RVP wrote:
> Should be OK, seeing as the only metrics used for the progress-bar are
> `filesize' (even if -1) and `bytes'. Ie. progress(1) mainly deals in the
> data it passes through, and not total execution time.
It also displays a transfer rate:
100% |*******************************| 680 KiB 264.59 KiB/s 00:00 ETA
The final transfer rate displayed will be based on the current time as
of the call to progressmeter(1), and since this call is currently made
after waiting for the "cmd" to exit, it _will_ reflect the total
execution time. I don't think making this display less accurate for
the sake of eliminating two lines of code would be a good trade-off.
--
Andreas Gustafsson, gson@gson.org
From: RVP <rvp@SDF.ORG>
To: Andreas Gustafsson <gson@gson.org>
Cc: gnats-bugs@netbsd.org, martin@netbsd.org, roland.illig@gmx.de,
Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>, vezhlys@gmail.com,
christos@NetBSD.org
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
sticky
Date: Fri, 27 Aug 2021 23:21:01 +0000 (UTC)
On Fri, 27 Aug 2021, Andreas Gustafsson wrote:
> 100% |*******************************| 680 KiB 264.59 KiB/s 00:00 ETA
>
> The final transfer rate displayed will be based on the current time as
> of the call to progressmeter(1), and since this call is currently made
> after waiting for the "cmd" to exit, it _will_ reflect the total
> execution time.
>
Yes, but should wait time (which is not IO time) be included in a xfer
statistic? I felt that it was not, which is why I stopped the progress-bar
before wait(). That it allowed me to get rid of 2 lines was an added
bonus.
But, really: I'm OK with progressbar(1) after the wait too. (After all,
progress might well be called on to run a program which xfers files at 110
baud--then you would see a different KiB/s between the 2 methods...)
-RVP
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56303 CVS commit: [netbsd-9] src/usr.bin/progress
Date: Tue, 25 Oct 2022 17:52:46 +0000
Module Name: src
Committed By: martin
Date: Tue Oct 25 17:52:46 UTC 2022
Modified Files:
src/usr.bin/progress [netbsd-9]: progress.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #1547):
usr.bin/progress/progress.c: revision 1.24
usr.bin/progress/progress.c: revision 1.25
Test errno when the return value from wait() indicates an error, not
when it indicates success. PR install/56303.
Add missing check for error returns from read(). Found by inspection
while reviewing the changes suggested by RVP in PR install/56303, but
not believed to be the cause of the failure reported in that PR.
To generate a diff of this commit:
cvs rdiff -u -r1.21.18.1 -r1.21.18.2 src/usr.bin/progress/progress.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2022
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home