On 2022-Oct-30, at 21:00, Mark Millard wrote:
> On 2022-Oct-30, at 19:47, Archimedes Gaviola
> wrote:
>
>> On Mon, Oct 31, 2022 at 1:29 AM Mark Millard wrote:
>> Archimedes Gaviola wrote on
>> Date: Sun, 30 Oct 2022 13:41:52 UTC :
>>
>>> I am b
On 2022-Nov-2, at 14:09, Archimedes Gaviola
wrote:
> On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola
> wrote:
>
> . . .
>
> . . .
>
>
> Hi Mark,
>
> Just an update, as kernel and world compilation is ongoing with my RPi3B
> system (with swap partition) is doing so far, so good. It alr
bob prohaska wrote on
Date: Sun, 06 Nov 2022 03:12:04 UTC :
> On Mon, Oct 24, 2022 at 08:32:17PM -0700, Mark Millard wrote:
> >
> > Your /etc/rc.d/ldconfig script seems to have not been updated
> > by use of etcupdate or mergemaster or other such. (How much
> > el
/libexec/hyperv/ is empty:
# ls -Tla /usr/libexec/hyperv/
total 9
drwxr-xr-x 2 root wheel 2 Apr 8 22:40:03 2021 .
drwxr-xr-x 10 root wheel 68 Nov 6 20:31:00 2022 ..
===
Mark Millard
marklmi at yahoo.com
share/mk/bsd.files.mk
/usr/main-src/share/mk/bsd.dirs.mk /usr/main-src/share/mk/bsd.incs.mk
/usr/main-src/share/mk/bsd.links.mk /usr/main-src/share/mk/bsd.dep.mk
/usr/main-src/share/mk/bsd.clang-analyze.mk /usr/main-src/share/mk/bsd.obj.mk
/usr/main-src/share/mk/bsd.subdir.mk /usr/main-src/share/mk/bsd.sys.mk
/usr/main-src/tools/build/mk/Makefile.boot'
.PATH='. /usr/main-src/usr.sbin/config'
make[2]: stopped in /usr/main-src
make[2]: stopped in /usr/main-src
make[2]: stopped in /usr/main-src
6.42 real26.37 user 5.47 sys
make[1]: stopped in /usr/main-src
make: stopped in /usr/main-src
===
Mark Millard
marklmi at yahoo.com
oom_attempts: -1
# sysctl -W vm.pfault_oom_wait
vm.pfault_oom_wait: 10
(So /etc/sysctl.conf or the like is an alternative:
Also writable.)
===
Mark Millard
marklmi at yahoo.com
means that it can't write to backing store dirty pages to give to
> another process...
>
> Typical reason is that the disk / flash is not responsive to writes for some
> reason. You'll need to find why... I'd look at trims.
>
> Or if you can't change the disk... you need to put less memory pressure
> on it..
===
Mark Millard
marklmi at yahoo.com
e the -T and
-W are not necessary on the command lines.
===
Mark Millard
marklmi at yahoo.com
ay with in my context. I also
avoid spinning rust. Thus I've only gotten "indefinite wait buffer"
or the like back before such was true, long ago.)
===
Mark Millard
marklmi at yahoo.com
e the loader can be
updated to track. Landing in the middle without noticing
and upgrading both the loader and the pool(s) could lead
to such problems: not yet the right loader version to
upgrade to.
===
Mark Millard
marklmi at yahoo.com
y of changing the feature flags, is it not?
zpool upgrade also does not consider the loader's status, so far
as I know. If FreeBSD's kernel/world supports something that the
loader would reject, teh result is still rejection for booting.
As I understand, some folks ran into this for
com.delphix:head_errlog until an updated loader was available
and then installed.
===
Mark Millard
marklmi at yahoo.com
gt; It's when you enable something on the zpool that you can run into trouble,
> but that's true independent of upgrade :)
>
> Warner
> Modulo bugs, try test systems first, etc. Of course.
>
===
Mark Millard
marklmi at yahoo.com
. . .
# sysctl -d kern.bootfile
kern.bootfile: Name of kernel file booted
# sysctl -W kern.bootfile
kern.bootfile: /boot/kernel.old/kernel
Looks wrong to me. (I've never explicitly assigned to kern.bootfile .)
===
Mark Millard
marklmi at yahoo.com
On Nov 12, 2022, at 20:42, Kyle Evans wrote:
> On Sat, Nov 12, 2022 at 10:16 PM Mark Millard wrote:
>>
>> The context:
>>
>> # ls -Tldt /boot/kern*/kernel
>> -r-xr-xr-x 1 root wheel 40003240 Nov 6 16:32:05 2022 /boot/kernel/kernel
>> -r-xr-xr-x
On Nov 20, 2022, at 19:48, Archimedes Gaviola
wrote:
> On Wed, Nov 9, 2022 at 10:15 AM Archimedes Gaviola
> wrote:
> On Wed, Nov 9, 2022 at 1:37 AM Mark Millard wrote:
> On Nov 8, 2022, at 04:15, Ronald Klop wrote:
>
> > Van: Warner Losh
> > Datum: dinsdag, 8
9c7ddf844589cb73c9b5
merge-base: CommitDate: 2022-11-06 22:06:40 +
n259064 (--first-parent --count for merge-base)
It was a copy I made of the directory tree I used for the
ThreadRipper 1950X's most recent update to its FreeBSD.
The macOS machine is a 2018 macMini (so: Intel).
===
Mark Millard
marklmi at yahoo.com
9cb73c9b5
merge-base: CommitDate: 2022-11-06 22:06:40 +
n259064 (--first-parent --count for merge-base)
===
Mark Millard
marklmi at yahoo.com
provides for
builds of main [so: 14] that have the new libc++.so.1 style
path. Nor did the main materials have logic to make it work
when built from an older context, such as a 13.1 context.
At least one of the two must happen to allow 13.1 to build
a 14. Having main [so: 14] deal with it, if possible, could
possibly also deal with 13.0 vintages/variants without
adjusting 13.0 materials.
===
Mark Millard
marklmi at yahoo.com
Jonathan Chen wrote on
Date: Fri, 23 Dec 2022 18:40:27 UTC :
> On 24/12/22 07:14, Mark Millard wrote:
> > Jonathan Chen wrote on
> > Date: Thu, 22 Dec 2022 19:21:37 UTC :
> >
> >> I recently updated my package builder machine to the
> >> stable/13-n2
# long output line split for reability
FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
main-n259842-c89209c674f2: Sat Dec 24 05:52:28 UTC 2022
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
arm64 aarch64 1400076 1400076
===
Mark Millard
marklmi at yahoo.com
an aarch64 equivalent of
lib/libc/x86/sys/Makefile.inc 's:
. . .
.if ${MACHINE_CPUARCH} == "amd64" && ${MK_HYPERV} != "no"
CFLAGS+= -DWANT_HYPERV
.endif
. . .
> Warner
>
> On Sun, Dec 25, 2022, 4:28 PM Mark Millard wrote:
> From the Dec 24 main [so: 14
ce might not be preserved.)
===
Mark Millard
marklmi at yahoo.com
On Dec 26, 2022, at 19:54, Mark Millard wrote:
> Should the following have been MFC'd? (I ran into this while
> looking to see why I see a boot message oddity on 13.* that
> I do not see on main [so: 14]. There was a time when main
> also produced the odd messages. But I
what to do when multiple
swap partitions are enabled if such a "ignore what
would be extra" mode was also enabled. As I'd not use
such, I've no specific recommendations to make that
would make any difference to my use.
===
Mark Millard
marklmi at yahoo.com
On Jan 21, 2023, at 23:17, Poul-Henning Kamp wrote:
>
> Mark Millard writes:
>
>> It would be nice if I could have just one swap partition
>> on a given boot media, one that is more than sufficient
>> in size for all but the biggest RAM system --but to
On Jan 22, 2023, at 00:21, Mark Millard wrote:
> On Jan 21, 2023, at 23:17, Poul-Henning Kamp wrote:
>
>> ----
>> Mark Millard writes:
>>
>>> It would be nice if I could have just one swap partition
>>> on a given boot media, one that is more t
On Jan 22, 2023, at 05:15, Mike Karels wrote:
> On 22 Jan 2023, at 2:42, Mark Millard wrote:
>
>> On Jan 22, 2023, at 00:21, Mark Millard wrote:
>>
>>> On Jan 21, 2023, at 23:17, Poul-Henning Kamp wrote:
>>>
>>>>
>>>>
On Jan 22, 2023, at 06:11, Ronald Klop wrote:
>
>
> Van: Mark Millard
> Datum: zondag, 22 januari 2023 05:41
> Aan: freebsd-current
> Onderwerp: An idea for swap partition size vs. swap space size in use handling
> I have boot media that are each set up to boot a vari
On Jan 22, 2023, at 09:46, Mark Millard wrote:
>
>> On Jan 22, 2023, at 05:15, Mike Karels wrote:
>>
>>> On 22 Jan 2023, at 2:42, Mark Millard wrote:
>>>
>>>> On Jan 22, 2023, at 00:21, Mark Millard wrote:
>>>>
tions of itself, but via devel/freebsd-gcc12 .
===
Mark Millard
marklmi at yahoo.com
/usr/obj/BUILDs/main-CA72-nodbg-gccxtc/usr/main-src/arm64.aarch64/stand/kboot/loader.kboot.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
. . .
(It will be some time before the debug build would get as far
as the above.)
===
Mark Millard
marklmi at yahoo.com
hat this is part of why devel/gcc*
ports exist. Otherwise: why have them?
> On Fri, Feb 10, 2023 at 8:42 PM Mark Millard wrote:
> self hosted aarch64 Non-debug buildworld Failure notice (from the .meta file):
>
> . . .
> /usr/local/libexec/gcc/aarch64-unknown-freebsd14.0/12.1.0/colle
ch64), I do not expect to be experimenting with armv7
and devel/freebsd-gcc12@armv7 for such just for my own
curiosity.
Note:
My builds were not a detailed replication of the FreeBSD
ci server's type of build context, even ignoring the
debug vs. non-debug coverage and the aarch64 testing.
The results are based on my normal, personal buildworld
buildkernel context.
===
Mark Millard
marklmi at yahoo.com
[This will be a question relative to the old material below.]
On Jan 27, 2021, at 17:33, Simon J. Gerraty wrote:
> Mark Millard via freebsd-current wrote:
>>>> Given an already built, installed and booted system version, I've
>>>> noted a big difference for MET
[Added a question about a possible typo in the old original message.]
On Feb 21, 2023, at 13:31, Mark Millard wrote:
> [This will be a question relative to the old material below.]
>
> On Jan 27, 2021, at 17:33, Simon J. Gerraty wrote:
>
>> Mark Millard via free
n being a symbolic link).
Note: WORLDTMP is not defined that early, thus the ${OBJTOP}/tmp
use.
-V.MAKE.META.IGNORE_PATHS is showing the paths I would
expect, matching the -dM lines.
So I'm still pondering what might be going on.
> .MAKE.META.IGNORE_FILTER
> ${.MAKE.META.IGNORE_PATTERNS:@m@${.p.:M$m}@}
===
Mark Millard
marklmi at yahoo.com
On Feb 22, 2023, at 17:18, Simon J. Gerraty wrote:
> Mark Millard wrote:
>
>> Thanks for the information.
>>
>>> strings `which bmake` | grep META.IGNORE
>>> .MAKE.META.IGNORE_PATHS
>>> .MAKE.META.IGNORE_PATTERNS
>>> ${.MAKE.META.IGNORE_PA
On Feb 22, 2023, at 19:47, Mark Millard wrote:
> On Feb 22, 2023, at 17:18, Simon J. Gerraty wrote:
>
>> Mark Millard wrote:
>>
>>> Thanks for the information.
>>>
>>>> strings `which bmake` | grep META.IGNORE
>>>
On Feb 22, 2023, at 22:43, Simon J. Gerraty wrote:
> Mark Millard wrote:
>> It appears that for symbolic links being the target, META_MODE does
>> not respect .MAKE.META.IGNORE_PATHS .
>
> The handling of links is rather complicated ;-)
> Among other things, the src ne
On Feb 22, 2023, at 22:23, Simon J. Gerraty wrote:
> Mark Millard wrote:
>>>
>>> Is there anything under ${OBJTOP}/tmp that you don't want to ignore?
>>
>> More than just _bootstrap_tools_links entries end up in
>> ${WORLDTMP}/legacy/bin/ (so in
ed int
Hash_Substring(Substring key)
{
unsigned int h;
const char *p;
h = 0;
for (p = key.start; p != key.end; p++)
h = 31 * h + (unsigned char)*p;
return h;
}
This h does include the '\0' byte so h==(unsigned int)(31*h_VALUE0).
I expect the mismatched hash values explain the repeated
"cached_realpath:" notices for the same path: inserted
but never found.
===
Mark Millard
marklmi at yahoo.com
On Feb 23, 2023, at 11:53, Mark Millard wrote:
> cached_realpath only reports its "cached_realpath:" notice
> (not the purging one) when it does not find the value via
> HashTable_FindValue and so does a HashTable_Set :
>
> const char *
> cached_realpath(const ch
On Feb 23, 2023, at 12:15, Simon J. Gerraty wrote:
> Mark Millard wrote:
>> The contribution to the list is currently generated via
>> use of:
>>
>> .if ${.MAKE.LEVEL} == 0
>
> Why is this guarded by .MAKE.LEVEL 0?
> .MAKE.META.IGNORE_* should be largely
[Note for "how many separate bmake instances are in that log?":
I do not know how to tell how many submakes are run total. It
was with -j32 on the threadripper 1950X, if that is was you
were after.]
On Feb 23, 2023, at 12:25, Simon J. Gerraty wrote:
> Mark Millard wrote:
>>&
"/usr/obj/BUILDs/main-CA7-nodbg-clang-alt"
\
make-main-CA7-nodbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX="/usr/obj/BUILDs/main-CA7-nodbg-clang"
\
make-main-CA72-dbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX="/usr/obj/BUILDs/main-CA72-dbg-clang"
\
make-main-CA72-dbg-gccxtc.aarch64-host.sh:MAKEOBJDIRPREFIX="/usr/obj/BUILDs/main-CA72-dbg-gccxtc"
\
make-main-CA72-nodbg-clang-alt.aarch64-host.sh:MAKEOBJDIRPREFIX="/usr/obj/BUILDs/main-CA72-nodbg-clang-alt"
\
make-main-CA72-nodbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX="/usr/obj/BUILDs/main-CA72-nodbg-clang"
\
make-main-CA72-nodbg-gccxtc.aarch64-host.sh:MAKEOBJDIRPREFIX="/usr/obj/BUILDs/main-CA72-nodbg-gccxtc"
\
===
Mark Millard
marklmi at yahoo.com
[I'm back at this again after some time on other subjects.]
On Feb 23, 2023, at 17:42, Simon J. Gerraty wrote:
> Mark Millard wrote:
>
>> Simplifying context . . .
>> . . .
>>> As I mentioned previously, there is no variablity of OBJTOP within the
>>&g
amd64/sys/GENERIC-NODBG/modules/amd64.amd64/tmp/legacy/usr
Still not right for "modules".
I'll note that outside modules, it is:
/amd64.amd64/tmp/legacy/usr
and still not right (MAKEOBJDIRPREFIX expanded
to empty).
I still do not know notation to make .MAKE.META.IGNORE_PATH
src/amd64.amd64/tmp/usr/lib/libctf.so'
is newer than the target...
1 file
'/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libcrypto.so'
is newer than the target...
1 file
'/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/lib/li
g the local time.)
So, as configured, /etc/localtime is used to
specify covert kernel UTC to local time as
needed: no addition non-zero offsets.
As I remember, things can be odd with file
systems from Windows variants and the time
stamps interpretation. Keeping such matching
vs. not can get into t
On Feb 25, 2023, at 20:01, Jamie Landeg-Jones wrote:
> Mark Millard wrote:
>
>> On Jan 21, 2023, at 23:17, Poul-Henning Kamp wrote:
>>>
>>> Last I looked at that code, that is precisely what happens
>>> if you add a too big swap-device ?
>>
>
On Feb 25, 2023, at 21:00, Mark Millard wrote:
> On Feb 25, 2023, at 20:01, Jamie Landeg-Jones wrote:
>
>> Mark Millard wrote:
>>
>>> On Jan 21, 2023, at 23:17, Poul-Henning Kamp wrote:
>>>>
>>>> Last I looked at that code, that is pr
er x86_64 vs. not or freebsdA.B
vs. freebsdX.Y differences count in the criteria and
either changing for FROM->TO ends up needing a
bootstrap/cross compiler.
>
> And of course if you are building natively, it is 'just' a regular
> bootstrap compiler.
Not for freebsdA.B -> freebsdX.Y transitions, based
on changes in default targets (and other details that
may sometimes implicitly go with that differing
default Target being used in the new compiler).
===
Mark Millard
marklmi at yahoo.com
ID or any part of it must not be used
directly. Instead the machine ID should be hashed with a
cryptographic, keyed hash function, using a fixed,
application-specific key. That way the ID will be properly
unique, and derived in a constant way from the machine ID but
there will be no way to retrieve the original machine ID from the
application-specific one.
END QUOTE
Is that at least recommended for handling FreeBSD's /etc/hostid
content?
Is FreeBSD going to document /etc/machine-id content properties
in a similar manor?
If FreeBSD ends up with a /etc/machine-id that does not have
the properties and recommended principles of use, it would
appear that the /etc/machine-id path would be highly misleading
and, so, inappropriate.
===
Mark Millard
marklmi at yahoo.com
On Mar 4, 2023, at 06:32, Tijl Coosemans wrote:
>
> On Fri, 3 Mar 2023 10:36:20 -0800 Mark Millard wrote:
>> What are the properties for the content of /etc/hostid
>> in FreeBSD? Where are they documented?
>>
>> /etc/machine-id has strong property guarnatee
>
nt in the criteria and
either changing for FROM->TO ends up needing a
bootstrap/cross compiler.
>
> And of course if you are building natively, it is 'just' a regular
> bootstrap compiler.
Not for freebsdA.B -> freebsdX.Y transitions, based
on changes in default targets (and other details that
may sometimes implicitly go with that differing
default Target being used in the new compiler).
===
Mark Millard
marklmi at yahoo.com
1 (use -v
> to see invocation) *** [gh-bc] Error code 1
seems to indicate that llvm15 was used to produce a file
at some point but later llvm14 was used to process the
file.
===
Mark Millard
marklmi at yahoo.com
've not been dealing with releng/13.2 but upgrades
from releng/13.1 and before likely have the same
questions for what the handling should be vs. what it
might actually be. Different ways of upgrading might
not be in agreement, for all I know.
===
Mark Millard
marklmi at yahoo.com
On Mar 16, 2023, at 15:55, Mark Millard wrote:
> # cat /etc/hostid /etc/machine-id /var/db/machine-id
> a4f7fbeb-f668-11de-b280-ebb65474e619
> a4f7fbebf66811deb280ebb65474e619
> 7227cd89727a462186e3ba680d0ee142
>
> (I'll not be keeping these values for the example syste
r possible prior
history sequences with /var/db/machine-id
and /etc/hostid ( but not /etc/machine-id ).
> Colin Percival
>
> On 3/16/23 15:55, Mark Millard wrote:
>> # cat /etc/hostid /etc/machine-id /var/db/machine-id
>> a4f7fbeb-f668-11de-b280-ebb65474e619
>> a4f7fbebf6
On Mar 16, 2023, at 17:27, Mark Millard wrote:
> On Mar 16, 2023, at 16:48, Colin Percival wrote:
>
>> I think the current situation should be sorted out aside from potential
>> issues
>> for people who upgraded to a "broken" version before updating to th
ing to the latest
>> code -- CCing bapt and tijl just in case since they're more familiar with
>> this
>> than I am.
>>
>> Colin Percival
>>
>> On 3/16/23 15:55, Mark Millard wrote:
>>> # cat /etc/hostid /etc/machine-id /var/d
blished via ntp, apparently. (I did not make such
adjustments to the snapshot before starting the
upgrade.)
I do not know if any of the "install: ///var/db/etcupdate/ . . . "
lines or the rmdir line are important.
It earlier indicated 5708 patches were fetched and that 377
files were a
On Mar 17, 2023, at 18:24, Mark Millard wrote:
> The 13.1-RELEASE (snapshot) to 13.2-RC3 freebsd-update's
> upgrade sequence did not go well relative to my being
> prompted to do the right thing to establish /etc/machine-id .
> After the last reboot (kernel upgrade, pres
On Mar 17, 2023, at 19:04, Mark Millard wrote:
> On Mar 17, 2023, at 18:24, Mark Millard wrote:
>
>> The 13.1-RELEASE (snapshot) to 13.2-RC3 freebsd-update's
>> upgrade sequence did not go well relative to my being
>> prompted to do the right thing to establish /
d 'fpr' in 'struct
fpreg'
memcpy(&fpreg.fpr[reg], val, sizeof(unw_fpreg_t));
~ ^
ptrace/_UPT_access_fpreg.c:123:30: error: no member named 'fpr' in 'struct
fpreg'
memcpy(val, &fpreg.fpr[reg], sizeof(unw_fpreg_t));
~ ^
2 errors generated.
*** [ptrace/_UPT_access_fpreg.lo] Error code 1
===
Mark Millard
marklmi at yahoo.com
confusion(s). But for now using a system clang 15+
toolchain to produce an older FreeBSD that is based on s system
clang 14 toolchain and an older target triple seems odd to me.
===
Mark Millard
marklmi at yahoo.com
Warner Losh wrote on
Date: Thu, 30 Mar 2023 22:15:38 UTC :
> On Thu, Mar 30, 2023, 3:45 PM void wrote:
>
> > On Thu, Mar 30, 2023 at 12:56:53PM -0700, Mark Millard wrote:
> >
> > >To my knowledge, FreeBSD has not actively supported newer
> > >FreeBSD bu
void wrote on
Date: Fri, 31 Mar 2023 13:18:34 UTC :
> On Thu, Mar 30, 2023 at 07:30:15PM -0700, Mark Millard wrote:
> >Warner Losh wrote on
> >Date: Thu, 30 Mar 2023 22:15:38 UTC :
> >
> >> On Thu, Mar 30, 2023, 3:45 PM void wrote:
> >>
> >>
at handle_el1h_sync+0x10
--- exception, esr 0xf0fa9198
(null)() at 0x400
KDB: enter: panic
[ thread pid 1446 tid 100101 ]
Stopped at kdb_enter+0x44: undefined f905c27f
db>
===
Mark Millard
marklmi at yahoo.com
port :
https://artifact.ci.freebsd.org/snapshot/main/b98fbf3781df16f7797b2bbeabf205dc7d4985ae/arm64/aarch64/kernel.txz
See also:
https://lists.freebsd.org/archives/freebsd-current/2023-April/003417.html
===
Mark Millard
marklmi at yahoo.com
ore
time to do the build, install, and test. (I'm keeping
my normal environments completely before the mess.)
FYI:
I have used the artifact build just after your pair of zfs
related updates to confirm the VFP problem is still in
place as of that point:
https://artifact.ci.freebsd.org/snapshot/main/5e2e3615d91f9c0c688987915ff5c8de23c22bde/arm64/aarch64/kernel.txz
(No artifact build was exactly at either of your commits.)
===
Mark Millard
marklmi at yahoo.com
On Apr 7, 2023, at 16:29, Kyle Evans wrote:
> On Fri, Apr 7, 2023 at 4:54 PM Mateusz Guzik wrote:
>>
>> On 4/7/23, Mark Millard wrote:
>>> On Apr 7, 2023, at 14:26, Mateusz Guzik wrote:
>>>
>>>> On 4/7/23, Mateusz Guzik wrote:
>>>>
ONLINE 0 0 0
errors: No known data errors
# zpool scrub zroot
# zpool status
pool: zroot
state: ONLINE
scan: scrub repaired 0B in 00:16:25 with 0 errors on Wed Apr 12 22:15:39 2023
config:
NAMESTATE READ WRITE CKSUM
zroot ONLINE 0 0 0
da0p8 ONLINE 0 0 0
errors: No known data errors
===
Mark Millard
marklmi at yahoo.com
[This just puts my prior reply's material into Cy's
adjusted resend of the original. The To/Cc should
be coomplete this time.]
On Apr 12, 2023, at 22:52, Cy Schubert wrote:
> In message , Mark Millard
> write
> s:
>> From: Charlie Li wrote on
>> Date
On Apr 12, 2023, at 23:52, Alexander Leidinger wrote:
> Quoting Mark Millard (from Wed, 12 Apr 2023 22:28:13
> -0700):
>
>> A fair number of errors are of the form: the build
>> installing a previously built package for use in the
>> builder but later the bui
s/pull/14739/files";
Cy reported the same in:
https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014519.html
"The EXDEV patch is applied. Block_cloning is disabled."
===
Mark Millard
marklmi at yahoo.com
//github.com/openzfs/zfs/pull/14739/files
The files were missing from packages installed to be used
during a port's build. No other types of examples of missing
files happened. (But only 11 ports failed.)
===
Mark Millard
marklmi at yahoo.com
On Apr 13, 2023, at 21:44, Charlie Li wrote:
> Mark Millard wrote:
>> FYI: in my original report for a context that has never had
>> block_cloning enabled, I reported BOTH missing files and
>> file content corruption in the poudriere-devel bulk build
>> testi
https://lists.freebsd.org/archives/freebsd-current/2023-April/003460.html
> DATA feature@block_cloning disabled local
You will still get corruptions but they will not be as
fundamental to problems restoring the pool to a good state.
[There is work in progress to try to have block_cloning
being enabled recoverable but effectively disabled other
than cleaning itself up. But this will not fix the other
cause(s) of corruption, which are still being worked on
as well.]
===
Mark Millard
marklmi at yahoo.com
On Apr 15, 2023, at 07:36, Cy Schubert wrote:
> In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>,
> FreeBSD Us
> er writes:
>> Am Thu, 13 Apr 2023 22:18:04 -0700
>> Mark Millard schrieb:
>>
>>> On Apr 13, 2023, at 21:44, Charl
On Apr 15, 2023, at 11:07, Cy Schubert wrote:
> In message <5a47f62d-0e78-4c3e-84c0-45eeb03c7...@yahoo.com>, Mark Millard
> write
> s:
>> On Apr 15, 2023, at 07:36, Cy Schubert =
>> wrote:
>>
>>> In message <20230415115452.08911...@thor.inter
gt; er writes:
>>>> Am Thu, 13 Apr 2023 22:18:04 -0700
>>>> Mark Millard schrieb:
>>>>
>>>>> On Apr 13, 2023, at 21:44, Charlie Li wrote:
>>>>>
>>>>>> Mark Millard wrote:
>>>>>>> FYI: in my ori
On Apr 15, 2023, at 15:33, Mark Millard wrote:
> On Apr 15, 2023, at 13:30, Mateusz Guzik wrote:
>
>> On 4/15/23, FreeBSD User wrote:
>>> Am Sat, 15 Apr 2023 07:36:25 -0700
>>> Cy Schubert schrieb:
>>>
>>>> In message <20230415115452.089
On Apr 15, 2023, at 15:49, Mark Millard wrote:
> . . .
>>
>>
>> (Mostly written as I progressed but some material later
>> inserted into/around previously written material.)
>>
>> Summary:
>>
>> As stands, it looks like reverting the d
sting? Vs.: Should I keep
using the content of that change?
(The question is prompted by the 2 recent commits
that I will update my test environment to be using,
in part by fetching and updating to a new head,
avoiding the "no dnode_next_offset change" status
that my existing test has.)
=
On Apr 15, 2023, at 17:27, Mark Millard wrote:
> On Apr 15, 2023, at 15:49, Mark Millard wrote:
>
>> . . .
>>>
>>>
>>> (Mostly written as I progressed but some material later
>>> inserted into/around previously written material.)
>>>
On Apr 15, 2023, at 21:31, Mark Millard wrote:
> On Apr 15, 2023, at 17:27, Mark Millard wrote:
>
>> On Apr 15, 2023, at 15:49, Mark Millard wrote:
>>
>>> . . .
>>>>
>>>>
>>>> (Mostly written as I progressed but some mater
On Apr 15, 2023, at 19:13, Mark Millard wrote:
> A general question is all for this message.
>
> So far no commit to FeeeBSD's main seems to be
> analogous to the content of:
>
> https://github.com/openzfs/zfs/pull/14739/files
>
> After my existing poudriere b
On Apr 16, 2023, at 01:34, Mark Millard wrote:
> On Apr 15, 2023, at 19:13, Mark Millard wrote:
>
>> A general question is all for this message.
>>
>> So far no commit to FeeeBSD's main seems to be
>> analogous to the content of:
>>
>>
On Apr 16, 2023, at 10:40, Mark Millard wrote:
> On Apr 16, 2023, at 01:34, Mark Millard wrote:
>
>> On Apr 15, 2023, at 19:13, Mark Millard wrote:
>>
>>> A general question is all for this message.
>>>
>>> So far no commit to FeeeBSD'
iled with error 6; retrying for 3 more seconds
Mounting from zfs:zroot failed with error 6.
Loader variables:
vfs.root.mountfrom=zfs:zroot
Manual root filesystem specification:
: [options]
Mount using filesystem
and with the specified (optional) option list.
eg. ufs:/dev/da0s1a
zfs:zroot/ROOT/default
cd9660:/dev/cd0 ro
(which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
? List valid disk boot devices
. Yield 1 second (for background tasks)
Abort manual input
mountroot>
This machine is part of the FreeBSD cluster for building PowerPC packages,
so we can build kernels to test anytime necessary.
END QUOTE
===
Mark Millard
marklmi at yahoo.com
o how to get there. )
Note: One could imagine a openzfs-2.1.10-freebsd
in releng/14.0 that did not list block_cloning, even
if there was (only) an odd way to get block_cloning
enabled for testing purposes.
===
Mark Millard
marklmi at yahoo.com
>
> /tmp/filelist.txt
> 9) Inspect /tmp/filelist.txt and save any important items. If the
> important files are not corrupted you can do:
> cp important_file new; mv new important_file
> NOTA BENE: "touch important_file" would not work, you do need to
> re-create the file.
> 10) Delete the remaining files/dirs in /tmp/filelist.txt. If you did 5)
> you will remove /boot/kernel.old files, but not /boot/kernel files.
> 11) Restore your compression and sync properties where appropiate.
>
===
Mark Millard
marklmi at yahoo.com
00b, r11=dd25c3e0
r12=, ssp=dd25c3c4, slr=0001, pc =c0610308
panic: Fatal abort
. . . (repeats over and over) . . .
===
Mark Millard
marklmi at yahoo.com
gt;
> On Tue, Apr 18, 2023, 4:45 PM Mark Millard wrote:
> https://github.com/openzfs/zfs/commit/d0cbd9feaf5b82130f2e679256c71e0c7413aae9
>
> does not seem to cover armv7, just aarch64. (FreeBSD disabled
> floating point for both armv7 and aarch64 but that is a
> different change
On Apr 18, 2023, at 15:02, José Pérez wrote:
> El 2023-04-18 21:37, Mark Millard escribió:
>>> In this case it does because the value is "active". If it's "enabled"
>>> you do not need to do anything.
>> Well, if block_cloning is disabled it wo
ge Mateusz Guzik
068913e4ba3d zfs: Add vfs.zfs.bclone_enabled sysctl. Pawel Jakub Dawidek
[TEMPORARY]
Warner's stand (loader) work caused by the import might be
associated with more openzfs changes at some point, allowing
for easily/directly avoiding use of "extra register sets" in
t
On Apr 18, 2023, at 15:44, Mark Millard wrote:
> https://github.com/openzfs/zfs/commit/d0cbd9feaf5b82130f2e679256c71e0c7413aae9
>
> does not seem to cover armv7, just aarch64. (FreeBSD disabled
> floating point for both armv7 and aarch64 but that is a
> different change than abov
ss expressions, like "[=a=]", where the string
between "[=" and "=]" is any collating element from its equivalence class, as
defined for the current locale. For exam-
ple, "[[=a=]]" might be equivalent to "[aáàäâ]", that is, to
"[a[.a-acute.][.a-grave.][.a-umlaut.][.a-circumflex.]]".
END QUOTE
# file /usr/bin/sh
/usr/bin/sh: symbolic link to bash
Seems like: pick your shell (as shown by echo $SHELL) and
that picks the pattern match rules used. (May be controllable
in the specific shell.)
===
Mark Millard
marklmi at yahoo.com
Yuri wrote on
Date: Fri, 21 Apr 2023 18:18:21 UTC :
> Yuri wrote:
> > Mark Millard wrote:
> >> Dimitry Andric wrote on
> >> Date: Fri, 21 Apr 2023 10:38:05 UTC :
> >>
> >>> On 21 Apr 2023, at 12:01, Ronald Klop wrote:
> >>>> Van
401 - 500 of 1389 matches
Mail list logo
