How to use Git Large File Storage (git-lfs)

While working on updating my website recently I noticed this message when doing a “git push”.
> git push
Counting objects: 20, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (20/20), done.
Writing objects: 100% (20/20), 92.49 MiB | 1.10 MiB/s, done.
Total 20 (delta 6), reused 0 (delta 0)
remote: Resolving deltas: 100% (6/6), completed with 5 local objects.
remote: warning: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com.
remote: warning: See http://git.io/iEPt8g for more information.
remote: warning: File includes/images/computers/builds/2004/VID_20170918_174906.mp4 is 67.53 MB; this is larger than GitHub's recommended maximum file size of 50.00 MB
To github.com:dsdickinson/codeuniversity.git
4c8f617..1f2b31a master -> master

 

I knew this would be a concern but hadn’t had to address it as of yet. So I decided to do some research on git-lfs to get familiar with it. These links were helpful:
https://git-lfs.github.com
https://www.youtube.com/watch?v=uLR1RNqJ1Mw
https://help.github.com/en/github/managing-large-files/versioning-large-files

Installation
> brew install git-lfs
...
Update your git config to finish installation:

# Update global git config
$ git lfs install

# Update system git config
$ git lfs install --system

Post Install
Make sure at this point you are in the repo you intend to use git-lfs in. This part you will have to do in all applicable repos it will be used in.
> git lfs install
Updated git hooks.
Git LFS initialized.

Specify file types to track.
> git lfs track "*.mp4"
Tracking "*.mp4"

Check file types being tracked.
> git lfs track
Listing tracked patterns
*.mp4 (.gitattributes)
Listing excluded patterns

Now at this point even though I had some *mp4 files added and committed to my repo already, it found these same files and changed them to use the new git-lfs module.

> git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)

modified: includes/images/computers/builds/2004/VID_20170918_174906.mp4
modified: includes/images/computers/builds/2018/VID-20180201-WA0001.mp4
modified: includes/images/computers/builds/2018/VID_20180121_145056.mp4
modified: includes/images/computers/builds/2018/VID_20180125_204256.mp4

So I then added them, committed them and pushed them up again.
> git add includes/images/computers/builds/2004/VID_20170918_174906.mp4
> git add includes/images/computers/builds/2018/VID-20180201-WA0001.mp4
> git add includes/images/computers/builds/2018/VID_20180121_145056.mp4
> git add includes/images/computers/builds/2018/VID_20180125_204256.mp4

> git commit
[master 6fbfa4b] Added mp4 files to git lfs.
4 files changed, 0 insertions(+), 0 deletions(-)
rewrite includes/images/computers/builds/2004/VID_20170918_174906.mp4 (99%)
rewrite includes/images/computers/builds/2018/VID-20180201-WA0001.mp4 (100%)
rewrite includes/images/computers/builds/2018/VID_20180121_145056.mp4 (99%)
rewrite includes/images/computers/builds/2018/VID_20180125_204256.mp4 (99%)

> git push
Uploading LFS objects: 100% (4/4), 113 MB | 1.3 MB/s, done.
Counting objects: 12, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (12/12), 1.29 KiB | 1.29 MiB/s, done.
Total 12 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
To github.com:dsdickinson/codeuniversity.git
1f2b31a..6fbfa4b master -> master

So the git-lfs module simply creates link references in my main repo on github.com to the new files in GitHub’s git-lfs server.

Here is how you can view the files that are being managed with git-lfs.

> git lfs ls-files
60c5be30ad * includes/images/computers/builds/2004/VID_20170918_174906.mp4
952f1a8feb * includes/images/computers/builds/2018/VID-20180201-WA0001.mp4
1a94475aa5 * includes/images/computers/builds/2018/VID_20180121_145056.mp4
4e3656ea95 * includes/images/computers/builds/2018/VID_20180125_204256.mp4

That’s pretty much all there is to it. Everything else in your GitHub workflow is the same.

hponcfg

The hponcfg utility allows a sys-admin to configure a server’s HP iLO hardware straight from its host server via the command line. It does the magic by reading in a pre-configured XML file with the required settings. In this particular example we are going to be setting the iLO’s hostname.

First we create the XML file that hponcfg will use to set the hostname. Here we will call the XML file change_hostname.xml.

