Re: Has the update procedure changed?

[Mark Millard]

On Aug 7, 2023, at 19:50, Robert Huff  wrote:

> Mark Millard  writes:
> 
>>  The material in 26.6.5 does not repeat all that, it is
>>  more of a summary that is presented.
>> 
>>  There are also instructions in UPDATING (near the end)
>>  and yet other instructions in Makefile (leading
>>  comments).
>> 
>>  I've not done detailed comparisons of such in some
>>  time, but they well not be exact matches. As I remember,
>>  the UPDATING material was more explicit about various
>>  cases/contexts and what was appropriate for them.
>> 
>>  It can be appropriate to review them all.
> 
> 1) It would be really nice is someone would take a look and make
> sure these 100% non-contradictory.

To be effective, this may require the additional criteria of
being very explicit each time there is a partial listing
of commands that summarize only some of the overall steps, the
ones involved for the subject(s) in the local subsection but
not other steps. The handbook 26.6.5 command lists would be
an example.

> 2) If I can only use one of these, which one should I choose?

The only one that covers a variety of types of contexts
is the one in UPDATING, if I remember right. It is hard
to avoid referencing that, even if only to figure out
which type of context one happens to be interested in
for the specific update at hand.

I'm not aware of installkernel depending on etcupdate
activity, but "man etcupdate"  reports, in part:

 -p Enable “pre-world” mode.  Only merge changes to files that
are necessary to successfully run ‘make installworld’ or
‘make installkernel’. . . .

To my knowledge not even UPDATING shows etcupdate -p
being used before installkernel. "man etcupdate" may be
trying to cover potential future updates that could
change the status? Still, it looks contradictory.

> I'm procrastinating on doing a najor update, and want to keep
> the long record of nothing going Horribly Wrong(tm).




===
Mark Millard
marklmi at yahoo.com

RE: Has the update procedure changed?

[Robert Huff]

Mark Millard  writes:

>   The material in 26.6.5 does not repeat all that, it is
>   more of a summary that is presented.
>   
>   There are also instructions in UPDATING (near the end)
>   and yet other instructions in Makefile (leading
>   comments).
>   
>   I've not done detailed comparisons of such in some
>   time, but they well not be exact matches. As I remember,
>   the UPDATING material was more explicit about various
>   cases/contexts and what was appropriate for them.
>   
>   It can be appropriate to review them all.

1) It would be really nice is someone would take a look and make
sure these 100% non-contradictory.
2) If I can only use one of these, which one should I choose?

I'm procrastinating on doing a najor update, and want to keep
the long record of nothing going Horribly Wrong(tm).


Respectfully,


Robert Huff

Re: Jail compile error on CURRENT?

[Yuri]

James Gritton wrote:
> On 2023-08-07 13:29, Dimitry Andric wrote:
>> On 7 Aug 2023, at 04:50, Yoshihiro Ota  wrote:
>>>
>>> Am I the only one seeing this error?
>>> I'm on 12.4-RELEASE amd64 and building CURRENT as of now.
>>>
>>> jaillex.c:2228:43: error: unused parameter 'yyscanner'
>>> [-Werror,-Wunused-parameter]
>>> void *yyalloc (yy_size_t  size , yyscan_t yyscanner)
>>>  ^
>>> jaillex.c:2233:58: error: unused parameter 'yyscanner'
>>> [-Werror,-Wunused-parameter]
>>> void *yyrealloc  (void * ptr, yy_size_t  size , yyscan_t yyscanner)
>>>     ^
>>> jaillex.c:2245:36: error: unused parameter 'yyscanner'
>>> [-Werror,-Wunused-parameter]
>>> void yyfree (void * ptr , yyscan_t yyscanner)
>>>   ^
>>> 6 errors generated.
>>> *** [jaillex.o] Error code 1
>>>
>>
>> It seems you are not crazy. :) I can reproduce the error, and I think it
>> might be caused by:
>>
>> https://cgit.freebsd.org/src/commit/?id=086e0149ae56641af245ce472e787c2f67d3aea5
>>
>> However, as to why this does not result in an error (or even a warning)
>> on -CURRENT, I have no clue. Maybe in the mean time flex in -CURRENT got
>> updated...
> 
> That is indeed the culprit.  Fortunately, it builds from 13.2-RELEASE,
> so building CURRENT from 12 can be done in two steps.  I hate to be the
> reason the update doesn't work directly, but the include capability I
> added to jail(8) requires re-entrant lex, which apparently managed to
> work around the error in 13.  They reason it doesn't give a warning BTW
> is these two lines that lex adds:
> 
>     struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
>     (void)yyg;
> 
> That makes yyscanner officially "used" even though its value is never
> actually read.  I suspect the version of lex in 12.4-RELEASE doesn't
> have one or both of those lines.
> 
> Perhaps you could add such lines to the offending functions yourself,
> and continue the make.  Or maybe build (and install) lex on its own
> first; by the time you see this error, there should already be a newer
> version of lex you could pop into place.
> 
> There's probably something I should do to make this work better, or
> perhaps some note I should put into UPDATING before 14.0 is released.

