Solved Which commands should I use to update FreeBSD?

Relricey

Relricey

Hi.

This is my first post. The forum is beautiful.

Which is better? Or is there another better method to update/upgrade?

Is there duplication/overlap in these commands?

Code: 
freebsd-update fetch && freebsd-update fetch install

or

Code: 
freebsd-update fetch && pkg update && pkg upgrade

or

Code: 
freebsd-update fetch && freebsd-update fetch install && pkg update && pkg upgrade

Thanks.
 
Let's discuss some fundamentals. To begin with: Read the handbook.

First: You are using a RELEASE version of FreeBSD, right? Because freebsd-update only works on release versions. Those are the production versions, intended for normal users. There are also versions that are called CURRENT and STABLE. Those are intended for people who want to alpha- and beta-test unreleased versions; they are not supported in this forum, and they are not for the faint of heart.

Second: You need to learn about the distinction between the FreeBSD base OS, and its packages. The base OS contains everything that you need for a self-hosting (meaning it can compile itself) and command-line based (meaning no GUI, no graphics or windowing) operating system. The base OS is updated using freebsd-update. The base OS changes version numbers when it is upgraded. Version numbers consist of the major number (for example 12), minor number (for example 3), and patch level (for example p2): I'm running 12.3p2 on my machine. The freebsd-update process (using fetch and install) you describe above will automatically go from patch to patch, but will not go across major or minor versions. To upgrade to the next major/minor version, you need to add the -R switch to the command.

And: If your upgrade includes the kernel, you need to reboot to switch to the new kernel. One good way to find out whether a reboot is required: Use the command freebsd-version (read its man page). After a reboot, I would rerun "freebsd-update install", just to make sure the update actually finished. There are updates where you have to reboot and restart the update, the messages will tell you, but you might forget to read the messages.

The packages (also known as ports) are distinct from the base OS. They don't have versions or releases, and get updated on individual schedules. Some packages are version locked, you can mostly ignore that. You can run package update/upgrade independent from freebsd-update.

You are showing a command line that has all the commands in one line. Which is also what Menelkir suggested with "freebsd-update fetch install" Personally, I don't do that. I run one command at a time, and look at the output. That's because the following commands may generate lots and lots of output, which will get buried if you run more commands. Similarly, I don't chain multiple commands in one line with "command1 && command2 && ...", again I want to see what happened before going the next step.

Did I mention reading the handbook? There is a really good chapter about this, which includes a discussion of packages versus ports (they are the same, but very different, read the book).
 
ralphbsz said:
Let's discuss some fundamentals. To begin with: Read the handbook.

First: You are using a RELEASE version of FreeBSD, right? Because freebsd-update only works on release versions. Those are the production versions, intended for normal users. There are also versions that are called CURRENT and STABLE. Those are intended for people who want to alpha- and beta-test unreleased versions; they are not supported in this forum, and they are not for the faint of heart.

Second: You need to learn about the distinction between the FreeBSD base OS, and its packages. The base OS contains everything that you need for a self-hosting (meaning it can compile itself) and command-line based (meaning no GUI, no graphics or windowing) operating system. The base OS is updated using freebsd-update. The base OS changes version numbers when it is upgraded. Version numbers consist of the major number (for example 12), minor number (for example 3), and patch level (for example p2): I'm running 12.3p2 on my machine. The freebsd-update process (using fetch and install) you describe above will automatically go from patch to patch, but will not go across major or minor versions. To upgrade to the next major/minor version, you need to add the -R switch to the command.

And: If your upgrade includes the kernel, you need to reboot to switch to the new kernel. One good way to find out whether a reboot is required: Use the command freebsd-version (read its man page). After a reboot, I would rerun "freebsd-update install", just to make sure the update actually finished. There are updates where you have to reboot and restart the update, the messages will tell you, but you might forget to read the messages.

The packages (also known as ports) are distinct from the base OS. They don't have versions or releases, and get updated on individual schedules. Some packages are version locked, you can mostly ignore that. You can run package update/upgrade independent from freebsd-update.

You are showing a command line that has all the commands in one line. Which is also what Menelkir suggested with "freebsd-update fetch install" Personally, I don't do that. I run one command at a time, and look at the output. That's because the following commands may generate lots and lots of output, which will get buried if you run more commands. Similarly, I don't chain multiple commands in one line with "command1 && command2 && ...", again I want to see what happened before going the next step.