<RIBCL VERSION=”2.0″>
<LOGIN USER_LOGIN=”admin” PASSWORD=”somecoolpassword”>
<RIB_INFO MODE=”write”>
<MOD_NETWORK_SETTINGS>
<DHCP_DOMAIN_NAME value=”No”/>
<DNS_NAME value=”blackbox-con”/>
<DOMAIN_NAME value=”my.domain.net”/>
</MOD_NETWORK_SETTINGS>
</RIB_INFO>
</LOGIN>
</RIBCL>

In this example the admin user that is setup on the iLO has a password of somecoolpassword. This is the account that will actually login to the iLO and do the thing. We want to turn off getting a DHCP domain name so we give DHCP_DOMAIN_NAME a value of No. The DNS_NAME is the hostname and the DOMAIN_NAME is the domain name and tied together you get the fully qualified domain name i.e. blackbox-con.my.domain,net.

Our second step is to run the hponcfg command that reads in the XML config file and updates the hostname accordingly.

> hponcfg -f change_hostname.xml
HP Lights-Out Online Configuration utility
Version 4.3.0 Date 12/10/2013 (c) Hewlett-Packard Company, 2014
Firmware Revision = 1.13 Device type = iLO 4 Driver name = hpilo
<INFORM>Integrated Lights-Out will reset at the end of the script.</INFORM>

Please wait while the firmware is reset. This might take a minute
Script succeeded

By running this command, we have renamed our iLO hardware to blackbox-con.my.domain.net. Presumably the actual host’s hostname would be something blackbox.my.domain.net and we would want to make them both unique.

And there you have it. We have just renamed our iLO hostname.

Upgrading iocage jails from FreeBSD 10.3 to 11.0 (major upgrade)

Iocage makes upgrading jails quite simple. It can be a little more involved than the host upgrade but not by much.

First on the host server we need to fetch the right version of FreeBSD for iocage to use. This will create the iocage zfs file system structures for upgrading to and building 11.0 jails.

$ sudo iocage fetch 11.0-RELEASE

