upgrading RAIDFRAME systems

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

What's the deal for upgrading systems running RAIDframe?

I have Sparc64 boxes running 4.0 and RAIDframe. Is it
possible to
upgrade these through the regular process, or do I need to
do a clean
install and restore from backups?

Thanks in advance for pointers about what to do/not to do.

dn
iD8DBQFGbZmIyPxGVjntI4IRAhtUAKDYrsFHRq/E5BPSof0Lnzi2eLJ/CwCg
7+KY
gEtkHjL21cFw+T/S3QBdbnM=
=G+gZ
-----END PGP SIGNATURE-----

On Mon, Jun 11, 2007 at 11:50:48AM -0700, David Newman
wrote:
 
> What's the deal for upgrading systems running
RAIDframe?
> 
> I have Sparc64 boxes running 4.0 and RAIDframe. Is it
possible to
> upgrade these through the regular process, or do I need
to do a clean
> install and restore from backups?
> 
> Thanks in advance for pointers about what to do/not to
do.

What I have always done is a "manual" upgrade:

1.  Back up.
2.  Boot in single user mode
3.  # mount -a -t ffs
4.  For each fileset except etcXX.tgz and xetcXX.tgz,
issue:
    # tar xpzf <fileset> -C /
5.  Using etcXX.tgz and xetcXX.tgz, manually update /etc and
/var, and make 
    any other changes, per the upgrade FAQ.  The mergemaster
port/package 
    makes this fairly quick and easy.

On Mon, Jun 11, 2007 at 03:53:49PM -0400, I wrote:
> What I have always done is a "manual"
upgrade:
> 
> 1.  Back up.
> 2.  Boot in single user mode
> 3.  # mount -a -t ffs
> 4.  For each fileset except etcXX.tgz and xetcXX.tgz,
issue:
>     # tar xpzf <fileset> -C /
> 5.  Using etcXX.tgz and xetcXX.tgz, manually update
/etc and /var, and make 
>     any other changes, per the upgrade FAQ.  The
mergemaster port/package 
>     makes this fairly quick and easy.

I am replying to my own post because I neglected to add:

6.  # cd /dev; sh MAKEDEV all
7.  Rewrite boot blocks (arch dependant).

Josh Grosse <joshjggimi.homeip.net> wrote:

> > 5.  Using etcXX.tgz and xetcXX.tgz, manually
update /etc and /var, and make 
> >     any other changes, per the upgrade FAQ.  The
mergemaster port/package 
> >     makes this fairly quick and easy.
> 
> 6.  # cd /dev; sh MAKEDEV all

mergemaster will offer to do this after installing a new
/dev/MAKEDEV.

-- 
Christian "naddy" Weisgerber                      
   naddymips.inka.de

Josh Grosse wrote:
> On Mon, Jun 11, 2007 at 03:53:49PM -0400, I wrote:
>> What I have always done is a "manual"
upgrade:
>> 
>> 1.  Back up.
>> 2.  Boot in single user mode
>> 3.  # mount -a -t ffs
>> 4.  For each fileset except etcXX.tgz and
xetcXX.tgz, issue:
>>     # tar xpzf <fileset> -C /
>> 5.  Using etcXX.tgz and xetcXX.tgz, manually update
/etc and /var, and make 
>>     any other changes, per the upgrade FAQ.  The
mergemaster port/package 
>>     makes this fairly quick and easy.
> 
> I am replying to my own post because I neglected to
add:
> 
> 6.  # cd /dev; sh MAKEDEV all
> 7.  Rewrite boot blocks (arch dependant).

am I missing something, or did you neglect to help him with
his question,
which was about how to upgrade with RAIDframe in use?

I don't see you installing a kernel at all in your process,
RAIDframe or
otherwise...

anyway, to answer the original question:
You will need a custom kernel including the RAIDframe
driver.

Depends on how much of your system is RAIDframed.  If you
got carried
away and did the whole system, I hope you have a spare
machine to build
the new RAIDframe kernel on.  You then use the in-place
upgrade process
in upgrade41.html.

IF you have just (say) /home RAIDframed, you can probably
not mount
the RAIDframe partitions, upgrade, build a new kernel, boot
from it,
and then mount your RAIDframe partitions.

Alternately, if you have some unallocated disk space
available, you
could probably build a temporary work area...but that's not
trivial.

Nick.

On Mon, Jun 11, 2007 at 06:59:46PM -0400, Nick Holland
wrote:
> am I missing something, or did you neglect to help him
with his question,
> which was about how to upgrade with RAIDframe in use?

I had everything except building the kernel, and placing it
on the one (or 
two) non-RAIDFrame controlled partitions for booting.  Yep,
I forgot 
that. :( 

On 6/12/07, Josh Grosse <joshjggimi.homeip.net>
wrote:
> On Mon, Jun 11, 2007 at 06:59:46PM -0400, Nick Holland
wrote:
> > am I missing something, or did you neglect to help
him with his question,
> > which was about how to upgrade with RAIDframe in
use?
>
> I had everything except building the kernel, and
placing it on the one (or
> two) non-RAIDFrame controlled partitions for booting. 
Yep, I forgot
> that. :(
>

I have several low end machines with dual SATA drives and
have the full
install under raidframe with the recommended a=/, b=swap,
d=/usr, etc...
Both drives have separate 4gb partitions which each have a
full install
serve as the boot partition.

1. Backup all data.
2. Disabe raidframe autoconfiguration.
3. Do a full install on the second drive's 4gb partition and
boot on that.
4. Enable raidframe and make install a new kernel.
5. Boot the new version on the second drive.

At this point if everything works you can newfs any of the
pre-upgrade
raid partitions and dump/restore from the new install on the
second
drive to the raid partitions. If you made separate data
partitions that don't
need upgraded you don't have to touch them. Don't forget to
resync the
first boot partition with the second and turn on
autoconfiguration. Oh,
remember to run installboot as part of resyncing (DOH!).

If for some reason you're new install is faulty you can just
resync the
second boot partition with the first (installboot!),
re-enable autoconfig,
and a reboot gets you back to square one.

-N