upgrading from 6.2 to 6.3 / 7?

L

Lem0nHead

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
 
The safest upgrade path from 6.x to 7.y is:
  1. upgrade to the latest version of 6.x (currently 6.4)
  2. upgrade to 7.0
  3. upgrade to the latest version of 7.x (currently 7.2)

That's the process for upgrading across any major versions:
  1. upgrade to the latest minor release of X
  2. upgrade to Y.0
  3. upgrade to the latest minor release of Y
 
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).
 
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. :)
 
thanks for the suggestions

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

Code: 
*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
Code: 
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
 
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
Code: 
*default base=/usr
to
Code: 
*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.

Code: 
# 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.
Code: 
# 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.
 
There's actually nothing wrong with using

Code: 
*default base=/usr

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

Code: 
*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.
 
DutchDaemon said:
There's actually nothing wrong with using

Code: 
*default base=/usr

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

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.
 
dennylin93 said:
For buildworld and buildkernel, -j n flags will speed up the process.
Click to expand...

Is it safe to use -j for buildkernel 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.
 
Used -j for buildkernel regularly over the past year or more. Never seen problems with it.
 
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
 
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:

Code: 
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?
 
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.
 
Lem0nHead said:
the only problem I had was that, when I run "mergemaster -p" it complained about a "PERL_VER" variable
Click to expand...

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

Code: 
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
Click to expand...

That appears to be the problem then ;) If you recognise the programs and use them, just put these lines in rc.conf with "YES".
 
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.
Click to expand...

gonna try
thanks for the COMPAT_FREEBSD6 hint

by the way, this mergemaster -F should be default :p
who doesn't want that?
 
You must log in or register to reply here.
Back
Top