$ zfs list
NAME                                                              USED  AVAIL  REFER  MOUNTPOINT
pgdata                                                           7.63G   262G    19K  legacy
pgdata/pg94                                                      7.63G   262G  7.63G  /pg94
sys                                                               257G   580G    19K  legacy
sys/ROOT                                                         2.27G   580G    19K  legacy
sys/ROOT/default                                                 2.27G   580G  1.38G  /
sys/home                                                         4.62G   580G  4.60G  /home
sys/iocage                                                       94.2G   580G  24.9G  /iocage
sys/iocage/.defaults                                               28K   580G    19K  /iocage/.defaults
sys/iocage/base                                                  1.35G   580G    19K  /iocage/base
sys/iocage/base/10.3-RELEASE                                      655M   580G    19K  /iocage/base/10.3-RELEASE
sys/iocage/base/10.3-RELEASE/root                                 655M   580G  69.5M  /iocage/base/10.3-RELEASE/root
sys/iocage/base/10.3-RELEASE/root/bin                             804K   580G   790K  /iocage/base/10.3-RELEASE/root/bin
sys/iocage/base/10.3-RELEASE/root/boot                           1.24M   580G  1.23M  /iocage/base/10.3-RELEASE/root/boot
sys/iocage/base/10.3-RELEASE/root/lib                            5.35M   580G  5.34M  /iocage/base/10.3-RELEASE/root/lib
sys/iocage/base/10.3-RELEASE/root/libexec                         196K   580G   185K  /iocage/base/10.3-RELEASE/root/libexec
sys/iocage/base/10.3-RELEASE/root/rescue                         4.94M   580G  4.93M  /iocage/base/10.3-RELEASE/root/rescue
sys/iocage/base/10.3-RELEASE/root/sbin                           3.81M   580G  3.79M  /iocage/base/10.3-RELEASE/root/sbin
sys/iocage/base/10.3-RELEASE/root/usr                             569M   580G    21K  /iocage/base/10.3-RELEASE/root/usr
sys/iocage/base/10.3-RELEASE/root/usr/bin                        48.0M   580G  47.9M  /iocage/base/10.3-RELEASE/root/usr/bin
sys/iocage/base/10.3-RELEASE/root/usr/include                    8.11M   580G  7.94M  /iocage/base/10.3-RELEASE/root/usr/include
sys/iocage/base/10.3-RELEASE/root/usr/lib                        39.7M   580G  39.7M  /iocage/base/10.3-RELEASE/root/usr/lib
sys/iocage/base/10.3-RELEASE/root/usr/lib32                      39.0M   580G  38.9M  /iocage/base/10.3-RELEASE/root/usr/lib32
sys/iocage/base/10.3-RELEASE/root/usr/libdata                     139K   580G   127K  /iocage/base/10.3-RELEASE/root/usr/libdata
sys/iocage/base/10.3-RELEASE/root/usr/libexec                    1.80M   580G  1.75M  /iocage/base/10.3-RELEASE/root/usr/libexec
sys/iocage/base/10.3-RELEASE/root/usr/sbin                       8.08M   580G  8.07M  /iocage/base/10.3-RELEASE/root/usr/sbin
sys/iocage/base/10.3-RELEASE/root/usr/share                      29.9M   580G  29.5M  /iocage/base/10.3-RELEASE/root/usr/share
sys/iocage/base/10.3-RELEASE/root/usr/src                         394M   580G   389M  /iocage/base/10.3-RELEASE/root/usr/src
sys/iocage/base/11.0-RELEASE                                      724M   580G    19K  /iocage/base/11.0-RELEASE
sys/iocage/base/11.0-RELEASE/root                                 724M   580G  47.2M  /iocage/base/11.0-RELEASE/root
sys/iocage/base/11.0-RELEASE/root/bin                             824K   580G   824K  /iocage/base/11.0-RELEASE/root/bin
sys/iocage/base/11.0-RELEASE/root/boot                           1.48M   580G  1.48M  /iocage/base/11.0-RELEASE/root/boot
sys/iocage/base/11.0-RELEASE/root/lib                            5.96M   580G  5.96M  /iocage/base/11.0-RELEASE/root/lib
sys/iocage/base/11.0-RELEASE/root/libexec                         192K   580G   192K  /iocage/base/11.0-RELEASE/root/libexec
sys/iocage/base/11.0-RELEASE/root/rescue                         5.75M   580G  5.75M  /iocage/base/11.0-RELEASE/root/rescue
sys/iocage/base/11.0-RELEASE/root/sbin                           3.99M   580G  3.99M  /iocage/base/11.0-RELEASE/root/sbin
sys/iocage/base/11.0-RELEASE/root/usr                             658M   580G   120K  /iocage/base/11.0-RELEASE/root/usr
sys/iocage/base/11.0-RELEASE/root/usr/bin                        77.8M   580G  77.8M  /iocage/base/11.0-RELEASE/root/usr/bin
sys/iocage/base/11.0-RELEASE/root/usr/include                    8.08M   580G  8.08M  /iocage/base/11.0-RELEASE/root/usr/include
sys/iocage/base/11.0-RELEASE/root/usr/lib                        48.7M   580G  48.7M  /iocage/base/11.0-RELEASE/root/usr/lib
sys/iocage/base/11.0-RELEASE/root/usr/lib32                      40.8M   580G  40.8M  /iocage/base/11.0-RELEASE/root/usr/lib32
sys/iocage/base/11.0-RELEASE/root/usr/libdata                     129K   580G   129K  /iocage/base/11.0-RELEASE/root/usr/libdata
sys/iocage/base/11.0-RELEASE/root/usr/libexec                    1.91M   580G  1.91M  /iocage/base/11.0-RELEASE/root/usr/libexec
sys/iocage/base/11.0-RELEASE/root/usr/sbin                       8.57M   580G  8.57M  /iocage/base/11.0-RELEASE/root/usr/sbin
sys/iocage/base/11.0-RELEASE/root/usr/share                      38.4M   580G  38.4M  /iocage/base/11.0-RELEASE/root/usr/share
sys/iocage/base/11.0-RELEASE/root/usr/src                         434M   580G   434M  /iocage/base/11.0-RELEASE/root/usr/src

 

$ sudo iocage upgrade jail01 -r 11.0-RELEASE
* Creating back-out snapshot.
* Upgrading jail.
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 10.3-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic src/src world/base world/doc world/lib32

The following components of FreeBSD do not seem to be installed:
world/games

Does this look reasonable (y/n)? y

Fetching metadata signature for 11.0-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.
Fetching files from 10.3-RELEASE for merging... done.
Preparing to download files... done.
Fetching 45107 patches.....10....20....30.  done.
Applying patches... done.
Fetching 12420 files...

Now we need to upgrade all the packages in the jail.