Did I mention reading the handbook? There is a really good chapter about this, which includes a discussion of packages versus ports (they are the same, but very different, read the book).
Click to expand...

My understanding is that STABLE is supported by this forum, whereas CURRENT is not.

... If you want support on these forums, run either a supported version of the -RELEASE branch (for proven, stable, solid installations) or of the -STABLE branch (a slightly more experimental, but still very stable version that incorporates some of the newer developments of the -CURRENT branch).
Click to expand...
Reference: Thread topics-about-unsupported-freebsd-versions.40469
 
Relricey welcome to FreeBSD Forums. Can you tell us which version you installed?

freebsd-version -kru ; uname -aKU

Where freebsd-update(8) runs on a version of FreeBSD that's not compatible, there'll be a simple on-screen message about compatibility (it will neither fetch nor update).

Hint: <https://forums.freebsd.org/help/bb-codes/#cmd> to format a command; <https://forums.freebsd.org/help/bb-codes/#code>, which you already used, will be good to format the output from a command.


hbsd please note,

Menelkir said:
don't need to update first.
Click to expand...

pkg-upgrade(8)
 
For clarification: STABLE is supported on these forums, but won't work with freebsd-update. Using freebsd-update only works with RELEASE versions.
 
Further clarification: pkg upgrade will not obviate the need to run freebsd-update. I just tested for this because I was in some doubt about it.

Before pkg upgrade:
Code: 
root@mlatest:~ # freebsd-version -kru
13.0-RELEASE-p4
13.0-RELEASE-p4
13.0-RELEASE-p5

After pkg upgrade:
Code: 
root@mlatest:~ # freebsd-version -kru
13.0-RELEASE-p4
13.0-RELEASE-p4
13.0-RELEASE-p5

After freebsd-update fetch && freebsd-update install:
Code: 
root@mlatest:~ # freebsd-version -kru
13.0-RELEASE-p7
13.0-RELEASE-p4
13.0-RELEASE-p7

I shall now reboot in order to load the new kernel. After rebooting, this will be the expected result:
Code: 
root@mlatest:~ # freebsd-version -kru
13.0-RELEASE-p7
13.0-RELEASE-p7
13.0-RELEASE-p7

Edited to add: It is not necessary to run pkg update before running pkg upgrade because the upgrade will automatically do the update for you.
 
eternal_noob said:
So why does pkg update even exist? Are there use cases?
Click to expand...

Good question, but the answer to your question is right there in the manual.

It is best practice to ensure your package repository catalogues are up
to date before doing any package installation (via pkg-install(8)) or
upgrades (via pkg-upgrade(8)). However, explicitly running pkg update is
not normally necessary. By default invoking either of pkg install or pkg
upgrade will cause repository catalogues to be updated automatically,
unless disabled by setting REPO_AUTOUPDATE to false in pkg.conf(5).
Click to expand...

On-line reference: pkg-update(8)

Command line reference: man pkg-update
 
eternal_noob said:
Why would one disable REPO_AUTOUPDATE?

Seems like a typical feature creep to me:
Add a useless option and a command to counteract that option.
Click to expand...
I'm sure there are some very good reasons. Some people maintain their own repositories, and it's probably very useful for them to have that kind of fine-grained control. There are many different use cases that are way outside my experience. I'm just a simple guy, who needs very little in the way of special accommodations, but FreeBSD doesn't exist just to serve MY needs. It serves a LOT of specialized purposes.
 
eternal_noob said:
I am tempted to create a poll and ask if anyone uses that option.
Click to expand...
I tend to doubt that the kinds of people who might use that option would answer such a poll. They might very likely not even read such a poll. They might not even read this forum at all. I used FreeBSD for close to 20 years before I even knew this forum existed.

If you want to start a poll, I'm thinking you should probably do it on the off-topic sub-forum.
 
No feelings hurt here.

eternal_noob said:
… why does pkg update even exist? Are there use cases?
Click to expand...

I'm a very frequent user.

grahamperrin said:
sensible use of ZFS boot environments
Click to expand...

More specifically:
  1. pkg update to tell whether any upgrade is applicable.
If an upgrade is applicable, be sensible:
  1. create a new boot environment
  2. activate the environment
  3. boot the environment
  4. upgrade
