Re: etcupdate -p, and other uses of etcupdate(8) (was: Has the update procedure changed?)

2023-08-28 Thread Tomoaki AOKI
On Sun, 27 Aug 2023 18:16:35 +0100
Graham Perrin  wrote:

> On 07/08/2023 16:51, Kevin Oberman wrote:
> > 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."
> >
> > …  "etcupdate -p". …
> 
>  prompted me to 
> look at 
> .
>  
> 
> 
> Is this fortune-provided tip outdated?

For new install with bsdinstall [1] and binary update by
freebsd-update [2], yes. But for src updates, no [3].


[1]
https://lists.freebsd.org/archives/freebsd-current/2023-August/004194.html

[2]
https://lists.freebsd.org/archives/freebsd-current/2023-August/004208.html

[3]
https://lists.freebsd.org/archives/freebsd-current/2023-August/004210.html


-- 
Tomoaki AOKI



etcupdate -p, and other uses of etcupdate(8) (was: Has the update procedure changed?)

2023-08-27 Thread Graham Perrin

On 07/08/2023 16:51, Kevin Oberman wrote:
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."


…  "etcupdate -p". …


 prompted me to 
look at 
. 



Is this fortune-provided tip outdated?




Re: Has the update procedure changed?

2023-08-11 Thread Tomoaki AOKI
On Fri, 11 Aug 2023 15:27:46 +0200
Dag-Erling Smørgrav  wrote:

> Tomoaki AOKI  writes:
> > This can help new installation using release tarballs (official or
> > locally built) or upgrading with overwriting using said tarballs, but
> > how does freebsd-update?
> 
> freebsd-update uses the same release process.
> 
> DES
> -- 
> Dag-Erling Smørgrav - d...@freebsd.org

Ah, thanks!
So just anyone running through source update like us are possibly
bitten.

-- 
Tomoaki AOKI



Re: Has the update procedure changed?

2023-08-11 Thread Dag-Erling Smørgrav
Tomoaki AOKI  writes:
> This can help new installation using release tarballs (official or
> locally built) or upgrading with overwriting using said tarballs, but
> how does freebsd-update?

freebsd-update uses the same release process.

DES
-- 
Dag-Erling Smørgrav - d...@freebsd.org



Re: Has the update procedure changed?

2023-08-10 Thread Tomoaki AOKI
On Thu, 10 Aug 2023 16:08:26 +0200
Dag-Erling Smørgrav  wrote:

> Tomoaki AOKI  writes:
> > Yes. But if bsdinstall and freebsd-update automatically bootstrap
> > etcupdate if not yet done, newbies and casual users wouldn't be bitten.
> 
> https://cgit.freebsd.org/src/commit/?id=e9120a256075543376496fbd75949eed1f13a887
> 
> DES
> -- 
> Dag-Erling Smørgrav - d...@freebsd.org

Oh, thanks! I've completely missed it when landed.

This can help new installation using release tarballs (official or
locally built) or upgrading with overwriting using said tarballs, but
how does freebsd-update? I'm not enough familiar with how
freebsd-update upgrades base.

-- 
Tomoaki AOKI



Re: Has the update procedure changed?

2023-08-10 Thread Tomoaki AOKI
On Thu, 10 Aug 2023 03:15:43 -0700 (PDT)
"Jeffrey Bouquet"  wrote:

> On Thu, 10 Aug 2023 06:32:14 +0900, Tomoaki AOKI  
> wrote:
> 
> > On Wed, 9 Aug 2023 05:50:05 -0700
> > David Wolfskill  wrote:
> > 
> > > On Wed, Aug 09, 2023 at 09:38:22PM +0900, Tomoaki AOKI wrote:
> > > > ...
> > > > 
> > > > Please correct me if I'm missing something.
> > > > I use source update for years and not using bsdinstall nor
> > > > freebsd-update.
> > > > 
> > > > Does bsdinstall (and/or freebsd-update) create the first current tree
> > > > for etcupdate, if not yet exists?
> > > > 
> > > > This would be most confusing and harmful point of etcupdate.
> > > > When I first tried etcupdate, I didn't noticed that I needed
> > > > `etcupdate extract -B` BEFORE UPDATING src tree.
> > > > Without this, etcupdate cannot detect what should be updated, even if a
> > > > plenty of updates are required.
> > > > 
> > > > At the moment, I must use mergemaster, and after that, `etcupdate
> > > > extract -B` for next run.
> > > > 
> > > > I think bsdinstall can create current tree, which is turned over to old
> > > > tree on actual run, for etcupdate.
> > > > So do freebsd-update. It would be able to create current tree JUST
> > > > BEFORE INSTALLING UPDATE.
> > > > 
> > > > I was helped by mergemaster, but after it completely retires, features
> > > > above should be mandatory.
> > > > 
> > > 
> > > TL;DR: Please see the "Bootstrapping" section of etcupdate(8).
> > 
> > I know. ;-) I'm using etcupdate when it first MFC'ed to latest stable
> > branch ATM, and bitten at the first time.
> > 
> > Anyone not familiar with etcupdate would bitten by forgotton
> > bootstrapping. :-(
> > 
> > 
> > > Details: I have been doing source-based updates of FreeBSD since around
> > > 1999.  As such, I used mergemaster for a long time, and got used to it.
> > > 
> > > With the switch to git, the $FreeBSD$ lines in config files became ...
> > > well, misleading noise.  And since mergemaster tried to use them, that
> > > didn't work very well.  This provided the incentive I needed to switch
> > > to etcupdate.
> > > 
> > > And... yeah; there was a "learning curve."  And the "bootstrapping" bit
> > > is necessary.  But it has worked well for me since.
> > 
> > Yes. But if bsdinstall and freebsd-update automatically bootstrap
> > etcupdate if not yet done, newbies and casual users wouldn't be bitten.
> > 
> > For source-based update users like us,
> > 
> >  *Bootstrapping section of man page should be near the top,
> >   for example, betweem DESCRIPTION and MODES section, not inside
> >   EXAMPLES section.
> > 
> >  *Also documented in UPDATING (or new document for common instructions)
> >   and handbook.
> > 
> > should be needed.
> > etcupdate cannot extract old tree from already-updated src.
> > So anyone forgotton bootstrapping is forced to roll back src for
> > bootstrapping and roll forward again BEFORE installworld, once
> > mergemaster dissapears.
> > 
> > > 
> > > Peace,
> > > david
> > > -- 
> > > David H. Wolfskill  da...@catwhisker.org
> > > Given Trump's claims about fairness in elections, his notion of a
> > > "fair trial" is almost certainly at variance with objective reality.
> > > 
> > > See https://www.catwhisker.org/~david/publickey.gpg for my public key.
> > 
> > 
> > -- 
> > Tomoaki AOKI
> 
> 
> Say 3/5 of FreeBSD installs have not used etcupdate yet, and for those they 
> are 
> less likely to encounter problems [ at least in my experience ] because 
> mergemaster
> has always be intuitive, an either-or choice at each menu, near zero chance of
> PBKAC, would it not make sense to keep mergemaster around slightly modified,
> for instance, with a new section of code that would prepare the result for 
> "now the next time /etc is updated, use only etcupdate THIS WAY".   
> alternately,
> upgrade etcupdate to be VERY verbose in its threeway merge so that 
> 1... version A of file is in /etc, version B of file is in /var/???, desired 
> version
>  of file is in /var/??? or /usr/src/??? user's and legacy items in the 
> /etc
> version are ... ;  ... ; ... ' 
>menu a) leave this file alone, please edit it manually to  
>  b) install ... file, you will edit it before reboot. 
>  c) 
>   more of an intuitive mergemaster - menu alike.
> .
> My uses of etcupdate have left files clobbered, which I had to replace from 
> backup, and then continue to use mergemaster.  I intend thus to keep a
> copy of  it seperate from the src tree for use forever, I'm old...

des@ told me that newbies should not be bitten by etcupdate in another
post. It's what I've missed when landed.

But upgrading from old installation with freebsd-update is still unclear
and so does source updating. For these, letting mergemaster warn for
etcupdate seems to be a good idea. But asking "Do you want to use
etcupdate next time? (y/N)" after successful merge (or resolved
conflicts), and if answerd 

Re: Has the update procedure changed?

2023-08-10 Thread Dag-Erling Smørgrav
Tomoaki AOKI  writes:
> Yes. But if bsdinstall and freebsd-update automatically bootstrap
> etcupdate if not yet done, newbies and casual users wouldn't be bitten.

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

DES
-- 
Dag-Erling Smørgrav - d...@freebsd.org



Re: Has the update procedure changed?

2023-08-09 Thread Tomoaki AOKI
On Wed, 9 Aug 2023 05:50:05 -0700
David Wolfskill  wrote:

> On Wed, Aug 09, 2023 at 09:38:22PM +0900, Tomoaki AOKI wrote:
> > ...
> > 
> > Please correct me if I'm missing something.
> > I use source update for years and not using bsdinstall nor
> > freebsd-update.
> > 
> > Does bsdinstall (and/or freebsd-update) create the first current tree
> > for etcupdate, if not yet exists?
> > 
> > This would be most confusing and harmful point of etcupdate.
> > When I first tried etcupdate, I didn't noticed that I needed
> > `etcupdate extract -B` BEFORE UPDATING src tree.
> > Without this, etcupdate cannot detect what should be updated, even if a
> > plenty of updates are required.
> > 
> > At the moment, I must use mergemaster, and after that, `etcupdate
> > extract -B` for next run.
> > 
> > I think bsdinstall can create current tree, which is turned over to old
> > tree on actual run, for etcupdate.
> > So do freebsd-update. It would be able to create current tree JUST
> > BEFORE INSTALLING UPDATE.
> > 
> > I was helped by mergemaster, but after it completely retires, features
> > above should be mandatory.
> > 
> 
> TL;DR: Please see the "Bootstrapping" section of etcupdate(8).

