# Major and Minor Version Upgrades offline



## scryptkiddy (Mar 13, 2013)

Hey all, 

Trying to update a system that is not connected to internet from 8.2-RELEASE to 8.3-RELEASE. 

On the internet connected machines, there are no problems. I followed the 25.2.3 section of the handbook, boom, all good. :e

But on the system that is not internet connected, I was a bit stumped. 
I did a few searches, but was a bit lost on some of the hits on how to do this. One thread seemed to be really close to what I'm trying do. 

wblock had a response(#4), but said it was (untested), and I also noticed fronclynne's response (#5) but was a bit confused where to start (I'm new at FreeBSD obviously) and how to do that exactly. 

Is there a section in the handbook for doing offline upgrades, or can someone help me understand their postings (if they are correct) in this situation? Would appreciate it.

SK


----------



## SirDice (Mar 14, 2013)

On the online machine check out a full source tree for 8.3-RELEASE (releng/8.3). Tar /usr/src/ and copy it to the offline machine. Build and install world as normal.


----------



## jb_fvwm2 (Mar 14, 2013)

If you've /obj /src on a thumbdrive, you can mount -o union (or unionfs) it to /usr and the two directories would be there to installworld from... won't always work but usually does. (rsync ... --bwlimit=1000 (see other posts) is useful for copying to the thumbdrive without corrupting it ( and can be tested first with just a subdirectory within /usr/src )


----------



## scryptkiddy (Mar 14, 2013)

Hey all, 

@SirDice - Your reply has me reading a lot on the CVS vs Subversion, since (I'm assuming) Subversion is what I need to use to "check out a full source tree".  So I read up on Synchronizing Source in Handbook (25.6).

I had only used portsnap to _update my ports tree_, along with portinstall / portupgrade to install and upgrade ports, along with freebsd-update to update the kernel. I have never known I could check out a full source tree, or even why I would need to (this a total noob admission I'm sure). :\

Anyhow, according to the Handbook (3.2.1) I can check out a source tree using:
`# svn checkout [url=svn+ssh://svn.freebsd.org/base/head]svn+ssh://svn.freebsd.org/base/head[/url] /usr/src`
then tar it up and copy it over to the offline machine. 

After that, I'm going to follow 25.7 Rebuilding â€œworldâ€ section of Handbook. 

Let me know if I'm on the  right track, and I can let everyone know how it worked out. 

SK

@jb_fvwm2 - sorry amigo, thumb drives not an option right now, system is not close by.


----------



## wblock@ (Mar 14, 2013)

scryptkiddy said:
			
		

> Hey all,
> 
> @SirDice - Your reply has me reading a lot on the CVS vs Subversion, since (I'm assuming) Subversion is what I need to use to "check out a full source tree".  So I read up on Synchronizing Source in Handbook (25.6).
> 
> ...



That's not quite the right command.  Only someone with a user account on the server can use svn+ssh.  And "head", also called -CURRENT, or the bleeding edge development version, is not recommended unless you are a developer.  The Using Subversion section shows a bit more.

Please point me to where you saw that example, because it should be updated.


----------



## phoenix (Mar 14, 2013)

Use freebsd-update to download the release you want.  Then copy /var/db/freebsd-update to the offline machine.  And use freebsd-update to install that version on the offline machine.

IOW, you fetch on the machine with Internet access.  Sneaker-net the bits over to the offline machine.  Then install on the offline machine.


----------



## scryptkiddy (Mar 14, 2013)

@@wblock I misspoke, it was not the Handbook, but an article on the freebsd website. It was formatted like the Handbook, so I thought it was part of it. Scroll down to the 3.2.1 section, that's where I got it from. Let me know what the right command is if that's not it (or is it in the link you gave me?).

@phoenix I tried that as my first go round, meaning I brought over all of the /var/db/freebsd-update directory to the non internet connected box. When I brought it over to that box, FreeBSD would not allow me to run freebsd-update without errors. It gave an error (I wish I would have wrote it down), that basically stated that there "were no updates to apply" or something to that effect.So I reverted the /var/db/freebsd-update directory to the backup that I made prior to starting that attempt. 

Sounds like I need the correct svn command (if you have please provide) then I can check out, copy, and bring over the new source tree to the offline box and test the build world section IAW the Handbook. 

Let me know if I'm on the right track. Appreciate the replies. 

SK


----------



## wblock@ (Mar 14, 2013)

scryptkiddy said:
			
		

> _@wblock_ I misspoke, it was not the Handbook, but an article on the freebsd website. It was formatted like the Handbook, so I thought it was part of it. Scroll down to the 3.2.1 section, thats where I got it from.
> Let me know what the right command is if thats not it (or is it in the link you gave me?).



Yes, that was the Committer's Guide.

To check out FreeBSD 8.3-RELEASE:

```
# mv /usr/src /usr/src.old
# svn checkout https://svn0.us-west.FreeBSD.org/base/releng/8.3 /usr/src
```

In the first step, /usr/src can be deleted if you don't have any customizations you want to save.  Either way, make sure /usr/src does not exist before the checkout.

The second line uses the western SVN mirror.  Depending on where you are, the eastern mirror might be faster.


----------



## scryptkiddy (Mar 14, 2013)

Ahh, okay. Am I to assume the Committer's Guide is not authoritative and more informational from this point on, or is that something you are going to update? Just curious for future reference... 

Back to business though, after I check out the source tree using SVN, I would tar up the /usr/src directory on the online box and move it over to the non internet connected box corrrect? And I'm assuming I would also need to ensure that the /usr/src directory does not exist on the non internet connected box as well (tar will overwrite it anyway, but just wondering).

Seems logical, but I hate assuming anything. 

SK


----------



## wblock@ (Mar 14, 2013)

The Committer's Guide is okay, but it's for committers, people who can directly modify FreeBSD source, ports, or docs.  The example it uses is somewhat correct for that, although it's been recommended that people use the mirrors rather than just svn.freebsd.org, which could change.

Once you have the /usr/src directory, yes, copy it to the system to be upgraded.  The .svn subdirectory is not needed, and skipping it will save a fair amount of space.  To avoid old files, remove the destination /usr/src first.


----------



## scryptkiddy (Mar 15, 2013)

Hmm, well have been troubleshooting the error if anyone is wondering whats going on. 

So after moving the tar of /usr/src from the online box to the non internet connected box, I mv'd the /usr/src to /usr/src.old , then extracted the tarball in the /usr directory.

Everything looked correct under the new /usr/src , so I ran [cmd=]freebsd-update install[/cmd] and received the following error:


```
[CMD=" "]#freebsd-update install[/CMD]
No updates are available to install. 
Run '/usr/sbin/freebsd-update fetch' first.
```

Not sure what that really means since the /usr/src that I uploaded was fetched on the online box, so it should be the latest already. 

Uname of online box: 
8.3-RELEASE-p3
Uname of non internet connected box:
8.2-RELEASE-p3

So I'm assuming I missed a step on the non internet connected box, or that something besides /usr/src is required to bring over. 

Let me know where I went wrong. 

SK


----------



## scryptkiddy (Mar 15, 2013)

Just thought of something. Do I need to bring over /usr/src/ AND /var/db/freebsd-update?

Maybe that*'*s what I missed. Let me know. 

SK


----------



## wblock@ (Mar 15, 2013)

You already have the source, there is no reason to mess with freebsd-update(8).  Build world and kernel as usual.


----------



## scryptkiddy (Mar 16, 2013)

I'm about to execute, been doing some reading on the build world procedurein the handbook.

My question is this non internet box is not close by so booting into single user mode remotely is not feasible unless I have a DRAC connection (which I don't). 

Not sure if I'm dead in the water, but trying to figure out if going to single user mode is *absolutely* necessary....or just recommended. This box is a test box of sorts, so I can try it, and / or shut down services if need be. But wanted to ask. 

SK


----------



## wblock@ (Mar 16, 2013)

Single user mode is not required: Building FreeBSD World And Kernel: The Short Form.


----------



## scryptkiddy (Mar 16, 2013)

Yeah, I kinda figured. After my post I saw this too in the build world procedure in the link from my post above:



> Upgrades from one release of the same FreeBSD branch to a more recent release of the same branch, such as from 9.0 to 9.1, may not need this procedure since it is less likely to run into serious mismatches between compiler, kernel, userland, and configuration files. The approach of make world followed by building and installing a new kernel might work well enough for minor updates.



Since I'm going from 8.2 to 8.3 that applies. So based on the above from the handbook (and the link you sent me) its just:

```
# make buildworld
# make kernel
# make installworld
# mergemaster -Ui
# shutdown -r now
/* Not in handbook, but might need? */
# cd /usr/src
# make check-old
```

I'm a little nervous about the last command, the link sent from wonkity says:


> If old files are found, use the delete-old and delete-old-libs targets to remove them. Programs that are still using old libraries will be broken until they have been recompiled.



So I'm assuming that `# make check-old` will give me a report, and let me know which binaries / ports / packages I'll have to recompile *IF* I choose to delete them. 

Fun stuff though, I'm currently on `# make buildworld`, its been running for like 15+ minutes. I suppose that if I had not brought over the .svn directories it would have been quicker? :\

I'll let this run, gonna look at this after the weekend, and I'll continue to follow up with status and / or questions if they come up, appreciate help thus far @wblock@. 

SK


----------



## wblock@ (Mar 16, 2013)

> So I'm assuming that `# make check-old` will give me a report, and let me know which binaries / ports / packages I'll have to recompile *IF* I choose to delete them.



It would be nice, but no, it does not.  Such a report is possible, I think, but it would take a very long time to run.



> ...Fun stuff though, I'm currently on `# make buildworld`, its been running for like 15+ minutes. I suppose that if I had not brought over the .svn directories it would have been quicker? :\



No, the .svn directory is not used by the build.  As far as fifteen minutes, you're compiling the entire userland from source.  Yes, it will take a while.  Sometimes hours on a slow machine.

There are some potential pitfalls in the process.  Using mergemaster(8) is one.  Read the man page, and do not blindly tell it to merge critical files like /etc/master.passwd or /etc/group.

Have you made a full backup?


----------



## scryptkiddy (Mar 18, 2013)

Yes, I created a backup using `# dd` to create a dump of each partition. I'm pretty familiar with it as well as `# restore`. I'll probably make a local copy of /etc/ files such as rc.conf passwd fstab, and others that I think I might need if `# mergemaster` is as potentially dangerous as it sounds.

This morning my (Windoze) computer seems to have been rebooted by a patch, I'm assuming my `# make kernel` finished though since it would be executing on the server anyway and has been on all weekend. I'm not sure if there is a way to check, but it should be okay to continue on to `# make installworld` next. I'll be reading up more on `# mergemaster` while it is executing that command. 

SK


----------



## scryptkiddy (Mar 18, 2013)

Progress, but a hiccup along the way that I need a bit more information on. 

I tried to execute  `# make installworld`, however, I received an error:


```
mtree: line 73: unknown user uucp
*** Error code 1

Stop in /usr/src.
```

I do recall removing the uucp user a while back (based on security). It was an account that I saw as unneccessary to _run_ the OS, however it was (and seems still is) required to _build_ the OS. At the time, I was only updating FreeBSD on internet connected boxes, so I assumed it safe to remove the user by simply commenting the user out of /etc/passwd via `# vipw` since I was using `# freebsd-update` only.

So I uncommented out the user in /etc/passwd, and reran the `# make installworld` and its (still) running. :e

But I would like to ask for some information on the `# uucp` user (not the binary). What I stated above is the length of my knowledge on the user, but any links or keen information on this user (as it applies to this thread) would be helpful. 

SK


----------



## scryptkiddy (Mar 18, 2013)

Okay

Rebooted, [CMD=""]uname -a[/CMD] now shows 8.3-RELEASE-p6, nice! :e

One items that I have to address:
I ran the rest of the commands on this link that you posted to check for any old libraries. Here is the result.

```
#cd /usr/src/
#make check-old
>>>> Checking for old files
>>>> Checking for old libraries
/lib/libcrypt.so.4
/lib/libreadline.so.7
/lib/libz.so.4
>>>> Checking for old directories
To remove old files and directories run 'make delete-old'.
To remove old librarires run 'make delete-old-libs'.
```

I have seen libcrypt.so.4 before when doing openssl(1) / ssh(1) updates, I think libz.so.4 is the also. So the question is, can I remove those (I will rebuild openssl(1) / ssh(1)), and / or how do I determine what needs to be rebuilt?


SK


----------



## wblock@ (Mar 18, 2013)

Don't use dd(1) for backups, it is not good for that.  See Backup Options For FreeBSD.

Both openssl(1) and ssh(1) are part of the base and were rebuilt with world.  Problems would be if something from ports was linked to the old libraries.  That is rare, and I can't recall the last time I saw a problem with that.  I would make another backup--maybe just of those libraries--and then remove them and test.


----------



## scryptkiddy (Mar 19, 2013)

Oops, big misprint. :\ I happened to be reading an article on dd(1) and typed it while I was replying to your post. Yes, I use dump(1), and love it too.

As far as the openssl and ssh, I noticed that the packages for those ports were still installed (the latest versions). So I can easily link /usr/bin/ssh (base) to /usr/local/bin/ssh and /usr/bin/openssl (base) to /usr/local/bin/openssl respectively. 

Good idea as far as backing up the files before removing, however as far as seeing what breaks that may be difficult. This box has around 140+ ports installed, not sure how I would be able to test except if something in future breaks when using or recompiling occurs.

Thanks again for all the help, now I know.

SK


----------



## wblock@ (Mar 19, 2013)

Don't link, just reinstall those ports and let them take care of it.


----------



## scryptkiddy (Mar 19, 2013)

Perhaps I'm installing the ports incorrectly. 

On the internet connected box I do the following to update the ports tree, then install the latest port, then create a package to move over to the non-internet connected box, then test:
-Internet connected box

```
#portsnap fetch
#porsnap extract
#portmaster -Bvw openssl
#portmaster -Bvw openssh
#pkg_create -b openssl-1.0.<new>
#pkg_create -b openssh<new>
```

-After uploading created packages above, on Non Internet connected box:

```
#pkg_create -b openssl-1.0.<old>
#pkg_delete -f openssl-1.0.<old>
#pkg_add openssl-1.0.<new>
#pkg_create -b openssh<old>
#pkg_delete -f openssh<old>
#openssl version
#ssh -V
```

I usually find that even after this, that the old version of openssl / openssh are still installed under /usr/bin/ssh /usr/bin/openssl, and the new ones are under /usr/local/bin/, so I usually link to ensure only the newest version is used in case the /usr/bin is called instead of the /usr/local/bin. 

Thats the only way I learned, if there is a better way please let me know. 

SK


----------



## wblock@ (Mar 19, 2013)

If a port is supposed to replace base system software, it should have an option for that.  Packages will not give a choice for that option, it will have to be set when the package is built.


----------



## SirDice (Mar 19, 2013)

If you add the -g switch to portmaster(8) and make sure /usr/ports/packages/ exists, packages will be build automatically and saved in /usr/ports/packages/.


----------



## scryptkiddy (Mar 19, 2013)

@wblock@ - Ahh, now I understand why I always need to do that on the binaries for the non internet connected boxes. 

@SirDice - That is a cool option, thanks for the tip. 

I'm off and running now. My goal was to upgrade a non-internet connected box from 8.2-8.3 and that is done. If anyone is following the thread, this is the overall steps I took to accomplish this based on the replies in this post:

--Online box:

Ensure you have Subversion
Need to obtain the latest source to upgrade the non internet computers' OS too. Subversion is the latest recommended way.
Guidance here
I built subversion(1) package which added two more packages:
neon(1) (with ssl)
apr(1)

Prepare /usr/src for new source. This was not needed for me, nothing was in /usr/src:
`# mv /usr/src /usr/src.old` 

Use Subversion, mirrors located here
Use subversion to get source and put in /usr/src, https would not work for me, so I used http
`# svn checkout [url]http://svn0.us-west.FreeBSD.org/base/releng/8.3[/url] /usr/src`

Create tar of new source to bring over to non internet connected box.
`# tar -cvf usr_src.tar /usr/src/`
Copy tarball usr_src.tar to CD / thumbdrive

--Offline Box:


Upload tarball
Upload usr_src.tar file to /usr/ 
`# cd /usr
#mv /usr/src /usr/src.old /*not needed for me, nothing was in there */
#tar -xvf usr_src.tar`

build new kernel using new source
`# make buildworld /* ~30 minutes */
#make kernel	/* ~15 minutes */
#make installkernel /* <5 minutes */
#make installworld  /* 10 minutes - REQUIRES uucp user! I had to add him back in */
#mergemaster -Uiv  /* understand your system, so that you know if you need to merge, delete, or install the new /etc/ files */
#shutdown -r now`

Verify new OS kernel installed
`# uname -a`

Clean up
`# cd /usr/src
#make check-old /* it lists out /path/file of old libs and directories that need to be removed. Make backups, then delete */
#make delete-old
#make delete-old-libs`
I rebooted here to test functionality of startup scripts after deleting the old paths and libraries.
Appreciate the help all. 

SK


----------



## wblock@ (Mar 19, 2013)

kernel is equivalent to buildkernel installkernel, so installkernel does not need to be done separately.  It will not hurt anything, just takes longer than necessary.


----------



## scryptkiddy (Mar 26, 2013)

Hrmmm....

Didn't want to bump this post, but today I was using my new found procedure of upgrading another offline system (thanks again all ), but this one had different result. Same OS upgrade as the other box: 8.2-RELEASE-p3 upgrading to 8.3-RELEASE-p6, on same hardware. 

After the OS upgrade on the first machine, [cmd=]uname -a[/cmd] returned 8.3-RELEASE-p6. Which it should since I did rebuild the kernel from svn source. However, the second machine, that I did today, the command returned 8.2-RELEASE-p3. I did some reading on the issue here which is where I learned about the file /usr/src/sys/conf/newvers.sh. The file has the following entry:


```
REVISION="8.3"
BRANCH="RELEASE-p6"
```

This is correct, and what I expected [cmd=]uname -a[/cmd] to return, but instead it returns the previous version 8.2-RELEASE-p3. Simple reboot was a thought, but that did not work either. 

So two questions. Where is [cmd=]uname -a[/cmd] getting its version if not from the file above? Second, how do I fix this (and any idea what I did to cause this so that I can avoid it in future)?

SK


----------



## SirDice (Mar 27, 2013)

Did you do a `# make clean` before starting the build process?


----------



## scryptkiddy (Mar 27, 2013)

Unfortunately not. I was not fully awake :\ and did a robotic like "I must follow procedure" zombie approach.

What I have done now is to remove the files from  both /usr/obj and /usr/src/ and have restarted the procedure at [cmd=]#make buildworld[/cmd].

The reason I removed the files at /usr/obj is due to the error I received from starting the process last time I tried the procedure (this morning). 

Let me know if this is way off base. 

SK


----------



## scryptkiddy (Mar 28, 2013)

Ahh, I think I figured it out!

Not knocking you, @wblock, but it was the below quoted reply that got me (my fault though for sure) 



> kernel is equivalent to buildkernel installkernel, so installkernel does not need to be done separately. It will not hurt anything, just takes longer than necessary.



I saw:

kernel was equivalent (*meaning alias*) to buildkernel installkernel...

You meant:

kernel was equivalent to *executing both* buildkernel *and* installkernel...


So I took the procedure I had run on the first machine under step 2 (see Post #27) and removed the `# make kernel`:

```
# make buildworld /* ~30 minutes */
#make installkernel /* <5 minutes */
#make installworld /* 10 minutes - REQUIRES uucp user! I had to add him back in */
#mergemaster -Uiv 
#shutdown -r now
```

I know I know, I'm learning though, so be kind. :e

Hopefully thats right. I'm starting back at the top of my procedure and using `# make kernel` it in this time so it should go smoothly. I'm not too comfortable with just executing `# make kernel` after the fact. I verified that the kernel was built under /usr/obj/usr/src/sys/GENERIC and it was, so confidence is a bit higher this time around.


SK


----------



## wblock@ (Mar 28, 2013)

I don't really get the misunderstanding; a confusion between the word "kernel" and these make targets, maybe.  To be clear:

```
# cd /usr/src
# make kernel
```

is the same as


```
# cd /usr/src
# make buildkernel installkernel
```

See line 276 of /usr/src/Makefile.


----------



## scryptkiddy (Mar 28, 2013)

Yeah, its hard to explain "confusion". 
Basically, I thought these three statements below did the same thing independently. So I decided to "pick one". I didn't understand that the first was really a superset of the other two. 

`# make kernel`
`# make buildkernel`
`# make installkernel`

Hope that helps. Either way, I think I'm good now, thanks again for your patience with me!

SK


----------



## wblock@ (Mar 28, 2013)

Ah, I think I see.  I should have said "kernel is equivalent to buildkernel _and then_ installkernel", or shown the example above in #33.  Sorry about that.


----------



## scryptkiddy (Mar 28, 2013)

That's it!

Anyway, my fault, I should still have been able to figure it out. 
Many thanks again, it's working now, I'm on my last server today, whoot! :e

SK


----------