$ sudo iocage console jail01
$ pkg-static install -f pkg
$ pkg upgrade
Shared object "libssl.so.7" not found, required by "pkg"

Here we have an issue with the old pkg binary which is linking to a version of libssl that no longer exists. To fix this we need to reinstall the pkg binary.

$ pkg-static install -f pkg
pkg-static: Warning: Major OS version upgrade detected.  Running "pkg-static install -f pkg" recommended
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
New version of pkg detected; it needs to be installed first.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        pkg: 1.8.8 -> 1.9.4_1

Number of packages to be upgraded: 1

3 MiB to be downloaded.

Proceed with this action? [y/N]: y
[blackbox@mars.com] Fetching pkg-1.9.4_1.txz: 100%    3 MiB   2.9MB/s    00:01
Checking integrity... done (0 conflicting)
[blackbox@mars.com] [1/1] Upgrading pkg from 1.8.8 to 1.9.4_1...
[blackbox@mars.com] [1/1] Extracting pkg-1.9.4_1: 100%
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be REINSTALLED:
        pkg-1.9.4_1

Number of packages to be reinstalled: 1

Proceed with this action? [y/N]: y
[1/1] Reinstalling pkg-1.9.4_1...
[1/1] Extracting pkg-1.9.4_1: 100%

Now let’s see if it works.

$ pkg info
alsa-lib-1.1.2                 ALSA compatibility library
ap24-mod_perl2-2.0.9,3         Embeds a Perl interpreter in the Apache server
apache24-2.4.23_1              Version 2.4.x of Apache web server
apr-1.5.2.1.5.4_1              Apache Portability Library
augeas-1.4.0                   Configuration editing tool
...

It works! Let’s continue upgrading the packages..

$ pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (324 candidates): 100%
Processing candidates (324 candidates): 100%
The following 353 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
 readline: 6.3.8
 p5-Sub-Quote: 2.003001
 p5-List-UtilsBy: 0.10
 p5-Math-Random-Secure: 0.06_1
 p5-Any-Moose: 0.26
...

Installed packages to be UPGRADED:
 zsh: 5.2_3 -> 5.3.1
 xproto: 7.0.28 -> 7.0.31
 wget: 1.18 -> 1.18_2
 vim-lite: 8.0.0019_1 -> 8.0.0134_1
...

Installed packages to be REINSTALLED:
 zfs-stats-1.2.2_1 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 xextproto-7.3.0 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 unzip-6.0_7 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 unixODBC-2.3.4 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
...

Number of packages to be installed: 29
Number of packages to be upgraded: 86
Number of packages to be reinstalled: 238

The process will require 46 MiB more space.
203 MiB to be downloaded.

Proceed with this action? [y/N]:
[blackbox@mars.com] Fetching zsh-5.3.1.txz: 100% 4 MiB 4.1MB/s 00:01
[blackbox@mars.com] Fetching zfs-stats-1.2.2_1.txz: 100% 9 KiB 9.5kB/s 00:01
[blackbox@mars.com] Fetching xproto-7.0.31.txz: 100% 59 KiB 60.2kB/s 00:01
[blackbox@mars.com] Fetching xextproto-7.3.0.txz: 100% 21 KiB 21.9kB/s 00:01
[blackbox@mars.com] Fetching wget-1.18_2.txz: 100% 578 KiB 592.2kB/s 00:01
[blackbox@mars.com] Fetching vim-lite-8.0.0134_1.txz: 100% 5 MiB 5.5MB/s 00:01
...

Number of packages to be installed: 29
Number of packages to be upgraded: 85
Number of packages to be reinstalled: 238

The process will require 46 MiB more space.

Proceed with this action? [y/N]:


[blackbox@mars.com] [1/354] Upgrading perl5 from 5.20.3_15 to 5.24.1.r4_1...
[blackbox@mars.com] [1/354] Extracting perl5-5.24.1.r4_1: 100%
[blackbox@mars.com] [2/354] Reinstalling p5-Sub-Install-0.928_1...
[blackbox@mars.com] [2/354] Extracting p5-Sub-Install-0.928_1: 100%
...
[blackbox@mars.com] [54/354] Installing libassuan-2.4.3...
[blackbox@mars.com] [54/354] Extracting libassuan-2.4.3: 100%
[blackbox@mars.com] [55/354] Installing libtasn1-4.9...
[blackbox@mars.com] [55/354] Extracting libtasn1-4.9: 100%
[blackbox@mars.com] [56/354] Installing tpm-emulator-0.7.4_1...
===> Creating groups.
Creating group '_tss' with gid '601'.
===> Creating users
Creating user '_tss' with uid '601'.
pw: user '_tss' disappeared during update
pkg: PRE-INSTALL script failed

