ZFS rename with associated snapshot present: odd error message
I had a: # zfs list -tall NAME USED AVAIL REFER MOUNTPOINT . . . zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 117G 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style 1.44G - 1.44G -. . . . . . (copied/pasted from somewhat earlier) and then attempted: # zfs rename zroot/DESTDIRs/13_0R-CA72-instwrld-norm zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 cannot open 'zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style': snapshot delimiter '@' is not expected here Despite the "cannot open" message, the result looks like: # zfs list -tall NAME USED AVAIL REFER MOUNTPOINT . . . zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 1.44G 114G 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt-0 zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0@dirty-style 1.44G - 1.44G - . . . Still, it leaves me wondering if everything is okay given that internal attempt to use the old name with @dirty-style when it was apparently no longer available under that naming. For reference: # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files? [Ignore recent test: -dirty vs. checked-in usage difference]
[The first buidlworld is still in process. So while waiting . . .] On 2021-May-4, at 10:31, Mark Millard wrote: > I probably know why the huge count of differences this time > unlike the original report . . . > > Previously I built based on a checked-in branch as part of > my experimenting. This time it was in a -dirty form (not > checked in), again as part of my experimental exploration. > > WITH_REPRODUCIBLE_BUILD= makes a distinction between these > if I remember right: (partially?) disabling itself for > -dirty style. > > To reproduce the original style of test I need to create > a branch with my few patches checked in and do the > buildworlds from that branch. > > This will, of course, take a while. > > Sorry for the noise. > I've confirmed some of the details of the large number of files with difference while waiting for the 1st buildworld : The 4 bytes at the end of the .gnu_debuglink section that are ending up different are the checksum for the .debug file. The .debug files have differences such as: │ -<1a> DW_AT_comp_dir: (indirect string) /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/usr/13_0R-src/arm64.aarch64/lib/csu/aarch64 │ +<1a> DW_AT_comp_dir: (indirect string) /usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/lib/csu/aarch64 So I need to build, snapshot (in case need to reference), install, clean-out, build, install elsewhere, compare. (Or analogous that uses the same build base-path for both installs despite separate buildworld's.) This is separate from any potential -dirty vs. checked-in handling variation by WITH_REPRODUCIBLE_BUILD= . My process that produced the original armv7 report happened to do that before I accidentally discovered the presence of the few files with differences. My new experiments were different and I'd not though of needing to vary the procedure to get you the right evidence. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files? [aarch64 test did not reproduce the issue]
On 2021-May-4, at 13:38, Mark Millard wrote: > [The first buidlworld is still in process. So while waiting . . .] > > On 2021-May-4, at 10:31, Mark Millard wrote: > >> I probably know why the huge count of differences this time >> unlike the original report . . . >> >> Previously I built based on a checked-in branch as part of >> my experimenting. This time it was in a -dirty form (not >> checked in), again as part of my experimental exploration. >> >> WITH_REPRODUCIBLE_BUILD= makes a distinction between these >> if I remember right: (partially?) disabling itself for >> -dirty style. >> >> To reproduce the original style of test I need to create >> a branch with my few patches checked in and do the >> buildworlds from that branch. >> >> This will, of course, take a while. >> >> Sorry for the noise. >> > > I've confirmed some of the details of the large number of > files with difference while waiting for the 1st buildworld : > > The 4 bytes at the end of the .gnu_debuglink section > that are ending up different are the checksum for the > .debug file. The .debug files have differences such as: > > │ -<1a> DW_AT_comp_dir: (indirect string) > /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/usr/13_0R-src/arm64.aarch64/lib/csu/aarch64 > │ +<1a> DW_AT_comp_dir: (indirect string) > /usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/lib/csu/aarch64 > > So I need to build, snapshot (in case need > to reference), install, clean-out, build, > install elsewhere, compare. (Or analogous > that uses the same build base-path for both > installs despite separate buildworld's.) > This is separate from any potential -dirty > vs. checked-in handling variation by > WITH_REPRODUCIBLE_BUILD= . > > My process that produced the original armv7 > report happened to do that before I accidentally > discovered the presence of the few files with > differences. My new experiments were different > and I'd not though of needing to vary the > procedure to get you the right evidence. > The two aarch64 test installs did not show any differences in a "diff -rq" . Ignoring *.meta files generated during the builds, the build directory tree snapshots showed just the differences: # diff -rq /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr | grep -v '\.meta' | more Files /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c and /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c differ Files /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk and /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk differ # diff -u /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c --- /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c 2021-05-04 13:45:14.463351000 -0700 +++ /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c 2021-05-04 19:04:32.338203000 -0700 @@ -4,7 +4,7 @@ ** Words from CORE set written in FICL ** Author: John Sadler (john_sad...@alum.mit.edu) ** Created: 27 December 1997 -** Last update: Tue May 4 13:45:14 PDT 2021 +** Last update: Tue May 4 19:04:32 PDT 2021 ***/ /* ** DO NOT EDIT THIS FILE -- it is generated by softwords/softcore.awk # diff -u /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk --- /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk 2021-05-04 10:55:26.030179000 -0700 +++ /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk 2021-05-04 16:14:24.513346000 -0700 @@ -1,4 +1,4 @@ -.info Using cached toolchain metadata from build at CA72_4c8G_ZFS on Tue May 4 10:55:26 PDT 2021 +.info Using cached toolchain metadata from build at CA72_4c8G_ZFS on Tue May 4 16:14:24 PDT 2021 _LOADED_TOOLCHAIN_METADATA=t COMPILER_VERSION=110001 X_COMPILER_VERSION=110001 I may run a 'target cortex-a7 (so: armv7) from aarch64' test next. That was the context for the original discovery and report. === Mark Millard marklmi at yahoo.com (
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?
On 2021-May-3, at 21:27, Mark Millard wrote:
> On 2021-May-3, at 19:26, Mark Millard wrote:
>
>> On 2021-May-3, at 10:51, Mark Millard wrote:
>>
>>> On 2021-May-3, at 07:47, Ed Maste wrote:
>>>
On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
wrote:
>
> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and
> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and
> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping6 differ
> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/bin/ntpq and
> /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/bin/ntpq differ...
This is unexpected. Unfortunately I haven't looked at reproducibility
in a while, and my work was all on x86. This could be a regression or
a longstanding issue with arm64.
If you install the diffoscope package (py37-diffoscope) and run it on
the two directories / files it should give a more convenient view of
the differences. (Or, if you can make a tarball of the differing files
I can take a look.)
>>>
>>> I no longer have the same content in those directory
>>> trees: newer rebuild and the same buildworld used to
>>> installworld to both places, instead of 2 different
>>> buildworld's. I'm also unsure how reproducible getting
>>> differences was.
>>>
>>> I can eventually do experiments to test multiple separate
>>> buildworld's and installworld's, but the machine is busy
>>> building ports and the llvm builds involved means it
>>> will be some time before I'd switch activities. And the
>>> buildworld's involve llvm builds as well and take notable
>>> time themselves. So my next comparison will not be any
>>> time soon.
>>>
>>> I'll let you know if I manage to generate another example,
>>> this time being sure to keep the data. If I try multiple
>>> times without finding any differences, I'll eventually
>>> decide "enough is enough" and let you know.
>>
>> I've still got a long ways to go to do the first
>> actual comparison of builds.
>>
>> But I'll note that I've built and stalled py37-diffoscope
>> (new to me). A basic quick test showed that it reports:
>>
>> W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh"
>> module is unavailable.
>>
>> As I'm not familiar with the tool, you might need to send
>> notes about how you want me to use the tool to get the
>> output that you would want. (And, so, I get to learn . . .)
>
> I've tried another experiment (* in the path matches "28" and "30"):
>
> # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
> $<3/>2021-05-03 21:08:48 W: diffoscope.main: Fuzzy-matching is currently
> disabled as the "tlsh" module is unavailable.
> $<3/>Traceback (most recent call last):
> File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745,
> in main
>sys.exit(run_diffoscope(parsed_args))
> File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677,
> in run_diffoscope
>difference = load_diff_from_path(path1)
> File
> "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", line
> 31, in load_diff_from_path
>return load_diff(codecs.getreader("utf-8")(fp), path)
> File
> "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", line
> 35, in load_diff
>return JSONReaderV1().load(fp, path)
> File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py",
> line 33, in load
>raw = json.load(fp)
> File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
>return loads(fp.read(),
> File "/usr/local/lib/python3.7/codecs.py", line 504, in read
>newchars, decodedbytes = self.decode(data, self.errors)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18:
> invalid start byte
>
> The two older snapshots of a Boot Environment have
> bin/sh files that compare equal. But every program I
> tried the above sort of thing against on got the same
> UnicodeDecodeError result from diffoscope, byte value
> and position matching.
>
> These snapshots have more than an installworld in them
> and so are messy to compare overall. But the
> installworld (and installkernel) content show similar
> differences to what I reported before as far as
> example files with differences go. But this is aarch64,
> not armv7.
>
> It will still be notable time before I have simple
> installworld tree's to compare.
While waiting for the 2nd buildworld to complete, I used
the 1st buildworld's materials to installworld twice (to
different, empty directory trees) and then did a diff.
The diff reported:
# diff -rq /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm2/ | more
diff: /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/usr/tests/local: No such file
or directory
diff:
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?
On Mon, 3 May 2021 at 22:26, Mark Millard wrote: > > But I'll note that I've built and stalled py37-diffoscope > (new to me). A basic quick test showed that it reports: > > W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh" module > is unavailable. I just looked up tlsh - its "A Locality Sensitive Hash"; I presume diffoscope uses it to infer file renames. I believe the warning emitted here should have no impact on the output we're looking for. As far as the utf-8 issues go, diffoscope requires a utf-8 locale and I suspect that is the issue. If you don't have LANG set already, try setting LANG=C.UTF-8 in your environment. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?
On Tue, 4 May 2021 at 11:52, Mark Millard wrote: > > > As far as the utf-8 issues go, diffoscope requires a utf-8 locale and > > I suspect that is the issue. If you don't have LANG set already, try > > setting LANG=C.UTF-8 in your environment. > > That is not the issue for the UnicodeDecodeError: > > # echo $LANG > C.UTF-8 > > # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh > [...] > $<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently > disabled as the "tlsh" module is unavailable. > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18: > invalid start byte Hmm, interesting - if you don't mind sharing I'd be interested in a copy of /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh, in order to track down what appears to be a diffoscope issue. To investigate the non-reproducibility though we can just manually run through the same sort of process that Diffoscope uses. I would suggest cmp -x to find the offsets of the difference(s), then use readelf -S to determine which section(s) have differences. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?
On 2021-May-4, at 08:51, Mark Millard wrote:
> On 2021-May-4, at 06:01, Ed Maste wrote:
>
>> On Mon, 3 May 2021 at 22:26, Mark Millard wrote:
>>>
>>> But I'll note that I've built and stalled py37-diffoscope
>>> (new to me). A basic quick test showed that it reports:
>>>
>>> W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh"
>>> module is unavailable.
>>
>> I just looked up tlsh - its "A Locality Sensitive Hash"; I presume
>> diffoscope uses it to infer file renames. I believe the warning
>> emitted here should have no impact on the output we're looking for.
>
> Okay.
>
>> As far as the utf-8 issues go, diffoscope requires a utf-8 locale and
>> I suspect that is the issue. If you don't have LANG set already, try
>> setting LANG=C.UTF-8 in your environment.
>
> That is not the issue for the UnicodeDecodeError:
>
> # echo $LANG
> C.UTF-8
>
> # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
> $<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently
> disabled as the "tlsh" module is unavailable.
> $<3/>Traceback (most recent call last):
> File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745,
> in main
>sys.exit(run_diffoscope(parsed_args))
> File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677,
> in run_diffoscope
>difference = load_diff_from_path(path1)
> File
> "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", line
> 31, in load_diff_from_path
>return load_diff(codecs.getreader("utf-8")(fp), path)
> File
> "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", line
> 35, in load_diff
>return JSONReaderV1().load(fp, path)
> File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py",
> line 33, in load
>raw = json.load(fp)
> File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
>return loads(fp.read(),
> File "/usr/local/lib/python3.7/codecs.py", line 504, in read
>newchars, decodedbytes = self.decode(data, self.errors)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18:
> invalid start byte
>
Well, the list of differing files is huge. But this seems to
be .gnu_debuglink content for the area it is in. I'll note
that I did installworld but not the likes of distrib-dirs
or distribution this time.
This test did buildworld to two distinct directories:
zroot/BUILDs/13_0R-CA72-nodbg-clang 5.13G 118G 5.13G
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang
zroot/BUILDs/13_0R-CA72-nodbg-clang-alt 4.28G 118G 4.28G
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt
and installworld to 2 distinct directories:
zroot/DESTDIRs/13_0R-CA72-instwrld-alt1.44G 118G 1.44G
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt
zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 118G 1.44G
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
Previously (armv7 target) I had built, installed, rebuilt
to same directory (after clean-out) and installed to an
alternate directory. That had gotten only a few files
different but I do not know (yet) if it was the procedural
difference that made the difference.
Prefix of the list of different files this time:
# diff -rq /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/ | more
Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/[ and
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/[ differ
Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat and
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat differ
Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chflags and
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chflags differ
Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chio and
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chio differ
. . .
Looking, aarch64 seems to typically get a back-to-back
sequence of 4 bytes different in native programs in my
builds:
# cmp -x /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat
3bd4 1d 65
3bd5 eb a3
3bd6 bb ca
3bd7 8e 1a
# ls -Tld /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat
-r-xr-xr-x 1 root wheel 18448 May 4 08:55:01 2021
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat
-r-xr-xr-x 1 root wheel 18448 May 3 23:16:36 2021
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat
Sections:
Idx Name Size VMA LMA File off Algn
. . .
25 .gnu_debuglink 0010 3bc8 2**0
CONTENTS, READONLY
3bd4-3bc8 == 0xC
# cmp -x /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chflags
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chflags
2208 88 a1
2209 e6 40
220a 60 94
220b bf ce
# ls -Tld /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chflags
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chflags
-r-xr-xr-x 1 root wheel
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?
[Just adding readelf -S info since it seems to show more.]
On 2021-May-4, at 10:01, Mark Millard wrote:
> On 2021-May-4, at 08:51, Mark Millard wrote:
>
>> On 2021-May-4, at 06:01, Ed Maste wrote:
>>
>>> On Mon, 3 May 2021 at 22:26, Mark Millard wrote:
But I'll note that I've built and stalled py37-diffoscope
(new to me). A basic quick test showed that it reports:
W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh"
module is unavailable.
>>>
>>> I just looked up tlsh - its "A Locality Sensitive Hash"; I presume
>>> diffoscope uses it to infer file renames. I believe the warning
>>> emitted here should have no impact on the output we're looking for.
>>
>> Okay.
>>
>>> As far as the utf-8 issues go, diffoscope requires a utf-8 locale and
>>> I suspect that is the issue. If you don't have LANG set already, try
>>> setting LANG=C.UTF-8 in your environment.
>>
>> That is not the issue for the UnicodeDecodeError:
>>
>> # echo $LANG
>> C.UTF-8
>>
>> # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
>> $<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently
>> disabled as the "tlsh" module is unavailable.
>> $<3/>Traceback (most recent call last):
>> File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745,
>> in main
>> sys.exit(run_diffoscope(parsed_args))
>> File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677,
>> in run_diffoscope
>> difference = load_diff_from_path(path1)
>> File
>> "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py",
>> line 31, in load_diff_from_path
>> return load_diff(codecs.getreader("utf-8")(fp), path)
>> File
>> "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py",
>> line 35, in load_diff
>> return JSONReaderV1().load(fp, path)
>> File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py",
>> line 33, in load
>> raw = json.load(fp)
>> File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
>> return loads(fp.read(),
>> File "/usr/local/lib/python3.7/codecs.py", line 504, in read
>> newchars, decodedbytes = self.decode(data, self.errors)
>> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18:
>> invalid start byte
>>
>
> Well, the list of differing files is huge. But this seems to
> be .gnu_debuglink content for the area it is in.
Specifically: the last 4 bytes of the .gnu_debuglink section.
> I'll note
> that I did installworld but not the likes of distrib-dirs
> or distribution this time.
>
> This test did buildworld to two distinct directories:
>
> zroot/BUILDs/13_0R-CA72-nodbg-clang 5.13G 118G 5.13G
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang
> zroot/BUILDs/13_0R-CA72-nodbg-clang-alt 4.28G 118G 4.28G
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt
>
> and installworld to 2 distinct directories:
>
> zroot/DESTDIRs/13_0R-CA72-instwrld-alt1.44G 118G 1.44G
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt
> zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 118G 1.44G
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
>
> Previously (armv7 target) I had built, installed, rebuilt
> to same directory (after clean-out) and installed to an
> alternate directory. That had gotten only a few files
> different but I do not know (yet) if it was the procedural
> difference that made the difference.
>
> Prefix of the list of different files this time:
>
> # diff -rq /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/ | more
> Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/[ and
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/[ differ
> Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat and
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat differ
> Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chflags and
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chflags differ
> Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chio and
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chio differ
> . . .
>
> Looking, aarch64 seems to typically get a back-to-back
> sequence of 4 bytes different in native programs in my
> builds:
>
> # cmp -x /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat
> 3bd4 1d 65
> 3bd5 eb a3
> 3bd6 bb ca
> 3bd7 8e 1a
>
> # ls -Tld /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat
> -r-xr-xr-x 1 root wheel 18448 May 4 08:55:01 2021
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat
> -r-xr-xr-x 1 root wheel 18448 May 3 23:16:36 2021
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> . . .
> 25 .gnu_debuglink 0010 3bc8 2**0
> CONTENTS, READONLY
Section
Re: bhyve and multiple network devices
On Mon, May 03, 2021 at 10:46:34PM +0200, Juraj Lutter wrote: > Hi, > > my bhyve command line (on 13.0-RELEASE) is: > > /usr/sbin/bhyve -c 2 -m 4G -H -A -P -u -s 0:0,hostbridge -s 1:0,lpc -s > 2:0,virtio-net,tap100 -s 3:0,virtio-net,priv0 -s > 4:0,virtio-blk,/dev/zvol/zroot/data/minio/host0/root -l com1,/dev/nmdm100B mr > > the result is: > > device emulation initialization error: File exists > > It works when using original interface name (tap105 in this case). > > priv0 is renamed tap: > priv0: flags=8902 metric 0 mtu 1500 > options=8 > ether 58:9c:fc:10:2b:0b > groups: tap > media: Ethernet autoselect > status: no carrier > nd6 options=29 > > Am I doing something inadequate, is this an expected behavior or is this a > kind of a bug? Unfortunately, bhyve doesn't support renamed tap devices. You'll need to keep the original tapN name. What you might want to experiment with is setting a description for the tap device. For example: ifconfig tapN description "private vNIC" Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: bhyve and multiple network devices
> On 4 May 2021, at 15:23, Shawn Webb wrote: > > Unfortunately, bhyve doesn't support renamed tap devices. You'll need > to keep the original tapN name. > > What you might want to experiment with is setting a description for > the tap device. For example: > > ifconfig tapN description "private vNIC" > Fair enough. Anyway, I can specify the original name while also keeping the device in ifconfig’s output renamed. It works. I’ve been able to make a lab setup of 4x minio nodes, 1x frr router, all routed with BGP+ECMP. otis — Juraj Lutter o...@freebsd.org ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?
On 2021-May-4, at 06:01, Ed Maste wrote:
> On Mon, 3 May 2021 at 22:26, Mark Millard wrote:
>>
>> But I'll note that I've built and stalled py37-diffoscope
>> (new to me). A basic quick test showed that it reports:
>>
>> W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh"
>> module is unavailable.
>
> I just looked up tlsh - its "A Locality Sensitive Hash"; I presume
> diffoscope uses it to infer file renames. I believe the warning
> emitted here should have no impact on the output we're looking for.
Okay.
> As far as the utf-8 issues go, diffoscope requires a utf-8 locale and
> I suspect that is the issue. If you don't have LANG set already, try
> setting LANG=C.UTF-8 in your environment.
That is not the issue for the UnicodeDecodeError:
# echo $LANG
C.UTF-8
# diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
$<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently
disabled as the "tlsh" module is unavailable.
$<3/>Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745,
in main
sys.exit(run_diffoscope(parsed_args))
File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677,
in run_diffoscope
difference = load_diff_from_path(path1)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py",
line 31, in load_diff_from_path
return load_diff(codecs.getreader("utf-8")(fp), path)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py",
line 35, in load_diff
return JSONReaderV1().load(fp, path)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py",
line 33, in load
raw = json.load(fp)
File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
return loads(fp.read(),
File "/usr/local/lib/python3.7/codecs.py", line 504, in read
newchars, decodedbytes = self.decode(data, self.errors)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18:
invalid start byte
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files? [Ignore recent test: -dirty vs. checked-in usage difference]
I probably know why the huge count of differences this time unlike the original report . . . Previously I built based on a checked-in branch as part of my experimenting. This time it was in a -dirty form (not checked in), again as part of my experimental exploration. WITH_REPRODUCIBLE_BUILD= makes a distinction between these if I remember right: (partially?) disabling itself for -dirty style. To reproduce the original style of test I need to create a branch with my few patches checked in and do the buildworlds from that branch. This will, of course, take a while. Sorry for the noise. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
diffoscope's odd UnicodeDecodeError error message: reason found
I had reported in the reproducable build list messages:
> # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
> [...]
> $<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently
> disabled as the "tlsh" module is unavailable.
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18:
> invalid start byte
Well, it turns out that the file name pattern was
incorrect and only matched one file.
By contrast:
# diffoscope /.zfs/snapshot/2021-04-*/bin/sh
$<3/>2021-05-04 11:05:25 W: diffoscope.main: Fuzzy-matching is currently
disabled as the "tlsh" module is unavailable.
worked fine.
And making the "one file" status obvious:
# diffoscope c_tests/a.out
$<3/>2021-05-04 11:11:45 W: diffoscope.main: Fuzzy-matching is currently
disabled as the "tlsh" module is unavailable.
$<3/>Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745,
in main
sys.exit(run_diffoscope(parsed_args))
File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677,
in run_diffoscope
difference = load_diff_from_path(path1)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py",
line 31, in load_diff_from_path
return load_diff(codecs.getreader("utf-8")(fp), path)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py",
line 35, in load_diff
return JSONReaderV1().load(fp, path)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py",
line 33, in load
raw = json.load(fp)
File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
return loads(fp.read(),
File "/usr/local/lib/python3.7/codecs.py", line 504, in read
newchars, decodedbytes = self.decode(data, self.errors)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18:
invalid start byte
Not exactly an obvious error message for the issue.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
