Update man page with modern versions.
Details
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Some users have run into an unexpected issue while using freebsd-update
The issue is user error, but hopefully we can add a safety belt to freebsd-update to prevent this type of foot shooting
user has a FreeBSD 9.2-RELEASE-pX system
freebsd-update upgrade -r 9.3-RELEASE
freebsd-update install
reboot
user forgets to install world, and remove old libs
uname -a shows 9.3, user is happy
world is still 9.2
months later, user wants to update from 9.3 to 9.3-p8 to get openssl fixes
freebsd-update fetch
freebsd-update install
now sshd is broken, because it has been upgraded, but libssh has not, so there is no ssh_explicit_bzero etc
Proposed fix: do not allow a 'freebsd-update fetch' again, until they finish the previously pending 'freebsd-update install's required.
Related:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196760
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196771
usr.sbin/freebsd-update/freebsd-update.sh | ||
---|---|---|
685 | This is probably not a smart enough check. We only want to block 'fetch' if there is an in-progress 'upgrade' going on. Where the user has installed a new kernel, but has not finished installing the new world yet. |
Improve the sanity check to look for an installed kernel, so it doesn't trigger if the user has been using 'freebsd-update cron' and just has minor patches pending
Once world is installed, and the oldlibs removal is complete, the -install symlink is renamed -rollback
Updating D1550: Add a sanity check to freebsd-update to disallow a 'fetch' if there are uninstalled upgraded pending
Add a -F parameter to override the new behaviour. This also allows fetch to be run without a tty.
I like the added sanity-check for partially-installed upgrades. But I think disabling the notty check should be a different option, e.g., --not-running-from-cron since otherwise we'll see 1. people complaining that fetch doesn't work from cron, 2. people replying to say "just add -F", 3. networks falling over under synchronized load; whereas --not-running-from-cron is a sufficiently descriptive option name that people *might* think twice before adding that to their cron jobs.
Please do not run
.Nm
from crontab or similar using this flag, see:
.Nm Cm fetch
s/fetch/cron/ ?
Fix manpage typo
Updating D1550: Add a sanity check to freebsd-update to disallow a 'fetch' if there are uninstalled upgraded pending
Add a -F parameter to override the new behaviour. This also allows fetch to be run without a tty.
Latest patch with --not-running-from-cron
looks good to me. @cperciva does it look good to you?
What's the s/-f conffile/-f newrelease/ bit doing in the man page?
I'd put the new options at the end of the list in the SYNOPSYS.
Fix manpage issues identified by cperciva
Updating D1550: Add a sanity check to freebsd-update to disallow a 'fetch' if there are uninstalled upgraded pending
Add a -F parameter to override the new behaviour. This also allows fetch to be run without a tty.
usr.sbin/freebsd-update/freebsd-update.8 | ||
---|---|---|
111 | Hmm, are we endorsing products here? I see the intention to give examples and I use some of these myself. I just want to avoid that similar solutions file PRs wanting to be listed there as well. Maybe we can phrase this less product specific while still making it clear what we mean? |
usr.sbin/freebsd-update/freebsd-update.8 | ||
---|---|---|
111 | There might also be an issue with this page still being around long after the named programs are gone. I can't think of a generic term for them right now, but there should be one. If names are going to be mentioned, they should be capitalized. |
usr.sbin/freebsd-update/freebsd-update.8 | ||
---|---|---|
111 | How about just writing "This is for use by automated tools." for now? This would keep the issue from stalling and we can always add more details to the handbook with concrete examples. |
I agree with @bcr
@allanjude can you implement @bcr's suggestion, and remove all references
to specific automation frameworks in your patch? If you can do that,
and commit this patch that would be great.
As I am only a doc committer, I need an "approved by" from someone with a src bit to commit this. (this signoff from a mentor for the docs part)