Review D28062 of /usr/src/UPDATING with regard to upgrading FreeBSD and inconsistency with the FreeBSD Handbook

[Graham Perrin]

1)

<https://reviews.freebsd.org/D28062#change-5KzY5tEtVUor> lines 2273 and 2275

With ZFS in the mix, /usr/src is present but empty (the file system is
not mounted).

If single user mode is recommended, then why is this not in the FreeBSD
Handbook?
<https://cgit.freebsd.org/doc/tree/documentation/content/en/books/handbook/cutting-edge/_index.adoc?id=84d56d3868a699c64c51d7453cedab0f3468ba03#n620>

2)

<https://reviews.freebsd.org/D28062#change-5KzY5tEtVUor> line 2274

etcupdate -p

No previous tree to compare against, a sane comparison is not possible.

<https://photos.app.goo.gl/3a64FfsNkGUTPj1XA>

In the past I simply ran etcupdate after make installworld.

If etcupdate -p fails before make installworld, then should the
subsequent etcupdate be with or without option -B ?

[d***@gmail.com]

-----Original Message-----
Sent: Saturday, 17 April 2021 21:52
Subject: Review D28062 of /usr/src/UPDATING with regard to upgrading
FreeBSD and inconsistency with the FreeBSD Handbook
1)
<https://reviews.freebsd.org/D28062#change-5KzY5tEtVUor> lines 2273 and 2275
With ZFS in the mix, /usr/src is present but empty (the file system is not
mounted).

See [3] a bit lower in the file at 2341. (cherry picked)
- mount -u /, to mount the root as rw so that you can installworld on it.
- sh /etc/rc.d/zfs start to mount all other datasets such as /usr/src, comes
down to "service zfs start"

If single user mode is recommended, then why is this not in the FreeBSD
Handbook?
<https://cgit.freebsd.org/doc/tree/documentation/content/en/books/handbo
ok/cutting-
edge/_index.adoc?id=84d56d3868a699c64c51d7453cedab0f3468ba03#n620>

Speaking of my own experience, I have not had any trouble doing source
installs on the fly (not in single user mode)
Altough, these mostly deal with STABLE/CURRENT branches and I can't comment
on why it is recommended (probably just the safer route for .so bumps).

2)
<https://reviews.freebsd.org/D28062#change-5KzY5tEtVUor> line 2274
etcupdate -p

No previous tree to compare against, a sane comparison is not possible.

<https://photos.app.goo.gl/3a64FfsNkGUTPj1XA>
In the past I simply ran etcupdate after make installworld.

Thats fine as long as there are no changes that could impact the
installworld process, like an extra user that might be added (ntpd most
recent), these are scarce though and you will typically notice pretty
quickly as the installworld process will fail in some sort of way.
I'm uncertain why it cannot compare to a previous tree, for me it gives no
output which means its fine.
Do you get normal output from "etcupdate diff"?

If etcupdate -p fails before make installworld, then should the subsequent
etcupdate be with or without option -B ?

-p and -B are not related.

-p deals with changes needed for a correct run of installworld (see above).

-B uses a freshly built world to speed up the tree comparison; although no
flags work fine here as well, so -B is not necessarily required.

_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

[Graham Perrin]

1)
<https://reviews.freebsd.org/D28062#change-5KzY5tEtVUor> lines 2273 and
2275
With ZFS in the mix, /usr/src is present but empty (the file system is not
mounted).

See [3] a bit lower in the file at 2341. … comes down to "service zfs start"

Thank you!

I commented on the disorder but hadn't paid attention to the _content_
of footnotes. My bad.

I habitually `mount -uw /`.

Never thought to run service in single user mode, I'll know for next time.

[John Baldwin]

Post by d***@gmail.com

If etcupdate -p fails before make installworld, then should the subsequent
etcupdate be with or without option -B ?

-p and -B are not related.
-p deals with changes needed for a correct run of installworld (see above).
-B uses a freshly built world to speed up the tree comparison; although no
flags work fine here as well, so -B is not necessarily required.

Technically -B speeds up generating the tree to compare against as it assumes
/usr/obj is up to date and uses that instead of rebuilding some files
generated by buildworld normally. The actual tree comparison isn't affected.

[John Baldwin]

Post by Graham Perrin
2)
<https://reviews.freebsd.org/D28062#change-5KzY5tEtVUor> line 2274
etcupdate -p

No previous tree to compare against, a sane comparison is not possible.

Hmm, how did you initially install this machine? Release images should
generally include a pre-populated /var/db/etcupdate so that etcupdate
works. If you don't have one of those, you will have to perform an
initial bootstrap of etcupdate (only once) by running 'etcupdate extract'.
If you do this before you update /usr/src then 'etcupdate' will later
work fine. If you are doing this after you have already updated
/usr/src, you will need to run 'etcupdate diff' after 'etcupdate extract'
and fix any unexpected local differences in the generated patch, e.g.
by copying files from /var/db/etcupdate/current/etc to /etc. Once
you have done this, 'etcupdate' will work fine on the next upgrade.

However, I'm curious how you didn't get the etcupdate bootstrap when
you initially installed.

[Graham Perrin]

Post by Graham Perrin
2)
<https://reviews.freebsd.org/D28062#change-5KzY5tEtVUor> line 2274
etcupdate -p
  > No previous tree to compare against, a sane comparison is not
possible.

Hmm, how did you initially install this machine?  Release images should
generally include a pre-populated /var/db/etcupdate so that etcupdate
works.  If you don't have one of those, you will have to perform an
initial bootstrap of etcupdate (only once) by running 'etcupdate extract'.
If you do this before you update /usr/src then 'etcupdate' will later
work fine.  If you are doing this after you have already updated
/usr/src, you will need to run 'etcupdate diff' after 'etcupdate extract'
and fix any unexpected local differences in the generated patch, e.g.
by copying files from /var/db/etcupdate/current/etc to /etc.  Once
you have done this, 'etcupdate' will work fine on the next upgrade.
However, I'm curious how you didn't get the etcupdate bootstrap when
you initially installed.

Sorry for not replying sooner.

It's not an answer to your question, but might the thread at
<https://lists.freebsd.org/pipermail/freebsd-current/2021-April/079538.html>
be relevant?

[John Baldwin]

Post by Graham Perrin

Post by Graham Perrin
2)
<https://reviews.freebsd.org/D28062#change-5KzY5tEtVUor> line 2274
etcupdate -p
  > No previous tree to compare against, a sane comparison is not
possible.

Hmm, how did you initially install this machine?  Release images should
generally include a pre-populated /var/db/etcupdate so that etcupdate
works.  If you don't have one of those, you will have to perform an
initial bootstrap of etcupdate (only once) by running 'etcupdate extract'.
If you do this before you update /usr/src then 'etcupdate' will later
work fine.  If you are doing this after you have already updated
/usr/src, you will need to run 'etcupdate diff' after 'etcupdate extract'
and fix any unexpected local differences in the generated patch, e.g.
by copying files from /var/db/etcupdate/current/etc to /etc.  Once
you have done this, 'etcupdate' will work fine on the next upgrade.
However, I'm curious how you didn't get the etcupdate bootstrap when
you initially installed.

Sorry for not replying sooner.
It's not an answer to your question, but might the thread at
<https://lists.freebsd.org/pipermail/freebsd-current/2021-April/079538.html>
be relevant?

Yes, you might indeed have hit this bug (which has since been fixed).
You might have to 'etcupdate extract' and then manually review
'etcupdate diff' to see if you have any unexpected diffs to recover.
Sorry. :-/