?– those four steps are the essence of it.

In reality: I often perform additional steps, for a quicker end result, but I'll not go into that level of detail here.
 
eternal_noob said:
No worries i am fine. I just wondered what you wanted to say with
Click to expand...
Developers for instance don't have time for the forum, and communicate via the mailing lists, or so I've read in other threads here. Makes sense to me. I'm retired now, but in my years of staying up late nights working on software development, I often had very little time for anything else, including sleep sometimes.

I imagine devs might also tweak the REPO_AUTOUPDATE setting and other settings just so that they can use more than one repo at a time in their own testing environments, and for comparison purposes. I do that myself sometimes, but I do it using pkg fetch and pkg add to build my own repos on disk, rather than using network repos.

That's just a little wild guesswork on my part though, because I really don't know much about what the FreeBSD devs do. Haven't looked at any of it, or these settings, too closely. I just use the RELEASE versions myself, and keep older, well-tested software versions for my own use, until I've had a chance to test the newer versions on separate test systems. I also keep separate repos for tried and true latest vs. quarterly package systems. In the past I kept different repos for 11.2 and 12.0 (for example), but now I keep it simple by doing everything on 13.0-RELEASE.
 
Vull said:
Developers for instance don't have time for the forum, and communicate via the mailing lists, or so I've read in other threads here. Makes sense to me. …
Click to expand...

For what I use (on FreeBSD 14.0-CURRENT) there are no human posts to the list, so far, this month. Last month, a minority of subjects (three or four) from humans, one of the human topic starters is also present as a developer in FreeBSD Forums. With this list, the vast majority of e-mails are automated.

Human developer activity is much more noticeable elsewhere, it's probably fair to say that realtime collaboration is preferred.

www.freebsd.org

Community

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
www.freebsd.org www.freebsd.org
 
Tux2bsd brings up a good point. Ideally, the best practice would be to run both freebsd-update and pkg upgrade very regularly, for example once a day. That could be automated, for example in a nightly cron job. The problem is that (as I said above), some people are too paranoid to allow upgrades to actually run unsupervised. For those people, the automated phase would be to fetch updates only, and to notify the admin when to manually run the actual upgrades. That would also solve the problem of how to know when the system needs to be rebooted to get an updated kernel started. A similar question is: When do daemons and services need to be restarted? I don't know of an automated solution that determines this from pkg upgrades (it may very well exist).

If one downloads or at least performs automated upgrades regularly (like once a day), their performance starts to matter.
 
ralphbsz said:
A similar question is: When do daemons and services need to be restarted?
Click to expand...
checkrestart

ralphbsz said:
fetch updates only, and to notify the admin
Click to expand...
man freebsd-update in short freebsd-update cron

The most important point I made was that freebsd-update is inefficient. Run freebsd-update fetch two times back to back, the problem is very plain to see (hint, the 2nd run should take a second or two). The mirrors that freebsd-update hits are slow changing, that means if you checked once per day it does not need perform that whole subsequent run it just needs to say "nothing new" and then when there is something new it can dive into the "Inspecting system" stuff. I solved that part, https://reviews.freebsd.org/D32570 , but freebsd-update has some spaghetti that prevents a simple fix to an otherwise simple problem.
 
Make a backup of your PostgreSQL database before running pkg upgrade if you have PostgreSQL server installed, or it might wipe out your PG database, especially during a major version upgrade. I would do the same when I was running MySQL server software, and would also do the same for any other SQL server.

Oddly, and rather unhelpfully in my humble opinion, the upgrade will WARN you to do this, but only AFTER it might already be too late to do it:
Code: 
[75/95] Upgrading postgresql13-server from 13.5 to 13.6...
===> Creating groups.
Using existing group 'postgres'.
===> Creating users
Using existing user 'postgres'.
===> Creating homedir(s)

  =========== BACKUP YOUR DATA! =============
  As always, backup your data before
  upgrading. If the upgrade leads to a higher
  major revision (e.g. 9.6 -> 10), a dump
  and restore of all databases is
  required. This is *NOT* done by the port!
  See https://www.postgresql.org/docs/current/upgrading.html
  ===========================================
[75/95] Extracting postgresql13-server-13.6: .......... done
 
You must log in or register to reply here.
Back
Top