On Friday 02 November 2007 01:58:34 am Erik Cederstrand wrote:
> David Yeske wrote:
> > I have a lot of appliances in the field running FreeBSD.  These
> > machines do not have a working compiler.  They need to be upgraded
> > from FreeBSD 4.10 to FreeBSD 6.2.  Has anyone gone through this
> > successfully?  Does anyone have pointers on a clean way to do this?
> > Due to the lack of console support for most of these machines, booting
> > from the 6.2 cd will not work.  This has to be a remote binary
> > upgrade.  I need to have FreeBSD 4.10 install FreeBSD 6.2, although
> > this could be done in stages with multiple reboots.  I want to avoid
> > upgrading from FreeBSD 4.10 to 5.5 to 6.2.  It appears that FreeBSD
> > 6.2 runs just fine on UFS1.
>
> First, I should mention that I have not done something like this before.
> However, I think it would help if you could be a little more specific.
> What are the specs of the machine (CPU, RAM, disk)? How remote are they
> (i.e. "next building" or "Greenland")? How many appliances need
> upgrading? Do you control the network they're attached to?
>
> A couple of ideas:
> 1) As you say, the official advice is 4.10 -> 5.5 -> 6.2. You could
> cross-compile the 5.5 world + kernel on a build machine and
> installworld/kernel on the appliance. Reboot, and repeat for 6.2. This
> assumes you have the disk space for the new world/kernel, or that you
> can at least NFS mount a remote /usr/obj.
>
> 2) If you have the disk space, you can create another partition, place a
> complete 6.2 distribution there (compiled on a build machine) and change
> the boot loader to boot the new partition.
>
> 3) If you are able to PXE boot the machine, you could do a network
> install of the appliance.
>
> 4) If you control the network, you could build a kernel with NFS_ROOT
> support so you're independent on the local disk. Wipe the disk and
> install a new distribution there.
>
> 5) Finally, if you have the RAM, you could build a kernel with MFS_ROOT
> support, place a memdisk image on the local disk and proceed as 4)
>
> Erik

Just in case there is any doubt, a remote upgrade from source is more involved 
than 4.10 -> 5.5 -> 6.2

The supported upgrade path across major version numbers has always been from 
the last release of the old to the first release of the new, and in the 5.x 
era there wasn't a direct upgrade path from 5.0 -> 5.5, you needed to do 
5.0 -> 5.3 -> 5.5 so your upgrade path from source really is....

4.10 -> 4.11 -> 5.0 -> 5.3 -> 5.5 -> 6.0 -> 6.2

There may be cases where you can skip a step, but then you venture in to the 
land of unsupported upgrades.

I'm not suggesting you go this route, just giving you more motivation to 
explore other options!

-- 
Thanks,

Josh Paetzel

PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to