Uh oh. Houston we have a problem. No biggie. Just run this to regenerate the passwd file which will fix it.

$ vipw
:w! (to save it)

Now lets finish up the pkg  upgrade.

$ pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (273 candidates): 100%
Processing candidates (273 candidates): 100%
Checking integrity... done (1 conflicting)
 - p5-Sub-Quote-2.003001 conflicts with p5-Moo-2.002004 on /usr/local/lib/perl5/site_perl/Sub/Defer.pm
Checking integrity... done (0 conflicting)
The following 298 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
 readline: 6.3.8
 p5-Sub-Quote: 2.003001
 p5-Math-Random-Secure: 0.06_1
 p5-Any-Moose: 0.26
...

Installed packages to be UPGRADED:
 zsh: 5.2_3 -> 5.3.1
 wget: 1.18 -> 1.18_2
 vim-lite: 8.0.0019_1 -> 8.0.0134_1
...

Installed packages to be REINSTALLED:
 zfs-stats-1.2.2_1 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 xextproto-7.3.0 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 unzip-6.0_7 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 unixODBC-2.3.4 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 ttcp-1.12_1 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 tmux-2.3 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
...

Number of packages to be installed: 25
Number of packages to be upgraded: 68
Number of packages to be reinstalled: 205

The process will require 40 MiB more space.

Proceed with this action? [y/N]: y
[eastern01.cello.com] [1/298] Installing tpm-emulator-0.7.4_1...
===> Creating groups.
Using existing group '_tss'.
===> Creating users
Using existing user '_tss'.
[blackbox@mars.com] [1/298] Extracting tpm-emulator-0.7.4_1: 100%
[blackbox@mars.com] [2/298] Deinstalling p5-Moo-2.002004...
[blackbox@mars.com] [2/298] Deleting files for p5-Moo-2.002004: 100%
[blackbox@mars.com] [3/298] Reinstalling xextproto-7.3.0...
...

Finally let’s upgrade any cpan modules we have installed in the jail.

$ cpan-outdated | cpanm
--> Working on I/IB/IBB/Acme-Damn-0.08.tar.gz
Fetching http://www.cpan.org/authors/id/I/IB/IBB/Acme-Damn-0.08.tar.gz ... OK
Configuring Acme-Damn-0.08 ... OK
Building and testing Acme-Damn-0.08 ... OK
Successfully installed Acme-Damn-0.08
--> Working on K/KA/KAZEBURO/Apache-LogFormat-Compiler-0.33.tar.gz
Fetching http://www.cpan.org/authors/id/K/KA/KAZEBURO/Apache-LogFormat-Compiler-0.33.tar.gz ... OK
Configuring Apache-LogFormat-Compiler-0.33 ... OK
Building and testing Apache-LogFormat-Compiler-0.33 ... OK
Successfully installed Apache-LogFormat-Compiler-0.33
--> Working on B/BI/BINGOS/Archive-Tar-2.24.tar.gz
Fetching http://www.cpan.org/authors/id/B/BI/BINGOS/Archive-Tar-2.24.tar.gz ... OK
Configuring Archive-Tar-2.24 ... OK
Building and testing Archive-Tar-2.24 ... OK
Successfully installed Archive-Tar-2.24
...

All done!

Upgrading from FreeBSD 10.3 to 11.0 (major upgrade)

Performing a major upgrade isn’t much different from doing a minor upgrade as far as ease goes. However more can go wrong. Here we’ll discuss the basic commands to get through it.

First we want to get to the latest and greatest minor version patch level of FreeBSD.

$ sudo freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 10.3-RELEASE from update6.freebsd.org... done.
Fetching metadata index... done.
Fetching 2 metadata patches.. done.
Applying metadata patches... done.
Inspecting system... done.
Preparing to download files... done.
Fetching 324 patches.....10....20....30. done.
Applying patches... done.
Fetching 40 files... done.

The following files are affected by updates, but no changes have
been downloaded because the files have been modified locally:
/etc/mail/freebsd.cf
/etc/mail/freebsd.submit.cf
/etc/mail/sendmail.cf
...