Or there is already a recipe for bootstrapping lex in Makefile.inc1,
though for somewhat older versions; possibly it could be updated for < 13?

.if ${BOOTSTRAPPING} < 133

Re: Jail compile error on CURRENT?

[James Gritton]

On 2023-08-07 13:29, Dimitry Andric wrote:

On 7 Aug 2023, at 04:50, Yoshihiro Ota  wrote:


Am I the only one seeing this error?
I'm on 12.4-RELEASE amd64 and building CURRENT as of now.

jaillex.c:2228:43: error: unused parameter 'yyscanner' 
[-Werror,-Wunused-parameter]

void *yyalloc (yy_size_t  size , yyscan_t yyscanner)
 ^
jaillex.c:2233:58: error: unused parameter 'yyscanner' 
[-Werror,-Wunused-parameter]

void *yyrealloc  (void * ptr, yy_size_t  size , yyscan_t yyscanner)
^
jaillex.c:2245:36: error: unused parameter 'yyscanner' 
[-Werror,-Wunused-parameter]

void yyfree (void * ptr , yyscan_t yyscanner)
  ^
6 errors generated.
*** [jaillex.o] Error code 1



It seems you are not crazy. :) I can reproduce the error, and I think 
it

might be caused by:

https://cgit.freebsd.org/src/commit/?id=086e0149ae56641af245ce472e787c2f67d3aea5

However, as to why this does not result in an error (or even a warning)
on -CURRENT, I have no clue. Maybe in the mean time flex in -CURRENT 
got

updated...


That is indeed the culprit.  Fortunately, it builds from 13.2-RELEASE, 
so building CURRENT from 12 can be done in two steps.  I hate to be the 
reason the update doesn't work directly, but the include capability I 
added to jail(8) requires re-entrant lex, which apparently managed to 
work around the error in 13.  They reason it doesn't give a warning BTW 
is these two lines that lex adds:


struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
(void)yyg;

That makes yyscanner officially "used" even though its value is never 
actually read.  I suspect the version of lex in 12.4-RELEASE doesn't 
have one or both of those lines.


Perhaps you could add such lines to the offending functions yourself, 
and continue the make.  Or maybe build (and install) lex on its own 
first; by the time you see this error, there should already be a newer 
version of lex you could pop into place.


There's probably something I should do to make this work better, or 
perhaps some note I should put into UPDATING before 14.0 is released.


- Jamie

Re: [Intel AlderLake] Read files to FAT32 or UFS partition cause data corrupt due to P-Core-Core

[Tomoaki AOKI]

On Sun, 6 Aug 2023 12:55:07 +0300
Konstantin Belousov  wrote:

