On 2021-Dec-31, at 18:18, Mark Millard wrote:
> On 2021-Dec-31, at 17:46, Mark Millard wrote:
>
>> On 2021-Dec-31, at 15:04, John Baldwin wrote:
>>
>>> On 12/31/21 2:59 PM, Mark Millard wrote:
On 2021-Dec-31, at 14:28, Mark Millard wrote:
> On 2021-Dec-30, at 14:04, John Baldwin
On 2021-Dec-31, at 17:46, Mark Millard wrote:
> On 2021-Dec-31, at 15:04, John Baldwin wrote:
>
>> On 12/31/21 2:59 PM, Mark Millard wrote:
>>> On 2021-Dec-31, at 14:28, Mark Millard wrote:
On 2021-Dec-30, at 14:04, John Baldwin wrote:
> On 12/30/21 1:09 PM, Mark Millard
On 2021-Dec-31, at 15:04, John Baldwin wrote:
> On 12/31/21 2:59 PM, Mark Millard wrote:
>> On 2021-Dec-31, at 14:28, Mark Millard wrote:
>>> On 2021-Dec-30, at 14:04, John Baldwin wrote:
>>>
On 12/30/21 1:09 PM, Mark Millard wrote:
> On 2021-Dec-30, at 13:05, Mark Millard wrote:
On 2021-Dec-31, at 14:28, Mark Millard wrote:
> On 2021-Dec-30, at 14:04, John Baldwin wrote:
>
>> On 12/30/21 1:09 PM, Mark Millard wrote:
>>> On 2021-Dec-30, at 13:05, Mark Millard wrote:
This asks a question in a different direction that my prior
reports about my builds vs. Cy's
On 2021-Dec-30, at 14:04, John Baldwin wrote:
> On 12/30/21 1:09 PM, Mark Millard wrote:
>> On 2021-Dec-30, at 13:05, Mark Millard wrote:
>>> This asks a question in a different direction that my prior
>>> reports about my builds vs. Cy's reported build.
>>>
>>> Background:
>>>
>>>
On 2021-Dec-30, at 19:15, Mark Millard wrote:
>
>> On 2021-Dec-30, at 15:14, Cy Schubert wrote:
>>
>> In message <3140c5f6-495f-441c-aa6b-542f3bc53...@yahoo.com>, Mark Millard
>> write
>> s:
>>> On 2021-Dec-30, at 11:52, Mark Millard wrote:
>> . . .
>> It was a NO_CLEAN build. A CLEAN build
On 2021-Dec-30, at 13:27, Mark Millard wrote:
>> Dear all,
>>
>> on a system updated yesterday I get
>>
>> tuexen_at_head:~/freebsd-src % git branch
>> * main
>> tuexen_at_head:~/freebsd-src % git pull
>> Already up to date.
>> tuexen_at_head:~/freebsd-src % uname -a
>> FreeBSD head
> On 2021-Dec-30, at 15:14, Cy Schubert wrote:
>
> In message <3140c5f6-495f-441c-aa6b-542f3bc53...@yahoo.com>, Mark Millard
> write
> s:
>> On 2021-Dec-30, at 11:52, Mark Millard wrote:
>>
This commit results in a different error.
ld: error:
> Dear all,
>
> on a system updated yesterday I get
>
> tuexen_at_head:~/freebsd-src % git branch
> * main
> tuexen_at_head:~/freebsd-src % git pull
> Already up to date.
> tuexen_at_head:~/freebsd-src % uname -a
> FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n252035-63f7f3921bd:
>
On 2021-Dec-30, at 13:05, Mark Millard wrote:
> This asks a question in a different direction that my prior
> reports about my builds vs. Cy's reported build.
>
> Background:
>
> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so:GROUP
> (
This asks a question in a different direction that my prior
reports about my builds vs. Cy's reported build.
Background:
/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so:GROUP
( /lib/libc++.so.1 /usr/lib/libcxxrt.so
and:
lrwxr-xr-x 1 root wheel23
On 2021-Dec-30, at 11:52, Mark Millard wrote:
>> This commit results in a different error.
>>
>> ld: error: /export/obj/opt/src/git-src/amd64.amd64/tmp/usr/lib/libc++.so:2:
>> cannot find /usr/lib/libc++.so.1 inside /export/obj/opt/src/git-src/amd64.am
>> d64/tmp
> GROUP (
> This commit results in a different error.
>
> ld: error: /export/obj/opt/src/git-src/amd64.amd64/tmp/usr/lib/libc++.so:2:
> cannot find /usr/lib/libc++.so.1 inside /export/obj/opt/src/git-src/amd64.am
> d64/tmp
> >>> GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so )
> >>> ^
> c++:
Building 33812d60b960 ( so after 6b1c5775d1c2 ) and installing
and rebooting did not put in place a /lib/libc++.so.1 but
delete-old-libs removed the /usr/lib/libc++.so.1 .
(Luckily my environment has sufficient recent near-redundancy
to recover easily by putting in place a /usr/lib/libc++.so.1 .)
In order to avoid the following for WITH_ASAN= WITH_UBSAN= (both used),
so also WITH_LLVM_BINUTILS= in use:
--- all_subdir_usr.bin/clang ---
--- llvm-as.full ---
ld: error: undefined symbol: compressBound
>>> referenced by Compression.cpp:51
>>>
On 2021-Dec-18, at 09:30, Ed Maste wrote:
> On Fri, 17 Dec 2021 at 11:09, Mark Millard wrote:
>>
>> I'm confused, beyond just LGPL claims in the (fairly
>> current) source code, but GPL more generally:
>>
>> # grep -rl "SPDX.*GPL" /usr/main-src/
>
> You need to exclude the ones with SPDX
From: Ed Maste wrote on
Date: Fri, 17 Dec 2021 08:42:49 -0500 :
> On Fri, 17 Dec 2021 at 05:12, Baptiste Daroussin wrote:
> >
> > > -gnu Various commands and libraries under the GNU Public License.
> > > - Please see gnu/COPYING* for more information.
> > > +gnu
Back when I upgraded the ThreadRipper 1950X amd64 system to (line split for
readability):
# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #25
main-n251456-22c4ab6cb015-dirty:
Tue Dec 7 19:38:53 PST 2021
From: FreeBSD User wrote on
Date: Wed, 15 Dec 2021 18:55:09 +0100 :
> . . .
>
> It is spooky, if not to say "buggy", if ZFS is capable of freezing the whole
> box even if
> the essential operating system stuff is isolated on a dedicated UFS
> filesystem.
I would guess that, for ZFS being in
tch: it was not obvious from my
background knowledge.
(From what you have reported, I'd not expect stable/* or
main to have such links.)
Thanks for the information. I know better what to do now.
>>> On 14.12.2021 19:36, Mark Millard via freebsd-current wrote:
>>>&g
that would have the final
version?
> On 14.12.2021 19:36, Mark Millard via freebsd-current wrote:
>> I just noticed that main reports that my pools were created
>> implicitly matching openzfs-2.1-freebsd (and without
>> an explicit compatibility assignment) but, under main, zpool
&
On 2021-Dec-14, at 16:36, Mark Millard wrote:
> I just noticed that main reports that my pools were created
> implicitly matching openzfs-2.1-freebsd (and without
> an explicit compatibility assignment) but, under main, zpool
> import and zpool status for those pools report a new, disabled
>
I just noticed that main reports that my pools were created
implicitly matching openzfs-2.1-freebsd (and without
an explicit compatibility assignment) but, under main, zpool
import and zpool status for those pools report a new, disabled
feature. Turns out the issue matches what the diff below
[ Note: w...@freebsd.org is only a guess, based on:
https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/001931.html
]
Attempting to update to:
main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021
resulted in boot failure (showing some boot -v output):
. . .
mmc0:
As of my update to (some line splitting applied):
# uname -apKU
FreeBSD CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #25
main-n251456-22c4ab6cb015-dirty:
Tue Dec 7 19:38:53 PST 2021
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
arm64
On 2021-Dec-6, at 14:19, Mark Millard wrote:
> This broke building lang/gcc11 so may be a exp run is appropriate:
>
> In file included from /usr/include/sys/cpuset.h:39,
> from /usr/include/sched.h:36,
> from /usr/include/pthread.h:48,
> from
>
This broke building lang/gcc11 so may be a exp run is appropriate:
In file included from /usr/include/sys/cpuset.h:39,
from /usr/include/sched.h:36,
from /usr/include/pthread.h:48,
from
/usr/obj/DESTDIRs/main-amd64-poud/ is a buildworld installation
for poudriere-devel use that I've been updating on occasion for
a while.
Despite:
>>> Checking for old files
>>> Checking for old libraries
>>> Checking for old directories
To remove old files and directories run 'make delete-old'.
On 2021-Nov-21, at 07:50, Mark Millard wrote:
> On 2021-Nov-20, at 11:54, Mark Millard wrote:
>
>> On 2021-Nov-19, at 22:20, Mark Millard wrote:
>>
>>> On 2021-Nov-18, at 12:15, Mark Millard wrote:
>>>
On 2021-Nov-17, at 11:17, Mark Millard wrote:
> On 2021-Nov-15, at
On 2021-Nov-20, at 11:54, Mark Millard wrote:
> On 2021-Nov-19, at 22:20, Mark Millard wrote:
>
>> On 2021-Nov-18, at 12:15, Mark Millard wrote:
>>
>>> On 2021-Nov-17, at 11:17, Mark Millard wrote:
>>>
On 2021-Nov-15, at 15:43, Mark Millard wrote:
> On 2021-Nov-15, at
On 2021-Nov-19, at 22:20, Mark Millard wrote:
> On 2021-Nov-18, at 12:15, Mark Millard wrote:
>
>> On 2021-Nov-17, at 11:17, Mark Millard wrote:
>>
>>> On 2021-Nov-15, at 15:43, Mark Millard wrote:
>>>
On 2021-Nov-15, at 13:13, Mark Millard wrote:
> On 2021-Nov-15, at
On 2021-Nov-18, at 12:15, Mark Millard wrote:
> On 2021-Nov-17, at 11:17, Mark Millard wrote:
>
>> On 2021-Nov-15, at 15:43, Mark Millard wrote:
>>
>>> On 2021-Nov-15, at 13:13, Mark Millard wrote:
>>>
On 2021-Nov-15, at 12:51, Mark Millard wrote:
> On 2021-Nov-15, at
On 2021-Nov-13, at 03:40, Mark Millard wrote:
> On 2021-Nov-13, at 03:20, Mark Millard wrote:
>
>
>> While attempting to see if I could repeat a bugzilla report in a
>> somewhat different context, I has the system hang up to the
>> point that ^C and ^Z did not work and ^T did not echo out
On 2021-Nov-18, at 15:54, Mark Millard wrote:
> The ThreadRipper 1950X FreeBSD system is reporting a message at
> 03:01:10 or so for the last 3 days. The .148 is a aarch64 system
> (HoneyComb). None of the other systems (aarch64 Small Board
> Computers and a armv7 SBC) are reporting such.
>
>
The ThreadRipper 1950X FreeBSD system is reporting a message at
03:01:10 or so for the last 3 days. The .148 is a aarch64 system
(HoneyComb). None of the other systems (aarch64 Small Board
Computers and a armv7 SBC) are reporting such.
Nov 16 03:01:10 amd64_ZFS kernel: newnfs: server
> On 2021-Nov-18, at 12:31, tue...@freebsd.org wrote:
>
>> On 17. Nov 2021, at 21:13, Mark Millard via freebsd-current
>> wrote:
>>
>> I've not noticed the ertt message before in:
>>
>> . . .
>> Waiting (max 60 seconds) for system thread `
On 2021-Nov-17, at 11:17, Mark Millard wrote:
> On 2021-Nov-15, at 15:43, Mark Millard wrote:
>
>> On 2021-Nov-15, at 13:13, Mark Millard wrote:
>>
>>> On 2021-Nov-15, at 12:51, Mark Millard wrote:
>>>
On 2021-Nov-15, at 11:31, Mark Millard wrote:
> I updated from (shown a
I've not noticed the ertt message before in:
. . .
Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop... done
All buffers synced.
Uptime: 1d9h57m18s
Khelp module "ertt" can't unload until its refcount drops from 1 to 0.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net
On 2021-Nov-15, at 15:43, Mark Millard wrote:
> On 2021-Nov-15, at 13:13, Mark Millard wrote:
>
>> On 2021-Nov-15, at 12:51, Mark Millard wrote:
>>
>>> On 2021-Nov-15, at 11:31, Mark Millard wrote:
>>>
I updated from (shown a system that I've not updated yet):
# uname -apKU
On 2021-Nov-15, at 13:13, Mark Millard wrote:
> On 2021-Nov-15, at 12:51, Mark Millard wrote:
>
>> On 2021-Nov-15, at 11:31, Mark Millard wrote:
>>
>>> I updated from (shown a system that I've not updated yet):
>>>
>>> # uname -apKU
>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD
On 2021-Nov-15, at 12:51, Mark Millard wrote:
> On 2021-Nov-15, at 11:31, Mark Millard wrote:
>
>> I updated from (shown a system that I've not updated yet):
>>
>> # uname -apKU
>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18
>> main-n250455-890cae197737-dirty: Thu Nov 4
On 2021-Nov-15, at 11:31, Mark Millard wrote:
> I updated from (shown a system that I've not updated yet):
>
> # uname -apKU
> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18
> main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021
>
I updated from (shown a system that I've not updated yet):
# uname -apKU
FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18
main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021
In my update sequence to install FreeBSD with the clang 13
related materials, the first -j32 installworld attempt got:
. . .
--- realinstall_subdir_lib/libc/tests/hash ---
install -o root -g wheel -m 444
/usr/main-src/contrib/netbsd-tests/lib/libc/hash/data/md5test-out
On 2021-Nov-13, at 03:20, Mark Millard wrote:
> While attempting to see if I could repeat a bugzilla report in a
> somewhat different context, I has the system hang up to the
> point that ^C and ^Z did not work and ^T did not echo out what
> would be expected for poudriere (or even the
While attempting to see if I could repeat a bugzilla report in a
somewhat different context, I has the system hang up to the
point that ^C and ^Z did not work and ^T did not echo out what
would be expected for poudriere (or even the kernel backtrace).
I was able to escape to ddb.
The context
On 2021-Oct-27, at 15:21, Mark Millard wrote:
> Unfortunately(?) this update added the .so.10 to mk/OptionalObsoleteFiles.inc
> :
>
> diff --git a/tools/build/mk/OptionalObsoleteFiles.inc
> b/tools/build/mk/OptionalObsoleteFiles.inc
> index a8b0329104c4..91822aac492a 100644
> ---
Unfortunately(?) this update added the .so.10 to mk/OptionalObsoleteFiles.inc :
diff --git a/tools/build/mk/OptionalObsoleteFiles.inc
b/tools/build/mk/OptionalObsoleteFiles.inc
index a8b0329104c4..91822aac492a 100644
--- a/tools/build/mk/OptionalObsoleteFiles.inc
+++
main [soi: 14] commit a96ef450 (2021-02-26 09:16:49 +)
changed DIALOG_STATE, DIALOG_VARS, and DIALOG_COLORS .
These are publicly exposed in (ones that I noticed):
/usr/include/dialog.h:extern DIALOG_STATE dialog_state;
/usr/include/dialog.h:extern DIALOG_VARS dialog_vars;
On 2021-Oct-21, at 16:24, Mark Millard wrote:
> On 2021-Oct-21, at 11:53, Mark Millard wrote:
>
>> On 2021-Oct-21, at 08:27, Tomoaki AOKI wrote:
>>
>>> On Thu, 21 Oct 2021 07:40:36 -0700
>>> Mark Millard via freebsd-current wrote:
>>>
&g
On 2021-Oct-21, at 11:53, Mark Millard wrote:
> On 2021-Oct-21, at 08:27, Tomoaki AOKI wrote:
>
>> On Thu, 21 Oct 2021 07:40:36 -0700
>> Mark Millard via freebsd-current wrote:
>>
>>>
>>>
>>> On 2021-Oct-21, at 06:14, Gary Jennejohn
On 2021-Oct-21, at 08:27, Tomoaki AOKI wrote:
> On Thu, 21 Oct 2021 07:40:36 -0700
> Mark Millard via freebsd-current wrote:
>
>>
>>
>> On 2021-Oct-21, at 06:14, Gary Jennejohn wrote:
>>
>>> On Thu, 21 Oct 2021 01:34:47 -0700
>>> Mark
On 2021-Oct-21, at 06:14, Gary Jennejohn wrote:
> On Thu, 21 Oct 2021 01:34:47 -0700
> Mark Millard via freebsd-current wrote:
>
>> I get the following crash (amd64 example shown), as reported
>> via gdb afterwards. (devel/llvm13 is just an example context.)
>>
I get the following crash (amd64 example shown), as reported
via gdb afterwards. (devel/llvm13 is just an example context.)
gdb `which dialog4ports` devel/llvm13/dialog4ports.core
. . .
Core was generated by `/usr/local/bin/dialog4ports'.
Program terminated with signal SIGSEGV, Segmentation
On 2021-Sep-25, at 23:25, Mark Millard wrote:
> I get odd time reports from poudriere on an armv7 under main [so: 14]:
>
>
>
> # poudriere bulk -jmain-CA7 lang/rust
> [00:00:00] Creating the reference jail... done
> . . .
> [00:00:00] Balancing pool
> [main-CA7-default] [2021-09-25_23h11m13s]
On 2021-Sep-16, at 16:27, Freddie Cash wrote:
>
> [message chopped and butchered, don't follow the quotes, it's just to show
> some bits together from different messages]
>
> On Thu, Sep 16, 2021 at 3:54 PM Mark Millard via freebsd-current
> wrote:
> > > F
On 2021-Sep-16, at 15:16, Alan Somers wrote:
> On Thu, Sep 16, 2021 at 4:02 PM Mark Millard wrote:
>
>
> On 2021-Sep-16, at 13:39, Alan Somers wrote:
>
> > On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current
> > wrote:
> > What do I go
.@via.net
> 650-207-0372 cell
> 650-213-1302 office
> 650-969-2124 fax
>
>
>
>> On Sep 16, 2021, at 1:01 PM, Mark Millard via freebsd-current
>> wrote:
>>
>> What do I go about:
>>
>> QUOTE
>> # zpool import
>> pool: zopt0
On 2021-Sep-16, at 13:39, Alan Somers wrote:
> On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current
> wrote:
> What do I go about:
>
> QUOTE
> # zpool import
>pool: zopt0
> id: 18166787938870325966
> state: FAULTED
> status: One or m
On 2021-Sep-16, at 13:01, Mark Millard wrote:
> What do I go about:
>
> QUOTE
> # zpool import
> pool: zopt0
> id: 18166787938870325966
> state: FAULTED
> status: One or more devices contains corrupted data.
> action: The pool cannot be imported due to damaged devices or data.
> see:
What do I go about:
QUOTE
# zpool import
pool: zopt0
id: 18166787938870325966
state: FAULTED
status: One or more devices contains corrupted data.
action: The pool cannot be imported due to damaged devices or data.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E
config:
> From: David Chisnall
> Date: Tue, 7 Sep 2021 14:51:21 +0100
> On 06/09/2021 20:34, Wolfram Schneider wrote:
> > With the option WITHOUT_TOOLCHAIN=yes the world build time is 2.5
> > times faster (real or user+sys), down from 48 min to 19.5 min real
> > time.
>
> Note that building LLVM with
On 2021-Jul-5, at 13:29, Fernando Apesteguía wrote:
> On Mon, Jul 5, 2021 at 8:48 AM Fernando Apesteguía
> wrote:
>>
>>
>>
>> El lun., 5 jul. 2021 4:59, Mark Millard escribió:
>>>
>>> The following commit seems to have proken installation
>>> by being incomplete:
>>>
>>> . . .
>>>
On 2021-Jul-4, at 19:59, Mark Millard wrote:
> The following commit seems to have proken installation
> by being incomplete:
>
> . . .
> committer Fernando Apesteguía 2021-06-30
> 07:57:51 +
> commit0a0f7486413c147d56808b38055c40c64cff61f5 (patch)
> . . .
> man: Build
The following commit seems to have proken installation
by being incomplete:
. . .
committer Fernando Apesteguía 2021-06-30
07:57:51 +
commit 0a0f7486413c147d56808b38055c40c64cff61f5 (patch)
. . .
man: Build manpages for all architectures
Building and installing
On 2021-Jul-2, at 08:38, Chuck Tuffli wrote:
> On Thu, Jun 24, 2021 at 11:50 PM Mark Millard via freebsd-current
> wrote:
>>
>> I've given up on figuring any useful out for this example.
>> I've also not had a repeat so far.
>>
>> I'm pro
I've given up on figuring any useful out for this example.
I've also not had a repeat so far.
I'm progressing to much more recent commits for the
environment to be based on as well.
The primary aarch64 system for my access is switching to
be a HoneyComb. The Optane was moved to the HoneyComb.
Dimitry Andric dim at FreeBSD.org wrote on
Mon Jun 14 19:17:40 UTC 2021 :
> The branch main has been updated by dim:
>
> URL:
> https://cgit.FreeBSD.org/src/commit/?id=790a6be5a1699291c6da87871426d0c56dedcc89
>
>
> commit 790a6be5a1699291c6da87871426d0c56dedcc89
> Author: Dimitry Andric
tech-lists wrote on
Date: Wed, 9 Jun 2021 02:13:07 +0100 :
> root_at_desktop:/usr/src# git remote prune freebsd
> fatal: 'freebsd' does not appear to be a git repository
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository
On 2021-Jun-6, at 13:25, Mark Millard wrote:
> Baptiste Daroussin wrote on
> Date: Sun, 6 Jun 2021 10:53:49 +0200 :
>
>> What has happended:
>> plan A: we migrated everything off mailman/pipermail seamlessly with
>> redirection
>> and so on. We patched the new archiver to produce the same
Baptiste Daroussin wrote on
Date: Sun, 6 Jun 2021 10:53:49 +0200 :
> What has happended:
> plan A: we migrated everything off mailman/pipermail seamlessly with
> redirection
> and so on. We patched the new archiver to produce the same file names has
> pipermail
>
> Plan A worked fine up to a
Cy Schubert wrote on:
Date: Tue, 01 Jun 2021 14:02:06 -0700 :
> Can you provide me with a backtrace, using the bt command, please.
That was in the original message from David W. A copy was
in the reply that you sent to the list as well:
> > (gdb) bt
> > #0 0x010fb34f in
On 2021-May-29, at 01:15, Mark Millard wrote:
> On 2021-May-23, at 00:46, Mark Millard via freebsd-current at freebsd.org> wrote:
>
>> On 2021-May-23, at 00:08, Mark Millard via freebsd-current > at freebsd.org> wrote:
>>
>>> On 2021-May-22, at 22:16,
On 2021-May-23, at 00:46, Mark Millard via freebsd-current wrote:
> On 2021-May-23, at 00:08, Mark Millard via freebsd-current at freebsd.org> wrote:
>
>> On 2021-May-22, at 22:16, Warner Losh wrote:
>>
>>> On Sat, May 22, 2021 at 10:44 PM Mark Milla
On 2021-May-23, at 00:08, Mark Millard via freebsd-current wrote:
> On 2021-May-22, at 22:16, Warner Losh wrote:
>
>> On Sat, May 22, 2021 at 10:44 PM Mark Millard via freebsd-arm
>> wrote:
>> # mount -onoatime 192.168.1.187:/usr/ports/ /mnt/
>> # diff -r /us
On 2021-May-22, at 22:16, Warner Losh wrote:
> On Sat, May 22, 2021 at 10:44 PM Mark Millard via freebsd-arm
> wrote:
> # mount -onoatime 192.168.1.187:/usr/ports/ /mnt/
> # diff -r /usr/ports/ /mnt/ | more
> nvme0: cpl does not map to outstanding cmd
> cdw0: sqhd:0020 sqid:0003
On 2021-May-14, at 13:48, Rodney W. Grimes
wrote:
>>
>> On 2021-May-14, at 05:52, Rodney W. Grimes > gndrsh.dnsmgr.net> wrote:
>>
Note: The context was using a non-debug main build
from mid-2021-Mar. (More details identified
later.)
The issue happend while
On 2021-May-14, at 05:52, Rodney W. Grimes
wrote:
>> Note: The context was using a non-debug main build
>> from mid-2021-Mar. (More details identified
>> later.)
>>
>> The issue happend while attempting a:
>>
>> # zfs send -R zpold@for-copy | zfs recv -Fdv zpnew
>>
>> where the
Note: The context was using a non-debug main build
from mid-2021-Mar. (More details identified
later.)
The issue happend while attempting a:
# zfs send -R zpold@for-copy | zfs recv -Fdv zpnew
where the drives involved in the command were:
zpold: a USB3 SSD, using /dev/da0p3
zpnew:
On 2021-May-5, at 17:01, Yuri Pankov wrote:
> Mark Millard via freebsd-current wrote:
>> Context:
>>
>> # gpart show -pl da0
>> => 40 468862048da0 GPT (224G)
>> 40 532480 da0p1 efiboot0 (260M)
>> 532520 2
Context:
# gpart show -pl da0
=> 40 468862048da0 GPT (224G)
40 532480 da0p1 efiboot0 (260M)
532520 2008 - free - (1.0M)
534528 25165824 da0p2 swp12a (12G)
25700352 25165824 da0p4 swp12b (12G)
50866176 417994752 da0p3 zfs0
On 2021-May-5, at 05:28, Mark Millard wrote:
> On 2021-May-5, at 02:47, Andriy Gapon wrote:
>
>> On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
>>> I had a:
>>> # zfs list -tall
>>> NAME USED AVAIL
On 2021-May-4, at 20:26, Mark Millard wrote:
> 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
>>>
On 2021-May-5, at 02:47, Andriy Gapon wrote:
> On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
>> I had a:
>> # zfs list -tall
>> NAME USED AVAIL REFER MOUNTPOINT
>> . . .
>> zroot/DESTDIRs/13_0R-CA72
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
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 -
tech-lists tech-lists at zyxst.net wrote on
Tue May 4 19:22:39 UTC 2021 :
> I've been trying to set up a boot-from-usb3 raspberry pi 4. I thought
> i'd be able to do this by booting into latest current snapshot image for
> arm64 rpi (written to microsd), and then running bsdinstall as root.
I've
[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.
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
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=
[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
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:
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
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:
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:
>>>>
>>
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
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/DESTDI
https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-May/003953.html
reports for main's commit just after c78ad207baed :
The branch main has been updated by andrew:
URL:
https://cgit.FreeBSD.org/src/commit/?id=f1957db43d28dbae1f82905304bab5be51942342
commit
[Just a resend: asking the question on the list
less than an hour before the UTC month change
might not be all that effective relative to
those that just web browse the list to read it.]
On 2021-Apr-30, at 16:21, Mark Millard wrote:
> Context . . .
>
> I've been experimenting with ZFS and
Context . . .
I've been experimenting with ZFS and bectl use recently.
It has been many years since I last used ZFS --and that
was only a short experiment that did not have to deal
with upgrades over time.
I now have:
# bectl list
BE Active Mountpoint Space Created
13S-CA72-nodbg
1 - 100 of 141 matches
Mail list logo