The following files will be removed as part of updating to 10.3-RELEASE-p15:
/usr/share/zoneinfo/America/Santa_Isabel
/usr/share/zoneinfo/Asia/Rangoon

The following files will be added as part of updating to 10.3-RELEASE-p15:
/usr/share/zoneinfo/Asia/Barnaul
/usr/share/zoneinfo/Asia/Famagusta
/usr/share/zoneinfo/Asia/Tomsk
/usr/share/zoneinfo/Asia/Yangon
...

The following files will be updated as part of updating to 10.3-RELEASE-p15:
/bin/freebsd-version
/lib/libc.so.7
/rescue/[
/rescue/atmconfig
/rescue/badsect
...

$ sudo freebsd-update install
Installing updates... done.

Now let’s do the major upgrade:

$ sudo freebsd-update upgrade -r 11.0-RELEASE
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 10.3-RELEASE from update3.freebsd.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic src/src world/base world/games world/lib32

The following components of FreeBSD do not seem to be installed:
world/doc

Does this look reasonable (y/n)? y

Fetching metadata signature for 11.0-RELEASE from update3.freebsd.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.
Fetching files from 10.3-RELEASE for merging... done.
Preparing to download files... done.
Fetching 45032 patches.....10....20....30....40....50. done.
Applying patches... done.
Fetching 12099 files... done.
Attempting to automatically merge changes in files... done.

The following file could not be merged automatically: /etc/defaults/rc.conf
Press Enter to edit this file in /usr/bin/vi and resolve the conflicts
manually...

At this point you’ll be placed into various files that have merge conflicts. They will need to be resolved. In each file you will see the markers that designate the old files content vs the new files content such as:

<<<<<<< current version
# $FreeBSD: release/10.3.0/etc/syslog.conf 194005 2014-06-11 15:07:02Z avg $
=======
# $FreeBSD: release/11.0.0/etc/syslog.conf 238473 2016-07-15 10:55:43Z brueffer $
>>>>>>> 11.0-RELEASE

Basically you will choose which content wins (typically the new content) by removing the markers and the old content. So in this example you would end up with:

# $FreeBSD: release/11.0.0/etc/syslog.conf 238473 2016-07-15 10:55:43Z brueffer $

Now we will continue on. Next you will be asked if various merges that did not have conflicts look reasonable.

The following changes, which occurred between FreeBSD 10.3-RELEASE and
FreeBSD 11.0-RELEASE have been merged into /etc/defaults/periodic.conf:
Does this look reasonable (y/n)?

The following files are affected by updates, but no changes have
been downloaded because the files have been modified locally:
/.cshrc
/.profile
/root/.cshrc
/root/.k5login
/root/.login
/root/.profile
...
To install the downloaded upgrades, run "/usr/sbin/freebsd-update install".

$ sudo freebsd-update install
$ sudo shutdown -r now

$ hostver
FreeBSD 10.3 RELEASE-p15

$ sudo freebsd-update install
Installing updates...

Completing this upgrade requires removing old shared object files.
Please rebuild all installed 3rd party software (e.g., programs
installed from the ports tree) and then run "/usr/sbin/freebsd-update install"
again to finish installing updates.

$ hostver
FreeBSD 11.0 RELEASE-p6

$ uname -r
11.0-RELEASE-p2

$ sudo shutdown -r now

Now lets upgrade the packages on the system.

$ sudo pkg upgrade
pkg: Warning: Major OS version upgrade detected.  Running "pkg-static install -f pkg" recommended
Updating FreeBSD repository catalogue...
Repository FreeBSD has a wrong packagesite, need to re-create database
Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
Fetching packagesite.txz: 100%    6 MiB   5.9MB/s    00:01
Processing entries: 100%
FreeBSD repository update completed. 25901 packages processed.
New version of pkg detected; it needs to be installed first.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        pkg: 1.9.3 -> 1.9.4_1

Number of packages to be upgraded: 1

3 MiB to be downloaded.

Proceed with this action? [y/N]: y
Fetching pkg-1.9.4_1.txz: 100%    3 MiB   2.9MB/s    00:01
Checking integrity... done (0 conflicting)
[1/1] Upgrading pkg from 1.9.3 to 1.9.4_1...
[1/1] Extracting pkg-1.9.4_1: 100%
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (102 candidates): 100%
Processing candidates (102 candidates): 100%
The following 104 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        readline: 6.3.8
        libnghttp2: 1.18.1

Installed packages to be UPGRADED:
        zsh: 5.2_4 -> 5.3.1
        vim-lite: 8.0.0063 -> 8.0.0134_1
        trousers: 0.3.13_1 -> 0.3.14_1
        sudo: 1.8.18p1 -> 1.8.19p1
        subversion: 1.9.4 -> 1.9.5
        sqlite3: 3.14.1_1 -> 3.15.1_1
        ruby: 2.2.5_1,1 -> 2.2.6_1,1
        rsync: 3.1.2_5 -> 3.1.2_6
        python27: 2.7.12 -> 2.7.13_1
        ...

Installed packages to be REINSTALLED:
        zfs-stats-1.2.2_1 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
        urlview-0.9.20131021_1 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
        unzip-6.0_7 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
        ttcp-1.12_1 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
        ...

Number of packages to be installed: 2
Number of packages to be upgraded: 38
Number of packages to be reinstalled: 64

The process will require 5 MiB more space.
110 MiB to be downloaded.

Proceed with this action? [y/N]: y
Fetching zsh-5.3.1.txz: 100%    4 MiB   4.1MB/s    00:01
Fetching zfs-stats-1.2.2_1.txz: 100%    9 KiB   9.5kB/s    00:01
Fetching vim-lite-8.0.0134_1.txz: 100%    5 MiB   5.5MB/s    00:01
...
Checking integrity... done (0 conflicting)
[1/104] Reinstalling indexinfo-0.2.6...
[1/104] Extracting indexinfo-0.2.6: 100%
[2/104] Reinstalling libffi-3.2.1...
[2/104] Extracting libffi-3.2.1: 100%
[3/104] Upgrading gettext-runtime from 0.19.8.1 to 0.19.8.1_1...
[3/104] Extracting gettext-runtime-0.19.8.1_1: 100%
...

Finally we’ll upgrade any perl modules on the system from cpan.

$ sudo cpan-outdated | sudo cpanm

So, to recap the commands are as follows and in this order:

$ sudo freebsd-update fetch
$ sudo freebsd-update install
$ sudo freebsd-update upgrade -r 11.0-RELEASE
$ sudo freebsd-update install
$ sudo shutdown -r now
$ sudo freebsd-update install
$ sudo pkg upgrade
$ sudo cpan-outdated | sudo cpanm

Display “real” FreeBSD version

Typically when you want to find the current version of FreeBSD you type the following:

$ uname -r
10.3-RELEASE-p4

That’s great but it doesn’t tell the full story. If updates were made that do not affect the kernel, than it will not be reflected here. For instance, if the system had been upgraded to patch 12 I would not know that from looking at this. It makes it look like its only been updated to patch 4. Enter the “/usr/src/sys/conf/newvers.sh” file. This file gives a more clear picture of the system’s current state of affairs. I wrote a quick script that grabs the relevant info from this file and displays it similarly to the uname output.

#!/usr/local/bin/perl

use strict;
use warnings;

my $file = "/usr/src/sys/conf/newvers.sh";
my $cnt = 0;
my ($type, $rev, $branch);

open (FILE, "$file") or die "File $file does not exist!";
while (<FILE>) {
 chomp ($_);
     if ($_ =~ /^TYPE="(.*)?"/) {
         $type = $1;
         $cnt++;
     }
    if ($_ =~ /^REVISION="(.*)?"/ && $cnt == 1) {
         $rev = $1;
         $cnt++;
     }
     if ($_ =~ /^BRANCH="(.*)?"/ && $cnt == 2) {
         $branch = $1;
     }
}
close (FILE);

print "$type $rev $branch\n";

I put this script in /usr/local/sbin/hostver on all the systems I administer.

$ hostver
FreeBSD 10.3 RELEASE-p12

Now I always know the current patch level of the system. There are other ways to get this info (freebsd-version) but this works fine for me.

Windows boot up .. 70,000+ updates?!?!?

I normally leave my Windows 7 PC up and running at the office for various reasons. The other day I came into work and we had lost power. I was greeted with the following update message while booting:

2014-07-07 10.15.25

20140707_101330

20140707_101354(0)

Now, to be fair, it ran through all these updates in a flash which was nice. I’m assuming this happened because I always turn off auto updates because I loath when Windows decides to reboot me to do an auto update and I loose work. Anyone else notice these fly-by recently or was it just catching up on updates?