> On Sun, Aug 06, 2023 at 06:12:38PM +0900, Tomoaki AOKI wrote:
> > On Wed, 23 Feb 2022 01:30:28 +0200
> > Konstantin Belousov  wrote:
> > 
> > > On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin wrote:
> > > > On 22.02.2022 17:46, Konstantin Belousov wrote:
> > > > > Ok, the next step is to get the CPU feature reports from P- vs. E- 
> > > > > cores.
> > > > > Patch below should work, with verbose boot.
> > > > 
> > > > Not much difference on that level:
> > > > 
> > > > --- zzzp2022-02-22 18:18:24.531704000 -0500
> > > > +++ zzze2022-02-22 18:18:18.631236000 -0500
> > > > @@ -1,22 +1,21 @@
> > > > -CPU 2: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU)
> > > > +CPU 16: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU)
> > > >Origin="GenuineIntel"  Id=0x90672  Family=0x6  Model=0x97  Stepping=2
> > > > Features=0xbfebfbff
> > > > Features2=0x7ffafbff
> > > >AMD Features=0x2c100800
> > > >AMD Features2=0x121
> > > >Structured Extended 
> > > > Features=0x239ca7eb
> > > >Structured Extended 
> > > > Features2=0x98c027ac
> > > >Structured Extended 
> > > > Features3=0xfc1cc410
> > > >XSAVE Features=0xf
> > > >IA32_ARCH_CAPS=0xd6b
> > > >VT-x: Basic Features=0x3da0500
> > > >  Pin-Based Controls=0xff
> > > >  Primary Processor 
> > > > Controls=0xfffbfffe
> > > >  Secondary Processor 
> > > > Controls=0xf5d7fff
> > > >  Exit Controls=0x3da0500
> > > >  Entry Controls=0x3da0500
> > > >  EPT Features=0x6f34141
> > > >  VPID 
> > > > Features=0x10f01
> > > >TSC: P-state invariant, performance statistics
> > > > -64-Byte prefetching
> > > > -L2 cache: 1280 kbytes, 8-way associative, 64 bytes/line
> > > > +L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line
> > > > 
> > > 
> > > Show me the full verbose dmesg of the boot then.
> > > 
> > > As another blind guess, try to disable pcid, vm.pmap.pcid_enabled=0.
> > > 
> > 
> > Hi.
> > 
> > Intel N100 is reported to crash without this tunable on 13.2 at
> > freebsd-users-jp ML (as this is a ML in Japanese, reported in
> > Japanese). [1]
> > Crashes with UFS, but ZFS is claimed to be OK.
> > 
> > N100 is an Alder Lake-N processor WITHOUT P-CORE. [2] [3]
> > So check logics on workarouund codes (IIRC, all are MFC'ed before 13.2)
> > wouldn't be working?
> 
> Show me the output from x86info -r on the machine, I do not care which
> specific core it is, they should be all the same.  x86info is available
> as sysutils/x86info.

Requested to original reporter and got the result below.
HTH.

---
root@eq12:~ # x86info -r
x86info v1.31pre
/dev/cpuctl0: No such file or directory
Found 4 identical CPUs
Extended Family: 0 Extended Model: 11 Family: 6 Model: 190 Stepping: 0
Type: 0 (Original OEM)
CPU Model (x86info's best guess): Unknown model.
eax in: 0x, eax = 0020 ebx = 756e6547 ecx = 6c65746e edx =
49656e69
eax in: 0x0001, eax = 000b06e0 ebx = 00800800 ecx = 7ffafbbf edx =
bfebfbff
eax in: 0x0002, eax = 00feff01 ebx = 00f0 ecx =  edx =

eax in: 0x0003, eax =  ebx =  ecx =  edx =

eax in: 0x0004, eax = fc004121 ebx = 01c0003f ecx = 003f edx =

eax in: 0x0005, eax = 0040 ebx = 0040 ecx = 0003 edx =
10102020
eax in: 0x0006, eax = 00578ff7 ebx = 0002 ecx = 0009 edx =

eax in: 0x0007, eax = 0002 ebx = 239ca7eb ecx = 98c007bc edx =
fc184410
eax in: 0x0008, eax =  ebx =  ecx =  edx =

eax in: 0x0009, eax =  ebx =  ecx =  edx =

eax in: 0x000a, eax = 07300605 ebx =  ecx = 0007 edx =
8603
eax in: 0x000b, eax = 0001 ebx = 0001 ecx = 0100 edx =

eax in: 0x000c, eax =  ebx =  ecx =  edx =

eax in: 0x000d, eax = 0207 ebx = 0a88 ecx = 0a88 edx =

eax in: 0x000e, eax =  ebx =  ecx =  edx =

eax in: 0x000f, eax =  ebx =  ecx =  edx =

eax in: 0x0010, eax =  ebx = 0004 ecx =  edx =

eax in: 0x0011, eax =  ebx =  ecx =  edx =

eax in: 0x0012, eax =  ebx =  ecx =  edx =

eax in: 0x0013, eax =  ebx =  ecx =  edx =

eax in: 0x0014, eax = 0001 ebx = 01ff ecx = 8007 edx =

eax in: 0x0015, eax = 0002 ebx = 002a ecx = 0249f000 edx =

eax in: 0x0016, eax = 0320 ebx = 0d48 ecx = 0064 edx =

eax in: 0x0017, eax =  ebx =  ecx =  edx =

eax in: 0x0018, eax = 0004 ebx =  ecx =  edx =

eax in: 0x0019, eax = 0007 ebx = 

14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so?

[Michael Grimm]

Hi,

I'm currently in the process to prepare for upcoming 14-STABLE. Thus, I 
upgraded one of my sytems from 13-STABLE to 14-CURRENT.

Everything went fine, except for programs that need /usr/lib/pam_opie.so which 
are:

1) jexec  /usr/bin/login -u 
2) redis-server
3) mariadb1011-server