I know. ;-) I'm using etcupdate when it first MFC'ed to latest stable
branch ATM, and bitten at the first time.

Anyone not familiar with etcupdate would bitten by forgotton
bootstrapping. :-(


> Details: I have been doing source-based updates of FreeBSD since around
> 1999.  As such, I used mergemaster for a long time, and got used to it.
> 
> With the switch to git, the $FreeBSD$ lines in config files became ...
> well, misleading noise.  And since mergemaster tried to use them, that
> didn't work very well.  This provided the incentive I needed to switch
> to etcupdate.
> 
> And... yeah; there was a "learning curve."  And the "bootstrapping" bit
> is necessary.  But it has worked well for me since.

Yes. But if bsdinstall and freebsd-update automatically bootstrap
etcupdate if not yet done, newbies and casual users wouldn't be bitten.

For source-based update users like us,

 *Bootstrapping section of man page should be near the top,
  for example, betweem DESCRIPTION and MODES section, not inside
  EXAMPLES section.

 *Also documented in UPDATING (or new document for common instructions)
  and handbook.

should be needed.
etcupdate cannot extract old tree from already-updated src.
So anyone forgotton bootstrapping is forced to roll back src for
bootstrapping and roll forward again BEFORE installworld, once
mergemaster dissapears.

> 
> Peace,
> david
> -- 
> David H. Wolfskill  da...@catwhisker.org
> Given Trump's claims about fairness in elections, his notion of a
> "fair trial" is almost certainly at variance with objective reality.
> 
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.


-- 
Tomoaki AOKI



Re: Has the update procedure changed?

2023-08-09 Thread Tomoaki AOKI
On Tue, 8 Aug 2023 23:22:32 -0700
Kevin Oberman  wrote:

> On Mon, Aug 7, 2023 at 9:12 AM Matthias Apitz  wrote:
> 
> > 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.
> >
> "
> 
> >
> > 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
> >
> 
> etcupdate is the successor to mergemaster.  It is vastly better, but does
> have a learning curve when you first start using it. Also, it has quite a
> few commands that are seldom needed and I think that intimidates people a
> bit. Unless you understand a three-way merge, it is confusing. It's not
> complicated, but different from mergemster. (freebsd-update always has done
> a three-way merge.)
> 
> I don't see how you get this from the man page.
> "Compares only files known to be
>  essential to the success of {build|install}world, i.e.,
>  /etc/group and /etc/master.passwd.
> 
> If it is potentially updating files that MIGHT be essential to a successful
> buildworld, running it after buildkernel seems quite wrong. At least I read
> {build|install}world as buildworld or installworld.
> 
> -- 
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

Please correct me if I'm missing something.
I use source update for years and not using bsdinstall nor
freebsd-update.

Does bsdinstall (and/or freebsd-update) create the first current tree
for etcupdate, if not yet exists?

This would be most confusing and harmful point of etcupdate.
When I first tried etcupdate, I didn't noticed that I needed
`etcupdate extract -B` BEFORE UPDATING src tree.
Without this, etcupdate cannot detect what should be updated, even if a
plenty of updates are required.

At the moment, I must use mergemaster, and after that, `etcupdate
extract -B` for next run.

I think bsdinstall can create current tree, which is turned over to old
tree on actual run, for etcupdate.
So do freebsd-update. It would be able to create current tree JUST
BEFORE INSTALLING UPDATE.

I was helped by mergemaster, but after it completely retires, features
above should be mandatory.

-- 
Tomoaki AOKI



Re: Has the update procedure changed?

2023-08-09 Thread Matthias Apitz
El día miércoles, agosto 09, 2023 a las 12:40:31 +0200, Miroslav Lachman 
escribió:

> On 09/08/2023 08:22, Kevin Oberman wrote:
> 
> > I don't see how you get this from the man page.
> > "Compares only files known to be
> >                   essential to the success of {build|install}world, i.e.,
> >                   /etc/group and /etc/master.passwd.
> > 
> > If it is potentially updating files that MIGHT be essential to a
> > successful buildworld, running it after buildkernel seems quite wrong.
> > At least I read {build|install}world as buildworld or installworld.
> 
> Correct me if I am wrong but AFAIK etcupdate -p (or mergemaster -p) updates
> entries in [master.]passwd and group which are only needed to install new
> files with the right owner and group set, not to build these files.
> (installkernel installs everything ass root:wheel)
> 
> Also Makefile contains this steps where mergemaster -p should be run after
> installkernel and reboot:
> 
> 2.  `make buildworld'
> 3.  `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
> 4.  `make installkernel KERNCONF=YOUR_KERNEL_HERE'   (default is GENERIC).
>  [steps 3. & 4. can be combined by using the "kernel" target]
> 5.  `reboot'(in single user mode: boot -s from the loader prompt).
> 6.  `mergemaster -p'
> 7.  `make installworld'
> 
> 
> And man page for etcpupdate -p has this:
> 
> -p  Enable “pre-world” mode.  Only merge changes to files
>   that are necessary to successfully run ‘make
>   installworld’ or ‘make installkernel

Yes, exactly. Running mergemaster -p or (etcupdate -p) before 'make buildworld'
does not make any sense. 

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?

2023-08-09 Thread Miroslav Lachman

On 09/08/2023 08:22, Kevin Oberman wrote:


I don't see how you get this from the man page.
"Compares only files known to be
                  essential to the success of {build|install}world, i.e.,
                  /etc/group and /etc/master.passwd.

If it is potentially updating files that MIGHT be essential to a 
successful buildworld, running it after buildkernel seems quite wrong. 
At least I read {build|install}world as buildworld or installworld.


Correct me if I am wrong but AFAIK etcupdate -p (or mergemaster -p) 
updates entries in [master.]passwd and group which are only needed to 
install new files with the right owner and group set, not to build these 
files. (installkernel installs everything ass root:wheel)


Also Makefile contains this steps where mergemaster -p should be run 
after installkernel and reboot:


2.  `make buildworld'
3.  `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
4.  `make installkernel KERNCONF=YOUR_KERNEL_HERE'   (default is GENERIC).
 [steps 3. & 4. can be combined by using the "kernel" target]
5.  `reboot'(in single user mode: boot -s from the loader prompt).
6.  `mergemaster -p'
7.  `make installworld'


And man page for etcpupdate -p has this:

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


Kind regards
Miroslav Lachman





Re: Has the update procedure changed?

2023-08-09 Thread Kevin Oberman
On Mon, Aug 7, 2023 at 9:12 AM Matthias Apitz  wrote:

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

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

etcupdate is the successor to mergemaster.  It is vastly better, but does
have a learning curve when you first start using it. Also, it has quite a
few commands that are seldom needed and I think that intimidates people a
bit. Unless you understand a three-way merge, it is confusing. It's not
complicated, but different from mergemster. (freebsd-update always has done
a three-way merge.)

I don't see how you get this from the man page.
"Compares only files known to be
 essential to the success of {build|install}world, i.e.,
 /etc/group and /etc/master.passwd.

If it is potentially updating files that MIGHT be essential to a successful
buildworld, running it after buildkernel seems quite wrong. At least I read
{build|install}world as buildworld or installworld.

-- 
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


Re: Has the update procedure changed?

2023-08-08 Thread Dag-Erling Smørgrav
Matthias Apitz  writes:
> 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?

'make reinstallkernel' is more appropriate in this case.

DES
-- 
Dag-Erling Smørgrav - d...@freebsd.org



Re: Has the update procedure changed?

2023-08-08 Thread Graham Perrin

On 06/08/2023 09:20, Mark Millard wrote:


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


IMHO a summary should not omit any step that is _essential_.

etcupdate -B is non-optional.




OpenPGP_signature
Description: OpenPGP digital signature


Re: Has the update procedure changed?

2023-08-08 Thread Graham Perrin

On 08/08/2023 03:50, Robert Huff wrote:


…

1) It would be really nice is someone would take a look and make
sure these 100% non-contradictory.

…


Looks by people should, ideally, include:


209744 – Move installation instructions from UPDATING to new file


256830 – the COMMON ITEMS: section in /usr/src/UPDATING makes no mention 
of etcupdate


… plus the discussion, which I can't find (I thought it was a BR), about 
disorderly numbering; and so on.




OpenPGP_signature
Description: OpenPGP digital signature


Re: Has the update procedure changed?

2023-08-07 Thread 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?

2023-08-07 Thread 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: Has the update procedure changed?

2023-08-07 Thread 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?

2023-08-07 Thread 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: Has the update procedure changed?

2023-08-06 Thread 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

Re: Has the update procedure changed?

2023-08-06 Thread 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: Has the update procedure changed?

2023-08-06 Thread 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



RE: Has the update procedure changed?

2023-08-06 Thread 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




Has the update procedure changed?

2023-08-05 Thread Matthias Apitz
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