Jail compile error on CURRENT?

[Yoshihiro Ota]

Hi,

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

Re: Has the update procedure changed?

[Tim Kellers]

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 EngineerE-mail: rkober...@gmail.comPGP 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

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

[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?



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


Is there, similarly, a need to rush the two commands?

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

Re: make buildworld puts legacy tools into the /usr/obj/... tree

[Michael Gmelin]

On 6. Aug 2023, at 18:12, Warner Losh  wrote:On Sun, Aug 6, 2023 at 10:05 AM Matthias Apitz  wrote:El día domingo, agosto 06, 2023 a las 09:58:32a. m. -0600, Warner Losh escribió:

> On Sun, Aug 6, 2023 at 7:58 AM Matthias Apitz  wrote:
> 
> >
> > I did, based of a git clone of head, a clean compile of world and kernel
> > with
> >
> > # cd /usr
> > # rm -rf obj
> > # mkdir obj
> > # cd src
> > # make -j8 buildworld
> > # make -j8 buildkernel
> > ...
> > I installed the result and the system runs fine. For some test I wanted
> > to do another installation to some DESTDIR with
> >
> > # make installworld DESTDIR=/home/...
> >
> > This failed with:
> >
> > --- installworld ---
> > mkdir -p /tmp/install.j76anzU56j
> >
> > ...
> > Required library libdialog.so.8 not found.
> > *** [installworld] Error code 1
> >
> > make[1]: stopped in /usr/src
> >
> > Investigating the problem it turned out that the 'make buildworld' puts
> > a lot of legacy binaries in to some directory:
> >
> > # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin
> > total 36976
> > -r-xr-xr-x  1 root wheel   13304 Nov 30  2020 [
> > lrwxr-xr-x  1 root wheel      54 Aug  5 13:05 apropos ->
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc
> > -rwxr-xr-x  1 root wheel 1008512 Aug  5 13:05 asn1_compile
> > -r-xr-xr-x  1 root wheel  217504 Nov 30  2020 awk
> > -r-xr-xr-x  1 root wheel    9576 Nov 30  2020 basename
> > -r-xr-xr-x  1 root wheel  195712 Nov 30  2020 bmake
> > -r-xr-xr-x  1 root wheel   33848 Nov 30  2020 bunzip2
> > ...
> > They are all from the system before updating it (from Nov 30 2020) and
> > of course are missing shared libs when they get called in the actual
> > system, for example
> >
> > # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup:
> >         libdialog.so.8 => not found (0)
> >         ^^
> >         libncursesw.so.9 => /lib/libncursesw.so.9 (0xf283d7b4000)
> >         libc.so.7 => /lib/libc.so.7 (0xf283e729000)
> >         libtinfow.so.9 => /lib/libtinfow.so.9 (0xf283c93d000)
> >         [vdso] (0xf283c4a4000)
> >
> > # which tzsetup
> > /usr/sbin/tzsetup
> > # ldd /usr/sbin/tzsetup
> > /usr/sbin/tzsetup:
> >         libprivatebsddialog.so.0 => /usr/lib/libprivatebsddialog.so.0
> > (0x1797fe45c000)
> >         libc.so.7 => /lib/libc.so.7 (0x1797fec89000)
> >         libncursesw.so.9 => /lib/libncursesw.so.9 (0x1798011df000)
> >         libtinfow.so.9 => /lib/libtinfow.so.9 (0x17980043d000)
> >         libformw.so.6 => /usr/lib/libformw.so.6 (0x17980164c000)
> >         [vdso] (0x1797fe2d9000)
> >
> > Why is this with the tools in /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin ?
> > Or what I have done wrong or overlooked?
> >
> 
> So, the build process builds tools that are used to make and install
> FreeBSD.
> That's what legacy is about: providing a compatible way to do all this. We
> setup env vars, etc, so that these tools pull their libraries from legacy
> as well
> so that we have a consistent set of binaries to run on while the rest of
> the world
> is being replaced. I'm surprised to see this failing, since it's what
> nanobsd does
> all the time, and I build new systems with nanobsd every week based on
> recent
> current trees.
> 
> Is there a libdalog.so.8 in your tmp/legacy tree at all?

No, there is not:

root@jet:~ # find /usr/obj.broken -name libdalog.so.8
root@jet:~ # 

The problem, for sure, is not when you build every day, but in my case
the last build (and the system used for building) was 2 years old. And note:
I started with an empty new /usr/obj.So what's the vintage of the host you are building with? And what sources areyou building...Also of note: we switched to no-clean builds by default which is way faster, butalso exposes issues like this...
Thanks, this is valuable information (starts adapting idempotent playbooks).-m

Re: make buildworld puts legacy tools into the /usr/obj/... tree

[Matthias Apitz]

El día domingo, agosto 06, 2023 a las 10:12:03a. m. -0600, Warner Losh escribió:

> So what's the vintage of the host you are building with? And what sources
> are
> you building...

The vintage was (now updated): 13.0-CURRENT 1300130 r368164
and /usr/src was git cloned from yesterday's head.

matthias

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

Re: make buildworld puts legacy tools into the /usr/obj/... tree

[Warner Losh]

On Sun, Aug 6, 2023 at 10:05 AM Matthias Apitz  wrote:

> El día domingo, agosto 06, 2023 a las 09:58:32a. m. -0600, Warner Losh
> escribió:
>
> > On Sun, Aug 6, 2023 at 7:58 AM Matthias Apitz  wrote:
> >
> > >
> > > I did, based of a git clone of head, a clean compile of world and
> kernel
> > > with
> > >
> > > # cd /usr
> > > # rm -rf obj
> > > # mkdir obj
> > > # cd src
> > > # make -j8 buildworld
> > > # make -j8 buildkernel
> > > ...
> > > I installed the result and the system runs fine. For some test I wanted
> > > to do another installation to some DESTDIR with
> > >
> > > # make installworld DESTDIR=/home/...
> > >
> > > This failed with:
> > >
> > > --- installworld ---
> > > mkdir -p /tmp/install.j76anzU56j
> > >
> > > ...
> > > Required library libdialog.so.8 not found.
> > > *** [installworld] Error code 1
> > >
> > > make[1]: stopped in /usr/src
> > >
> > > Investigating the problem it turned out that the 'make buildworld' puts
> > > a lot of legacy binaries in to some directory:
> > >
> > > # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin
> > > total 36976
> > > -r-xr-xr-x  1 root wheel   13304 Nov 30  2020 [
> > > lrwxr-xr-x  1 root wheel  54 Aug  5 13:05 apropos ->
> > > /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc
> > > -rwxr-xr-x  1 root wheel 1008512 Aug  5 13:05 asn1_compile
> > > -r-xr-xr-x  1 root wheel  217504 Nov 30  2020 awk
> > > -r-xr-xr-x  1 root wheel9576 Nov 30  2020 basename
> > > -r-xr-xr-x  1 root wheel  195712 Nov 30  2020 bmake
> > > -r-xr-xr-x  1 root wheel   33848 Nov 30  2020 bunzip2
> > > ...
> > > They are all from the system before updating it (from Nov 30 2020) and
> > > of course are missing shared libs when they get called in the actual
> > > system, for example
> > >
> > > # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup
> > > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup:
> > > libdialog.so.8 => not found (0)
> > > ^^
> > > libncursesw.so.9 => /lib/libncursesw.so.9 (0xf283d7b4000)
> > > libc.so.7 => /lib/libc.so.7 (0xf283e729000)
> > > libtinfow.so.9 => /lib/libtinfow.so.9 (0xf283c93d000)
> > > [vdso] (0xf283c4a4000)
> > >
> > > # which tzsetup
> > > /usr/sbin/tzsetup
> > > # ldd /usr/sbin/tzsetup
> > > /usr/sbin/tzsetup:
> > > libprivatebsddialog.so.0 => /usr/lib/libprivatebsddialog.so.0
> > > (0x1797fe45c000)
> > > libc.so.7 => /lib/libc.so.7 (0x1797fec89000)
> > > libncursesw.so.9 => /lib/libncursesw.so.9 (0x1798011df000)
> > > libtinfow.so.9 => /lib/libtinfow.so.9 (0x17980043d000)
> > > libformw.so.6 => /usr/lib/libformw.so.6 (0x17980164c000)
> > > [vdso] (0x1797fe2d9000)
> > >
> > > Why is this with the tools in
> /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin ?
> > > Or what I have done wrong or overlooked?
> > >
> >
> > So, the build process builds tools that are used to make and install
> > FreeBSD.
> > That's what legacy is about: providing a compatible way to do all this.
> We
> > setup env vars, etc, so that these tools pull their libraries from legacy
> > as well
> > so that we have a consistent set of binaries to run on while the rest of
> > the world
> > is being replaced. I'm surprised to see this failing, since it's what
> > nanobsd does
> > all the time, and I build new systems with nanobsd every week based on
> > recent
> > current trees.
> >
> > Is there a libdalog.so.8 in your tmp/legacy tree at all?
>
> No, there is not:
>
> root@jet:~ # find /usr/obj.broken -name libdalog.so.8
> root@jet:~ #
>
> The problem, for sure, is not when you build every day, but in my case
> the last build (and the system used for building) was 2 years old. And
> note:
> I started with an empty new /usr/obj.
>

So what's the vintage of the host you are building with? And what sources
are
you building...

Also of note: we switched to no-clean builds by default which is way
faster, but
also exposes issues like this...

Warner

Re: poudriere && git

[Matthias Apitz]

El día domingo, agosto 06, 2023 a las 10:03:48a. m. -0600, Warner Losh escribió:

> Unless there's a way to reproduce the problem from a clean build, I doubt
> it will ever be addressed. It works for me, so I need the exact steps to do
> from a clean state to get to failure. I just did a installworld and that
> works just fine with DESTDIR for me, so puzzling out how your system got
> into a weird state is a big time sink that I don't have time to do. if
> there's a set of simple steps, then either that can be documented as
> broken/unsupported or fixed.

There is an easy way to reproduce: install an older FreeBSD, let's say
12.0, update /usr/src with git to head, and run

# rm -rf /usr/obj
# make buildworld
# make installworld DESTDIR=/foo

HIH

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

Re: Fwd: Unreliability with DHCP

[Warner Losh]

On Sun, Aug 6, 2023 at 12:38 AM Kevin Oberman  wrote:

> On Sat, Aug 5, 2023 at 3:16 PM Graham Perrin 
> wrote:
>
>> On 05/08/2023 12:39, Oleksandr Kryvulia wrote:
>> > 04.08.23 19:07, Graham Perrin пише:
>> >>
>> >> Can anyone from freebsd-net@ help?
>> >>
>> >>
>> >>  Forwarded Message 
>> >> Subject: Unreliability with DHCP
>> >> Date: Sun, 30 Jul 2023 16:17:43 +0100
>> >> From: Graham Perrin 
>> >> Organisation: FreeBSD
>> >> To: FreeBSD CURRENT 
>> >>
>> >>
>> >>
>> >> 1. Sleep (suspend) whilst connected to one network
>> >>
>> >> 2. connect to a network elsewhere
>> >>
>> >> 3. wake (resume).
>> >>
>> >> Result:
>> >>
>> >> /etc/resolv.conf frequently contains outdated information. In some
>> >> (maybe all) such cases, the IPv4 inet address is outdated; and so on.
>> >>
>> >> Which /etc/rc.d/ file(s) should I attempt to fix?
>> >>
>> >> I imagine using the resume keyword, which is currently used by only
>> >> one script:
>> >>
>> >> % rcorder -k resume /etc/rc.d/*
>> >> /etc/rc.d/ntpd
>> >> %
>> >>
>> >>
>> >> I routinely run the command below to work around the bug (and observe
>> >> the states of things) – run _after_ the bug bites. I'd prefer a fix,
>> >> to prevent the bites.
>> >>
>> >> ls /var/run/resolvconf/interfaces/ ; route delete default ; ifconfig
>> >> wlan0 down && ifconfig em0 down && sleep 5 ; ls
>> >> /var/run/resolvconf/interfaces/ ; ifconfig em0 up && sleep 15
>> >> ; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; ping -c
>> >> 2 -4 freshports.org
>> >>
>> >
>> >
>> > As dirty workaround I have in my /etc/rc.resume
>> >
>> > service netif restart
>> > service routing restart
>>
>>
>> Thanks, I'll try when I'm next on campus.
>>
>> I do know that 'service routing restart' can be problematic. Please,
>> see, for example, ; I had something
>> similar a few minutes ago.
>>
>
> My usual solution is "service netif restart wlan0" (or the interface you
> are using). It should restart the interface, if rc.conf calls for it,
> dhcpclient and wpa_supplicant (if appropriate).
>

I'll have to remember that. I've been removing and reinsterting my usb
dongle when when dhclient fails.
I'd like to move to the internal wlan card, but the driver support has some
show-stopper issues with
suspend/resume for me more basic than dhclient... However, once those are
resolved, I'd need a way to
workaround the dhclient bug.

Anybody have a clue why this is needed?

Warner

Re: make buildworld puts legacy tools into the /usr/obj/... tree

[Matthias Apitz]

El día domingo, agosto 06, 2023 a las 09:58:32a. m. -0600, Warner Losh escribió:

> On Sun, Aug 6, 2023 at 7:58 AM Matthias Apitz  wrote:
> 
> >
> > I did, based of a git clone of head, a clean compile of world and kernel
> > with
> >
> > # cd /usr
> > # rm -rf obj
> > # mkdir obj
> > # cd src
> > # make -j8 buildworld
> > # make -j8 buildkernel
> > ...
> > I installed the result and the system runs fine. For some test I wanted
> > to do another installation to some DESTDIR with
> >
> > # make installworld DESTDIR=/home/...
> >
> > This failed with:
> >
> > --- installworld ---
> > mkdir -p /tmp/install.j76anzU56j
> >
> > ...
> > Required library libdialog.so.8 not found.
> > *** [installworld] Error code 1
> >
> > make[1]: stopped in /usr/src
> >
> > Investigating the problem it turned out that the 'make buildworld' puts
> > a lot of legacy binaries in to some directory:
> >
> > # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin
> > total 36976
> > -r-xr-xr-x  1 root wheel   13304 Nov 30  2020 [
> > lrwxr-xr-x  1 root wheel  54 Aug  5 13:05 apropos ->
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc
> > -rwxr-xr-x  1 root wheel 1008512 Aug  5 13:05 asn1_compile
> > -r-xr-xr-x  1 root wheel  217504 Nov 30  2020 awk
> > -r-xr-xr-x  1 root wheel9576 Nov 30  2020 basename
> > -r-xr-xr-x  1 root wheel  195712 Nov 30  2020 bmake
> > -r-xr-xr-x  1 root wheel   33848 Nov 30  2020 bunzip2
> > ...
> > They are all from the system before updating it (from Nov 30 2020) and
> > of course are missing shared libs when they get called in the actual
> > system, for example
> >
> > # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup:
> > libdialog.so.8 => not found (0)
> > ^^
> > libncursesw.so.9 => /lib/libncursesw.so.9 (0xf283d7b4000)
> > libc.so.7 => /lib/libc.so.7 (0xf283e729000)
> > libtinfow.so.9 => /lib/libtinfow.so.9 (0xf283c93d000)
> > [vdso] (0xf283c4a4000)
> >
> > # which tzsetup
> > /usr/sbin/tzsetup
> > # ldd /usr/sbin/tzsetup
> > /usr/sbin/tzsetup:
> > libprivatebsddialog.so.0 => /usr/lib/libprivatebsddialog.so.0
> > (0x1797fe45c000)
> > libc.so.7 => /lib/libc.so.7 (0x1797fec89000)
> > libncursesw.so.9 => /lib/libncursesw.so.9 (0x1798011df000)
> > libtinfow.so.9 => /lib/libtinfow.so.9 (0x17980043d000)
> > libformw.so.6 => /usr/lib/libformw.so.6 (0x17980164c000)
> > [vdso] (0x1797fe2d9000)
> >
> > Why is this with the tools in /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin ?
> > Or what I have done wrong or overlooked?
> >
> 
> So, the build process builds tools that are used to make and install
> FreeBSD.
> That's what legacy is about: providing a compatible way to do all this. We
> setup env vars, etc, so that these tools pull their libraries from legacy
> as well
> so that we have a consistent set of binaries to run on while the rest of
> the world
> is being replaced. I'm surprised to see this failing, since it's what
> nanobsd does
> all the time, and I build new systems with nanobsd every week based on
> recent
> current trees.
> 
> Is there a libdalog.so.8 in your tmp/legacy tree at all?

No, there is not:

root@jet:~ # find /usr/obj.broken -name libdalog.so.8
root@jet:~ # 

The problem, for sure, is not when you build every day, but in my case
the last build (and the system used for building) was 2 years old. And note:
I started with an empty new /usr/obj.

matthias

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

Re: poudriere && git

[Warner Losh]

On Sun, Aug 6, 2023 at 10:01 AM Matthias Apitz  wrote:

> El día domingo, agosto 06, 2023 a las 04:11:00p. m. +0200, Matthias Apitz
> escribió:
>
> > --
> > --- installworld ---
> > mkdir -p /tmp/install.j76anzU56j
> >
> > ...
> > Required library libdialog.so.8 not found.
> > *** [installworld] Error code 1
> >
> > make[1]: stopped in /usr/src
> > 1 error
>
> Now after a new 'make buildworld' the jail creation worked fine:
>
> # poudriere jail -c -j 140-CURRENT -m src=/usr/src
> ...
> [00:02:27] Recording filesystem state for clean... done
> [00:02:28] Jail 140-CURRENT 14.0-CURRENT 1400094 amd64 is ready to be used
>
> # poudriere jail -l
> JAILNAMEVERSION  ARCH  METHOD   TIMESTAMP
>  PATH
> 140-CURRENT 14.0-CURRENT 1400094 amd64 src=/usr/src 2023-08-06
> 17:35:06 /usr/local/poudriere/jails/140-CURRENT
> freebsd-r368166 13.0-CURRENT 1300130 r368164 amd64 svn+http 2020-11-30
> 12:43:46 /usr/local/poudriere/jails/freebsd-r368166
>
> I will file a PR about this legacy files problem. Thanks for your help.
>

Unless there's a way to reproduce the problem from a clean build, I doubt
it will ever be addressed. It works for me, so I need the exact steps to do
from a clean state to get to failure. I just did a installworld and that
works just fine with DESTDIR for me, so puzzling out how your system got
into a weird state is a big time sink that I don't have time to do. if
there's a set of simple steps, then either that can be documented as
broken/unsupported or fixed.

Warner

Re: poudriere && git

[Matthias Apitz]

El día domingo, agosto 06, 2023 a las 04:11:00p. m. +0200, Matthias Apitz 
escribió:

> --
> --- installworld ---
> mkdir -p /tmp/install.j76anzU56j
> 
> ...
> Required library libdialog.so.8 not found.
> *** [installworld] Error code 1
> 
> make[1]: stopped in /usr/src
> 1 error

Now after a new 'make buildworld' the jail creation worked fine:

# poudriere jail -c -j 140-CURRENT -m src=/usr/src
...
[00:02:27] Recording filesystem state for clean... done
[00:02:28] Jail 140-CURRENT 14.0-CURRENT 1400094 amd64 is ready to be used

# poudriere jail -l
JAILNAMEVERSION  ARCH  METHOD   TIMESTAMP   
PATH
140-CURRENT 14.0-CURRENT 1400094 amd64 src=/usr/src 2023-08-06 
17:35:06 /usr/local/poudriere/jails/140-CURRENT
freebsd-r368166 13.0-CURRENT 1300130 r368164 amd64 svn+http 2020-11-30 
12:43:46 /usr/local/poudriere/jails/freebsd-r368166

I will file a PR about this legacy files problem. Thanks for your help.

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

Re: make buildworld puts legacy tools into the /usr/obj/... tree

[Warner Losh]

On Sun, Aug 6, 2023 at 7:58 AM Matthias Apitz  wrote:

>
> I did, based of a git clone of head, a clean compile of world and kernel
> with
>
> # cd /usr
> # rm -rf obj
> # mkdir obj
> # cd src
> # make -j8 buildworld
> # make -j8 buildkernel
> ...
> I installed the result and the system runs fine. For some test I wanted
> to do another installation to some DESTDIR with
>
> # make installworld DESTDIR=/home/...
>
> This failed with:
>
> --- installworld ---
> mkdir -p /tmp/install.j76anzU56j
>
> ...
> Required library libdialog.so.8 not found.
> *** [installworld] Error code 1
>
> make[1]: stopped in /usr/src
>
> Investigating the problem it turned out that the 'make buildworld' puts
> a lot of legacy binaries in to some directory:
>
> # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin
> total 36976
> -r-xr-xr-x  1 root wheel   13304 Nov 30  2020 [
> lrwxr-xr-x  1 root wheel  54 Aug  5 13:05 apropos ->
> /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc
> -rwxr-xr-x  1 root wheel 1008512 Aug  5 13:05 asn1_compile
> -r-xr-xr-x  1 root wheel  217504 Nov 30  2020 awk
> -r-xr-xr-x  1 root wheel9576 Nov 30  2020 basename
> -r-xr-xr-x  1 root wheel  195712 Nov 30  2020 bmake
> -r-xr-xr-x  1 root wheel   33848 Nov 30  2020 bunzip2
> ...
> They are all from the system before updating it (from Nov 30 2020) and
> of course are missing shared libs when they get called in the actual
> system, for example
>
> # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup
> /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup:
> libdialog.so.8 => not found (0)
> ^^
> libncursesw.so.9 => /lib/libncursesw.so.9 (0xf283d7b4000)
> libc.so.7 => /lib/libc.so.7 (0xf283e729000)
> libtinfow.so.9 => /lib/libtinfow.so.9 (0xf283c93d000)
> [vdso] (0xf283c4a4000)
>
> # which tzsetup
> /usr/sbin/tzsetup
> # ldd /usr/sbin/tzsetup
> /usr/sbin/tzsetup:
> libprivatebsddialog.so.0 => /usr/lib/libprivatebsddialog.so.0
> (0x1797fe45c000)
> libc.so.7 => /lib/libc.so.7 (0x1797fec89000)
> libncursesw.so.9 => /lib/libncursesw.so.9 (0x1798011df000)
> libtinfow.so.9 => /lib/libtinfow.so.9 (0x17980043d000)
> libformw.so.6 => /usr/lib/libformw.so.6 (0x17980164c000)
> [vdso] (0x1797fe2d9000)
>
> Why is this with the tools in /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin ?
> Or what I have done wrong or overlooked?
>

So, the build process builds tools that are used to make and install
FreeBSD.
That's what legacy is about: providing a compatible way to do all this. We
setup env vars, etc, so that these tools pull their libraries from legacy
as well
so that we have a consistent set of binaries to run on while the rest of
the world
is being replaced. I'm surprised to see this failing, since it's what
nanobsd does
all the time, and I build new systems with nanobsd every week based on
recent
current trees.

Is there a libdalog.so.8 in your tmp/legacy tree at all?

Warner

Re: Has the update procedure changed?

[Kevin Oberman]

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

Re: poudriere && git

[Matthias Apitz]

El día domingo, agosto 06, 2023 a las 03:50:15p. m. +0200, Michael Grimm 
escribió:

> Matthias Apitz  wrote
> 
> Creation:
> poudriere jail -c -j stable -m src=/usr/src
> 

Thanks. I tested this as well some hours ago and it failed for the
reason I detailed some minutes ago in the other mail with the 
Subject: make buildworld puts legacy tools into the /usr/obj/...

The jail creation does internally also a 'make installworld':

# poudriere jail -c -j 140-CURRENT -m src=/usr/src
[00:00:00] Creating 140-CURRENT fs at /usr/local/poudriere/jails/140-CURRENT... 
done
[00:00:01] Copying /usr/src to /usr/local/poudriere/jails/140-CURRENT/usr/src...
[00:02:02] Starting make installworld
--- installworld ---
make[1]: "/usr/obj/usr/src/amd64.amd64/toolchain-metadata.mk" line 1: Using 
cached toolchain metadata from build at jet on Sat Aug  5 14:12:11 CEST 2023
--- _installcheck_world ---
--
>>> Install check world
--
--- installworld ---
mkdir -p /tmp/install.j76anzU56j

...
Required library libdialog.so.8 not found.
*** [installworld] Error code 1

make[1]: stopped in /usr/src
1 error

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.

In any case, thanks for your help.

matthias

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

make buildworld puts legacy tools into the /usr/obj/... tree

[Matthias Apitz]

I did, based of a git clone of head, a clean compile of world and kernel
with

# cd /usr
# rm -rf obj
# mkdir obj
# cd src
# make -j8 buildworld
# make -j8 buildkernel
...
I installed the result and the system runs fine. For some test I wanted
to do another installation to some DESTDIR with

# make installworld DESTDIR=/home/...

This failed with:

--- installworld ---
mkdir -p /tmp/install.j76anzU56j

...
Required library libdialog.so.8 not found.
*** [installworld] Error code 1

make[1]: stopped in /usr/src

Investigating the problem it turned out that the 'make buildworld' puts
a lot of legacy binaries in to some directory:

# ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin
total 36976
-r-xr-xr-x  1 root wheel   13304 Nov 30  2020 [
lrwxr-xr-x  1 root wheel  54 Aug  5 13:05 apropos -> 
/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc
-rwxr-xr-x  1 root wheel 1008512 Aug  5 13:05 asn1_compile
-r-xr-xr-x  1 root wheel  217504 Nov 30  2020 awk
-r-xr-xr-x  1 root wheel9576 Nov 30  2020 basename
-r-xr-xr-x  1 root wheel  195712 Nov 30  2020 bmake
-r-xr-xr-x  1 root wheel   33848 Nov 30  2020 bunzip2
...
They are all from the system before updating it (from Nov 30 2020) and
of course are missing shared libs when they get called in the actual
system, for example

# ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup
/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup:
libdialog.so.8 => not found (0)
^^
libncursesw.so.9 => /lib/libncursesw.so.9 (0xf283d7b4000)
libc.so.7 => /lib/libc.so.7 (0xf283e729000)
libtinfow.so.9 => /lib/libtinfow.so.9 (0xf283c93d000)
[vdso] (0xf283c4a4000)

# which tzsetup
/usr/sbin/tzsetup
# ldd /usr/sbin/tzsetup
/usr/sbin/tzsetup:
libprivatebsddialog.so.0 => /usr/lib/libprivatebsddialog.so.0 
(0x1797fe45c000)
libc.so.7 => /lib/libc.so.7 (0x1797fec89000)
libncursesw.so.9 => /lib/libncursesw.so.9 (0x1798011df000)
libtinfow.so.9 => /lib/libtinfow.so.9 (0x17980043d000)
libformw.so.6 => /usr/lib/libformw.so.6 (0x17980164c000)
[vdso] (0x1797fe2d9000)

Why is this with the tools in /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin ?
Or what I have done wrong or overlooked?

matthias

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

Re: poudriere && git

[Michael Grimm]

Matthias Apitz  wrote

> poudriere jail -c -j head -m null -S /usr/src
> 
> which gives an error:
> 
> [00:00:00] Error: Must set -M to path of jail to use
> 
> I don't know what to set for the path to -M. The host system is in
> /usr/src and /usr/obj.  My old existing jail is:
> 
> poudriere jail -l
> JAILNAMEVERSION  ARCH  METHOD   TIMESTAMP 
>   PATH
> freebsd-r368166 13.0-CURRENT 1300130 r368164 amd64 svn+http 2020-11-30 
> 12:43:46 /usr/local/poudriere/jails/freebsd-r368166

Creation:
poudriere jail -c -j stable -m src=/usr/src

poudriere jail -l
JAILNAME VERSION ARCH  METHOD   TIMESTAMP   PATH
stable   13.2-STABLE 1302507 amd64 src=/usr/src 2023-08-05 15:01:13 
/usr/home/poudriere/jails/stable

Updating:
poudriere jail -u -j stable

Regards,
Michael

Re: poudriere && git

[Matthias Apitz]

El día sábado, agosto 05, 2023 a las 10:08:11a. m. +0200, Kurt Jaeger escribió:

> Hi!
> 
> > In the past I created the jails based on svn, for example with
> > 
> > # poudriere jail  -c -j freebsd-r368166 -m svn+http -v head@r368166
> 
> I have the src repo in /usr/src, build the host system
> from that tree and then use:
> 
> poudriere jail -j head -u -m null -S /usr/src

Hello,

Sure you missed '-c'. i.e. the cmd you wanted is:

poudriere jail -c -j head -m null -S /usr/src

which gives an error:

[00:00:00] Error: Must set -M to path of jail to use

I don't know what to set for the path to -M. The host system is in
/usr/src and /usr/obj.  My old existing jail is:

poudriere jail -l
JAILNAMEVERSION  ARCH  METHOD   TIMESTAMP   
PATH
freebsd-r368166 13.0-CURRENT 1300130 r368164 amd64 svn+http 2020-11-30 12:43:46 
/usr/local/poudriere/jails/freebsd-r368166

Any idea, what should I set? Thanks

matthias

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

Re: unsubscribe

[The Doctor]

On Sun, Aug 06, 2023 at 09:01:42AM +0200, Damon Unric wrote:
> unsubscribe
> 

please do this via the mailman web interface.

-- 
Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b 
An extremist would label a moderate an extremist: know who is lying to you, or 
suffer.  -unknown Beware https://mindspring.com

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

[Konstantin Belousov]

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.

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

[Tomoaki AOKI]

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?

Sorry, I'm just a liaison here and do not have any actual affected
haedware (means that cannot test at all myself).

The reporter claims that the actual hardware is as follows.

 Beelink EQ12 intel N100, 16GB-DDR5,512GB M.2 SSD [4]

Working states are reported as follows.

 Installed to ZFS: OK

 Stock 13.2 without any custom tunalble:
  Crash with UFS

 Tunable vm.pmap.pcid_enabled=0 in /boot/loader.conf:
  No crash reported with situation below.
   *Add "vm.pmap.pcid_enabled=0" on /boot/loader (on installed geom)
just after the installation finished.
   *Reboot to the installed partition.
   *`portsnap fetch extract`
   *`cd /usr/ports/ports-mgmt/portmaster ; make install clean`
   *`portmaster www/apache24`
  And any other operations after above are claimed OK.

 Tunable vm.pmap.pcid_invlpg_workaround=1 instead above:
  Better than stock 13.2, but crashes on `portmaster www/apache24`
  of the procedures above.


[1]
https://lists.freebsd.org/archives/freebsd-users-jp/2023-July/000205.html

[2]
https://www.intel.com/content/www/us/en/products/sku/231803/intel-processor-n100-6m-cache-up-to-3-40-ghz/specifications.html

[3] https://en.wikipedia.org/wiki/Alder_Lake

[4] https://www.bee-link.com/eq12-n100-clone-1-82615581


Regards.

-- 
Tomoaki AOKI

Re: Has the update procedure changed?

[Matthias Apitz]

El día domingo, agosto 06, 2023 a las 01:20:54a. m. -0700, Mark Millard 
escribió:

> 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.

Thanks for the pointers.

During the installation I got the following error:

# make installkernel
...
kldxref /boot/kernel
kldxref: error while reading /boot/kernel/iwlwifi-9000-pu-b0-jf-b0-46.ucode.ko: 
Bad address
kldxref: error while reading /boot/kernel/iwlwifi-9260-th-b0-jf-b0-46.ucode.ko: 
Bad address
kldxref: error while reading /boot/kernel/ktest_netlink_message_writer.ko: Bad 
address

I know the reason (the install process uses the old existing kldxref which does
not can handle some things). I proceeded with the installation and all
is fine, the box is up again in multiuser and /usr/sbin/kldxref is now
from today. Should I run 'make installkernel' a 2nd time?

matthias

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

See bugzilla's 272965 and 272966 for cortex-A7 armv7 example kyua test case panics for main [so: 14], split by backtrace structure

[Mark Millard]

See:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272965
and:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272966

All involve 'Alignment Fault' on read at some point
but the 272966 ones first involve: Kernel page fault with
the following non-sleepable locks held during
in6ifa_ifwithaddr.

The 272965 ones involve udp_input getting the alignment
fault.

These reports are based on using the most recent snapshot
of main [so: 14], not based on my own builds. They do
not involve aarch64 at all: no chroot use, no jail use,
no lib32 existing for the already just-armv7 context.

===
Mark Millard
marklmi at yahoo.com

RE: Has the update procedure changed?

[Mark Millard]

Matthias Apitz  wrote on
Date: Sun, 06 Aug 2023 05:50:36 UTC :

> 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?


https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld
section 26.6.1 lists:

# git pull /usr/src 
check /usr/src/UPDATING 
# cd /usr/src 
# make -j4 buildworld 
# make -j4 kernel 
# shutdown -r now 
# etcupdate -p 
# cd /usr/src 
# make installworld 
# etcupdate -B 
# shutdown -r now  

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.

===
Mark Millard
marklmi at yahoo.com

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

[Oleksandr Kryvulia]

06.08.23 01:35, Graham Perrin пише:

On 05/08/2023 23:16, Graham Perrin wrote:

On 05/08/2023 12:39, Oleksandr Kryvulia wrote:

04.08.23 19:07, Graham Perrin пише:


…



As dirty workaround I have in my /etc/rc.resume

service netif restart
service routing restart


 … 'service routing restart' can be problematic. Please, see, for 
example, ; I had something similar 
a few minutes ago.


After 'service routing restart' (alone), should 'route show default' 
find a route?




Only if you have static route configuration.
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. Another option is to run 'service dhclient restart 
wlan0' after routing restart. I have lagg with em0 and wlan0 - thats why 
I need 'service netif restart' instead.

unsubscribe

[Damon Unric]

unsubscribe

Re: Fwd: Unreliability with DHCP

[Kevin Oberman]

On Sat, Aug 5, 2023 at 3:16 PM Graham Perrin 
wrote:

> On 05/08/2023 12:39, Oleksandr Kryvulia wrote:
> > 04.08.23 19:07, Graham Perrin пише:
> >>
> >> Can anyone from freebsd-net@ help?
> >>
> >>
> >>  Forwarded Message 
> >> Subject: Unreliability with DHCP
> >> Date: Sun, 30 Jul 2023 16:17:43 +0100
> >> From: Graham Perrin 
> >> Organisation: FreeBSD
> >> To: FreeBSD CURRENT 
> >>
> >>
> >>
> >> 1. Sleep (suspend) whilst connected to one network
> >>
> >> 2. connect to a network elsewhere
> >>
> >> 3. wake (resume).
> >>
> >> Result:
> >>
> >> /etc/resolv.conf frequently contains outdated information. In some
> >> (maybe all) such cases, the IPv4 inet address is outdated; and so on.
> >>
> >> Which /etc/rc.d/ file(s) should I attempt to fix?
> >>
> >> I imagine using the resume keyword, which is currently used by only
> >> one script:
> >>
> >> % rcorder -k resume /etc/rc.d/*
> >> /etc/rc.d/ntpd
> >> %
> >>
> >>
> >> I routinely run the command below to work around the bug (and observe
> >> the states of things) – run _after_ the bug bites. I'd prefer a fix,
> >> to prevent the bites.
> >>
> >> ls /var/run/resolvconf/interfaces/ ; route delete default ; ifconfig
> >> wlan0 down && ifconfig em0 down && sleep 5 ; ls
> >> /var/run/resolvconf/interfaces/ ; ifconfig em0 up && sleep 15
> >> ; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; ping -c
> >> 2 -4 freshports.org
> >>
> >
> >
> > As dirty workaround I have in my /etc/rc.resume
> >
> > service netif restart
> > service routing restart
>
>
> Thanks, I'll try when I'm next on campus.
>
> I do know that 'service routing restart' can be problematic. Please,
> see, for example, ; I had something
> similar a few minutes ago.
>

My usual solution is "service netif restart wlan0" (or the interface you
are using). It should restart the interface, if rc.conf calls for it,
dhcpclient and wpa_supplicant (if appropriate).
-- 
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683