Error messages:

su[6371]: in openpam_load_module(): no pam_opie.so found
su[6371]: pam_start: System error

Well, although it has been reported some time ago that pam_opie and 
pam_opieaccess.so will become removed in Freebsd 14, there is a port 
security/opie providing both libraries. Quick workaround.

But I want to understand why the above mentioned programs do fail although not 
dynamically linked against /usr/lib/pam_opie.so

MWN> ldd /usr/bin/login
/usr/bin/login:
libutil.so.9 => /lib/libutil.so.9 (0xd408ecf7000)
libpam.so.6 => /usr/lib/libpam.so.6 (0xd408f6f2000)
libbsm.so.3 => /usr/lib/libbsm.so.3 (0xd4090dab000)
libc.so.7 => /lib/libc.so.7 (0xd408f99d000)
[vdso] (0xd408e18f630)

MWN> ldd /usr/local/bin/redis-server
/usr/local/bin/redis-server:
libthr.so.3 => /lib/libthr.so.3 (0x89a8847f000)
libm.so.5 => /lib/libm.so.5 (0x89a87beb000)
libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x89a891c7000)
libssl.so.30 => /usr/lib/libssl.so.30 (0x89a8a271000)
libcrypto.so.30 => /lib/libcrypto.so.30 (0x89a8b02b000)
libc.so.7 => /lib/libc.so.7 (0x89a8c7fe000)
libelf.so.2 => /lib/libelf.so.2 (0x89a8949b000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x89a8bb85000)
[vdso] (0x89a87323630)

MWN> ldd /usr/local/libexec/mariadbd
/usr/local/libexec/mariadbd:
libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0 (0x145ae576f000)
libwrap.so.6 => /usr/lib/libwrap.so.6 (0x145ae64a5000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x145ae74be000)
libz.so.6 => /lib/libz.so.6 (0x145ae7d0b000)
libm.so.5 => /lib/libm.so.5 (0x145ae8b3e000)
libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x145ae6e03000)
libssl.so.30 => /usr/lib/libssl.so.30 (0x145ae9575000)
libcrypto.so.30 => /lib/libcrypto.so.30 (0x145aeafff000)
libc++.so.1 => /lib/libc++.so.1 (0x145ae9e3b000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x145aeaa85000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x145aec745000)
libthr.so.3 => /lib/libthr.so.3 (0x145aebf1)
libc.so.7 => /lib/libc.so.7 (0x145aec7fa000)
libelf.so.2 => /lib/libelf.so.2 (0x145aee867000)
[vdso] (0x145ae5010630)

