# upgrading from 6.2 to 6.3 / 7?



## Lem0nHead (Aug 18, 2009)

hello

I'm having a problem with my current 6.2 kernel, so I'm considering upgrading to 6.3 or 7

since it's an important server, I'm doing my best to avoid major downtimes
so what's the least risk option?
1) upgrade from 6.2 to 6.3 (and, if it doesn't solve the problem, upgrade from 6.3 to 7 later)
2) upgrade from 6.2 to 7?

I current have only SSH access to this server, but I can request a ipkvm which will probably make things safer

thanks


----------



## phoenix (Aug 18, 2009)

The safest upgrade path from 6.x to 7.y is:

upgrade to the latest version of 6.x (currently 6.4)
upgrade to 7.0
upgrade to the latest version of 7.x (currently 7.2)

That's the process for upgrading across any major versions:

upgrade to the latest minor release of X
upgrade to Y.0
upgrade to the latest minor release of Y


----------



## DutchDaemon (Aug 18, 2009)

It's usually considered best practice to upgrade to the latest minor version before hopping to the next major version, so I'd advise upgrading to 6.4 first, and then upgrade to 7.2 (I personally don't think the 7.0 stopover is really necessary, but opinions differ).


----------



## phoenix (Aug 19, 2009)

Yes, it should be safe to go from "last minor version of X" to "current version of X+1".  I just like to play it safe when it comes to important servers, and upgrade to .0 first.


----------



## Lem0nHead (Aug 19, 2009)

thanks for the suggestions

would it be safe to update from 6.2 to 6.4 with this cvsup config?


```
*default host=cvsup.us.FreeBSD.org
*default base=/usr
*default prefix=/usr

*default release=cvs tag=RELENG_6_4
*default delete use-rel-suffix

*default compress

src-all
```

and then the classic

```
cd /usr/src
make buildworld
make buildkernel KERNCONF=CUSTOM
make installkernel KERNCONF=CUSTOM
mergemaster -p
make installworld
mergemaster
```

(after customizing the kernel)?


sorry to ask that basic question
I've done that before like that and it worked, but I'm just wondering if I should take some other precaution, expect some kind of lib problem and so on

thanks


----------



## dennylin93 (Aug 19, 2009)

I also did an upgrade of 6.4 to 7.2 a few weeks ago. I didn't encounter any problems at all.

Your supfile is a bit weird. Change

```
*default base=/usr
```
to

```
*default base=/var/db
```

As for the actual upgrade process, the safest way is to follow the method mentioned in the Handbook. Although rebooting into single user mode takes more time, it is safer.


```
# cd /usr/src
# make buildworld
# make buildkernel KERNCONF=KERNEL
# make installkernel KERNCONF=KERNEL
# shutdown -r now
```

For buildworld and buildkernel, -j n flags will speed up the process.

Boot into single user mode.

```
# adjkerntz -i
# mount -a -t ufs
# mergemaster -p
# cd /usr/src
# make installworld
# mergemaster
# reboot
```

By the way, it might be faster to use `# mergmaster -Ui` instead of `# mergemaster` (-U updates files that have not been modified and -i installs files that don't exist). I forgot the flags once, and I had to install over a hundred files that were updated but not modified manually.

It is also preferable to upgrade ports when a major upgrade is done.


----------



## DutchDaemon (Aug 19, 2009)

There's actually nothing wrong with using


```
*default base=/usr
```

Used it since the ${epoch} on about ${atoms} installs.


----------



## DutchDaemon (Aug 19, 2009)

@Lem0nHead


```
*default release=cvs tag=RELENG_6_4
```

This may be purely intuitive, but I feel that using RELENG_6 for this time only might get you as close to 7 as you can get. It should make the jump to 7 as lightweight as possible.

Note: make sure to recompile all of your ports on FreeBSD 7. You will have compat6 in the kernel, but being on the same 'binary page' is preferable.


----------



## phoenix (Aug 19, 2009)

DutchDaemon said:
			
		

> There's actually nothing wrong with using
> 
> 
> ```
> ...



This was the default for cvsup installed via the ports tree.

Once csup was imported into the base, the default was changed to /var/db/ to follow hier(7).  (Check the commit history for /usr/share/examples/cvsup/standard-supfile to see exactly when the change was made.)

Both will work fine, though.  Neither will cause the world to end.    Technically, /var/db/ is more correct.


----------



## phoenix (Aug 19, 2009)

dennylin93 said:
			
		

> For buildworld and buildkernel, -j n flags will speed up the process.



Is it safe to use -j for build*kernel* now?  In the past, it wasn't, and using -j would lead to build and runtime errors as the Makefiles were not -j safe.  I've never used it for buildkernel.


----------



## DutchDaemon (Aug 19, 2009)

Used -j for buildkernel regularly over the past year or more. Never seen problems with it.


----------



## phoenix (Aug 19, 2009)

Coolio.  Thanks for the update.


----------



## Lem0nHead (Aug 20, 2009)

thanks for the hints, guys
today I sucessfully got to update a test server from 6.1 to 6.4
saturday I'm gonna try on the real server (6.2 -> 6.4) and, if it doesn't solve the problem, then I'll try the 6.4 -> 7.2 on the test server and then on the real one

thanks


----------



## Lem0nHead (Aug 23, 2009)

it seems the 6.2 -> 6.4 upgrade was successful
the only problem I had was that, when I run "mergemaster -p" it complained about a "PERL_VER" variable on /etc/make.conf and didn't do anything

so I thought it was ok and proceeded to "mergemaster"
it them buged me a lot, making me choose a lot of files
I was in a hurry (single mode as suggested, so all services down), but I tried to be careful
I basically installed all new files, except rc.conf, hosts and snmpd

now everything seems fine, except some bugs on snmpd (that I think I can handle, and it's not very important right now) and:


```
Aug 23 03:30:58 server09 root: /etc/rc: WARNING: $rfcomm_pppd_server_enable is not set properly - see rc.conf(5).
Aug 23 03:31:04 server09 root: /etc/rc: WARNING: $mixer_enable is not set properly - see rc.conf(5).
```

but I don't even have this vars on /etc/rc.conf
does it mean I should have them setted to the default value or something like that?


can the way I did things (without mergemaster -p) cause problems upgrading to 7.2?


----------



## Aprogas (Aug 23, 2009)

I recently cut a corner and went directly from 6.3 to 7.2 without passing 6.4, I have not yet seen any problems. Add COMPAT_FREEBSD6 to your kernel unless you want to rebuild/reinstall all your ports/packages. Run post-install mergemaster with -F for the hundreds of files that only have a new $FreeBSD tag.


----------



## DutchDaemon (Aug 23, 2009)

Lem0nHead said:
			
		

> the only problem I had was that, when I run "mergemaster -p" it complained about a "PERL_VER" variable



Not a problem, just a warning. Some ports use make.conf to store variables (like Perl), and mergemaster doesn't recognise these lines.



> ```
> Aug 23 03:30:58 server09 root: /etc/rc: WARNING: $rfcomm_pppd_server_enable is not set properly - see rc.conf(5).
> Aug 23 03:31:04 server09 root: /etc/rc: WARNING: $mixer_enable is not set properly - see rc.conf(5).
> ```
> ...



That appears to be the problem then   If you recognise the programs and use them, just put these lines in rc.conf with "YES".


----------



## Lem0nHead (Aug 23, 2009)

Aprogas said:
			
		

> I recently cut a corner and went directly from 6.3 to 7.2 without passing 6.4, I have not yet seen any problems. Add COMPAT_FREEBSD6 to your kernel unless you want to rebuild/reinstall all your ports/packages. Run post-install mergemaster with -F for the hundreds of files that only have a new $FreeBSD tag.



gonna try
thanks for the COMPAT_FREEBSD6 hint

by the way, this mergemaster -F should be default 
who doesn't want that?


----------