Which alternatives to pam_opie should I investigate?
Reason: I want to get rid of security/opie

Thanks and regards,
Michael

Re: Jail compile error on CURRENT?

[Dimitry Andric]

On 7 Aug 2023, at 04:50, Yoshihiro Ota  wrote:
> 
> Am I the only one seeing this error?
> I'm on 12.4-RELEASE amd64 and building CURRENT as of now.
> 
> jaillex.c:2228:43: error: unused parameter 'yyscanner' 
> [-Werror,-Wunused-parameter]
> void *yyalloc (yy_size_t  size , yyscan_t yyscanner)
>  ^
> jaillex.c:2233:58: error: unused parameter 'yyscanner' 
> [-Werror,-Wunused-parameter]
> void *yyrealloc  (void * ptr, yy_size_t  size , yyscan_t yyscanner)
> ^
> jaillex.c:2245:36: error: unused parameter 'yyscanner' 
> [-Werror,-Wunused-parameter]
> void yyfree (void * ptr , yyscan_t yyscanner)
>   ^
> 6 errors generated.
> *** [jaillex.o] Error code 1
> 

It seems you are not crazy. :) I can reproduce the error, and I think it
might be caused by:

https://cgit.freebsd.org/src/commit/?id=086e0149ae56641af245ce472e787c2f67d3aea5

However, as to why this does not result in an error (or even a warning)
on -CURRENT, I have no clue. Maybe in the mean time flex in -CURRENT got
updated...

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: armv7 kyua runs via chroot on aarch64: zfs tests leave behind processes from timed out tests

[Mark Millard]

On Aug 7, 2023, at 11:29, Enji Cooper  wrote:
> 
> 
>> On Aug 3, 2023, at 10:20 AM, Mark Millard  wrote:
>> 
>> .. .
> 
> Hi Mark,
> Could you please submit bugs and CC freebsd-testing or another appropriate 
> mailing list? It looks like there are some Arm64 architecture specific issues 
> that need to be addressed based on the limited information I have from these 
> emails.
> Do you have DEADLKRES/INVARIANTS/WITNESS compiled into your kernel? If not, 
> could you please do that?
> If that doesn’t give any helpful hints, could you please panic the kernel and 
> dump some debug info from ddb, e.g.,
> 1. alltrace
> 2. show allchains
> 3. show alllocks

I tend to submit only once/if I've done the work to
establish the problems in snapshots or other such
that do not involve my builds. Submitting only based
on my builds is a means of last resort for me. Also,
when a bunch of issues are showing up in the same
time frame, I tend to start with a subset and let
others sit for a time until I get to them. There are
a bunch pending at this point. I'm more willing to
report to the lists based on less information and
a longer time frame to having more information,
largely in case it prompts others that have related
observations or the like.

My recent submittals for cortex-A7 (armv7) kyua run
related panics are:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272965
("armv7 'Alignment Fault' on read panic during udp_input for
kyua's sys/netinet6/exthdr:exthdr ; other udp_input related
panics")

and:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272966
("armv7 Kernel page fault with non-sleepable locks held panic
during in6ifa_ifwithaddr for kyua's sys/netpfil/pf/killstate:v6;
more tests too")

An interesting oddity is that, in my somewhat older
environment, I do not get the udp_input related panics
(272965). I only got those with the snapshot (while
trying to gather information to create the other submital
[272966]).

Michal Meloun has been having me test patches related
to these. But I could only effectively test the 272966
cases in the context I have, given that "interesting
oddity". (Michal also originally thought the 2 reports
were duplicates of each other. But they are not, at
least in my builds.)

I'll note that the "non-sleepable locks" is more of
an identification of context than a cause: it is from
part of the code that handles an alignment abort (that
shows up in the console output somewhat later), or
so I've been told.

It is true that I normally run non-debug builds. But
my normal build procedure builds both ways and I
substitute (install) the relevant debug build (WITNESS
and such included) when I get to the point that I'd
use it to advantage. My testing of Michal's patches
are based on my debug-build context.

===
Mark Millard
marklmi at yahoo.com

Re: armv7 kyua runs via chroot on aarch64: zfs tests leave behind processes from timed out tests

[Enji Cooper]

> On Aug 3, 2023, at 10:20 AM, Mark Millard  wrote:
> 
> On Aug 3, 2023, at 07:18, Mark Millard  wrote:
> 
>> On Aug 3, 2023, at 00:19, Mark Millard  wrote:
>> 
>>> This is after the patch (leading whitespace might
>>> not have been preserved in what you see):
>>> 
>>> # git -C /usr/main-src/ diff sys/dev/md/
>>> diff --git a/sys/dev/md/md.c b/sys/dev/md/md.c
>>> index a719dccb1955..365296ec4276 100644
>>> --- a/sys/dev/md/md.c
>>> +++ b/sys/dev/md/md.c
>>> @@ -147,8 +147,15 @@ struct md_ioctl32 {
>>>  int md_fwsectors;
>>>  uint32_tmd_label;
>>>  int md_pad[MDNPAD];
>>> +#ifdef __aarch64__
>>> +   uint32_tmd_pad0;
>>> +#endif
>>> } __attribute__((__packed__));
>>> +#ifdef __aarch64__
>>> +CTASSERT((sizeof(struct md_ioctl32)) == 440);
>>> +#else
>>> CTASSERT((sizeof(struct md_ioctl32)) == 436);
>>> +#endif
>>> 
>>> #defineMDIOCATTACH_32  _IOC_NEWTYPE(MDIOCATTACH, struct md_ioctl32)
>>> #defineMDIOCDETACH_32  _IOC_NEWTYPE(MDIOCDETACH, struct md_ioctl32)
>>> 
>>> 
>>> The kyua run is still in process, but at this point there is
>>> the following accumulation from the zfs testing timouts:
>>> 
>>> # ps -alxdww
>>> UID   PID  PPID C PRI NI   VSZ   RSS MWCHAN   STAT TTTIME COMMAND
>>> . . .
>>> 0 17491 1 6  20  0 36460 12324 -T - 0:24.71 |-- 
>>> fsync_integrity /testdir2316/testfile2316
>>> 0 17551 1 5  20  0 10600  7512 tx->tx_s D - 0:00.00 |-- 
>>> /sbin/zpool destroy -f testpool.2316
>>> 0 17739 1 7  20  0 10600  7308 zfs tear D - 0:00.00 |-- 
>>> /sbin/zpool destroy -f testpool.2316
>>> 0 17841 1 3  20  0 10600  7316 tx->tx_s D - 0:00.00 |-- 
>>> /sbin/zpool destroy -f testpool.2316
>>> 0 17860 1 0  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 17888 1 3  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 17907 1 6  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 17928 1 7  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 17955 1 0  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 17976 1 4  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 17995 1 2  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18023 1 2  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18043 1 2  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18064 1 3  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18085 1 0  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18114 1 7  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18135 1 2  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18157 1 6  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18177 1 6  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18205 1 4  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18224 1 1  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18255 1 3  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18275 1 1  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18296 1 5  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18317 1 4  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18345 1 4  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18365 1 2  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18386 1 3  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18412 1 1  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18447 1 5  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18466 1 5  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18516 1 6  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18535 1 2  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>>> 0 18632 1 0  20  0 10080  6956 spa_name D - 0:00.00 |-- 
>>> /sbin/zfs upgrade
>> 
>> It has added:
>> 
>> 0 18656 1 7  20  0  10080  6956 spa_name D - 0:00.00 |-- 
>> /sbin/zfs upgrade
>> 0 18748 1 0  20  0  10080  6956 spa_name D - 0:00.00 |-- 
>> /sbin/zfs upgrade
>> 0 18767 1 4  20  0  10080  6956 spa_name D - 0:00.00 |-- 
>> /sbin/zfs upgrade
>> 0 18858 1 5  20  0  10080  6956 spa_name D - 0:00.00 |-- 
>> /sbin/zfs upgrade

Re: Has the update procedure changed?

[Matthias Apitz]

El día lunes, agosto 07, 2023 a las 08:51:55a. m. -0700, Kevin Oberman escribió:

> On Sun, Aug 6, 2023 at 9:51 AM Tim Kellers  wrote:
> 
> >
> >
> > On Aug 6, 2023, at 11:05 AM, Kevin Oberman  wrote:
> >
> > 
> > On Sat, Aug 5, 2023 at 10:51 PM Matthias Apitz  wrote:
> >
> >> In the past I was used to use the following procedure to install a new
> >> kernel and world:
> >>
> >> # cd /usr/src
> >> # make installkernel
> >> # shutdown -r now
> >>
> >> boot -s from the loader prompt
> >>
> >> # adjkerntz -i
> >> # mount -a -t ufs
> >> # mergemaster -p
> >> # cd /usr/src
> >> # make installworld
> >> # mergemaster
> >> # yes | make delete-old
> >> # yes | make delete-old-libs
> >>
> >> # reboot
> >>
> ...

> I am more confused about  "etcupdate -p". Both files put it after the
> kernel installation and reboot but before the installworld. The man page
> for etcupdate says that '-p' it should be run before "make buildworld" and
> I have always followed the man pages.

The man page of mergemaster says:

 -p  Pre-buildworld mode.  Compares only files known to be
 essential to the success of {build|install}world, i.e.,
 /etc/group and /etc/master.passwd.

i.e. it must be run after installkernel and before installworld to
adjust the new /etc/group and /etc/master.passwd. After installworld mergemaster
should be run (or etcupdate) without -p to adjust all the scripts below
/etc, /etc/rc.d/ ... I've used this procedure above for many years and
it always let me decide it I want the new or the old or deal later with
the diff of all these files. And so I did it yesterday and it worked fine again.

Will check the next time what etcupdate wants to do, because it seems
the sucsessor of mergemaster.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Re: Has the update procedure changed?

[Kevin Oberman]

On Sun, Aug 6, 2023 at 9:51 AM Tim Kellers  wrote:

>
>
> On Aug 6, 2023, at 11:05 AM, Kevin Oberman  wrote:
>
> 
> On Sat, Aug 5, 2023 at 10:51 PM Matthias Apitz  wrote:
>
>> In the past I was used to use the following procedure to install a new
>> kernel and world:
>>
>> # cd /usr/src
>> # make installkernel
>> # shutdown -r now
>>
>> boot -s from the loader prompt
>>
>> # adjkerntz -i
>> # mount -a -t ufs
>> # mergemaster -p
>> # cd /usr/src
>> # make installworld
>> # mergemaster
>> # yes | make delete-old
>> # yes | make delete-old-libs
>>
>> # reboot
>>
>> Now the handbook
>> https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld
>> says only:
>>
>> # cd /usr/src
>> # make installkernel
>> # shutdown -r now
>> # cd /usr/src
>> # make installworld
>> # shutdown -r now
>>
>> Has this changed in past two years?
>>
>> Thanks
>>
>> matthias
>> --
>> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/
>> +49-176-38902045
>> Public GnuPG key: http://www.unixarea.de/key.pub
>>
>
> Wow! Several obvious reasons that this looks just wrong. (Then again, so
> is yours in one case.)
> 1. "mergemaster -p" MUST be run before you build the kernel. (Actually,
> hte man page says it should be run BEFORE buildworld and that is what I've
> always done although I have never seen a case where it was needed until
> buildkernel.
> 2. While mergemaster(8) is still in the system, you really should be using
> etcupdate(8). You also need to understand how a three-way merge is done and
> that you  often need to edit the merged file when first running it.  It's
> pretty simple to run and rarely is needed after the first run, but it is
> critical to do this for /etc files that you have modified. It's generally
> just picking which of the two (original/yours) you want in the final file.
> The big win with etcupdate(8) is that it only needs to be run once for
> modified files in almost all cases.
> 3. Where is "make check-old" and the other tests to get rid of old files.
> Leaving these around can lead to serious issues.
> 4. If you don't do adjkerntz -i, you might find files installed in the
> future which can get REALLY  confusing!
>
> Historically, the final source of truth for all of this is
> /usr/src/UPDATING. It has been updated for etcupdate(8) and is handled by
> imp@, so I tend to believe it is correct.
>
> OK. Everyone who knows better, please explain why. I didn't mention "fsck
> -p" but I'm really paranoid and it really, really should not be needed
> unless something goes wrong in the shutdown after installing the new kernel.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
>
> I’ve always used the procedure listed at line 90 of the Makefile in
> /usr/src as the source of truth. Has that changed?
>
> Tim
>

UPDATING seems to match the Makefile except that Makefile is far less
detailed. The Makefile even says "See src/UPDATING `COMMON ITEMS' for more
complete information."

I am more confused about  "etcupdate -p". Both files put it after the
kernel installation and reboot but before the installworld. The man page
for etcupdate says that '-p' it should be run before "make buildworld" and
I have always followed the man pages.
-- 
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

Re: poudriere && git

[void]

On Sun, Aug 06, 2023 at 04:11:00PM +0200, Matthias Apitz wrote:


I'm now already running a new "make buildworld" again, which perhaps will
but the actual tools into .../legacy/... and they will work because
tools and shared libs fit together.

I think there is something broken in buildworld with these legacy stuff.


The way I build multiple versions of poudriere jails (this is on a -current
box) is like this:

1. first decide what version to build. In this case, 13-stable.
2. if not already done, git clone https://git.freebsd.org/src.git /usr/src
3. cd /usr/src && git checkout stable/13
4. poudriere jail -c -j 13stable -b -m src=/usr/src -J8 -v stable/13

then

if I want to make a 12.4 poudriere on the same box:

5. cd /usr/src && git checkout releng/12.4
6. poudriere jail -c -j 124releng -b -m src=/usr/src -J8 -v releng/12.4

7. if I want to update these jails, I need to first 'git checkout' the right 
version
   before running -u. I cannot accurately recall if you'd have to use -b as 
well,
   but I don't think you do. After all, -v isn't required in a -u context. So, 
to update,
   'poudriere jail -j jailname -J8 -u'. -b builds from the specified sources 
*and* makes
   its own obj tree, from what I've seen.
--

Re: service routing restart, service dhclient restart (was: Unreliability with DHCP)

[Oleksandr Kryvulia]

06.08.23 19:23, Graham Perrin пише:

Thanks,

On 06/08/2023 08:36, Oleksandr Kryvulia wrote:
… In my case default route is assigned by dhclient, so 'service 
routing restart' must be run quickly after 'service netif restart' - 
before we receive dhcp offer. 


Is this documented and explained somewhere, or did you learn through 
trial and error?


It's my own expirience  + reading /etc/rc.d/routing




Another option is to run 'service dhclient restart wlan0' after 
routing restart. …


Is there, similarly, a need to rush the two commands?
I can't answer for sure, you need to try different options and choose 
the one that works. If you're using typical network configuration, 
you'll probably be fine with routing restart + dhclient restart only. 
This works for me in most cases until I configured lagg interface.


 no route;
 /etc/rc.d/dhclient: WARNING: 
failed to start dhclient