Swinstall instances cause kernel corruption?

[Jillian Kee]

Hi,

Is it likely that a kernel corruption might be caused by 2 instances of swinstall during a OS upgrade from 10.20 to 11.00 and thus causing system to panic? One instance of the swinstall is stopped at the analysing stage which has already finished, and the other proceeds with the installation process.

Any answers? Thanks!

[Alex Glennie]

I guess it could be if the swinstall hung : perhaps kernal link files and/or librarys were corrupted ?

Might be worth checking the swinstall log files / var/adm/sw or running swlist -l fileset -a state and check to see if corrupt or partially installed files show up.

[Stefan Farrelly]

Yes, 2 swinstalls running and one is analyzing and one installing doesnt sound good.
In my experience upgrading from 10.20 to 11 is troublesome, much easier to do a straight install to 11, espeically if youre having problems getting the upgrade to work.

[Tim Malnati]

I hope you have your backup tapes ready. First, I'm somewhat curious as to how and why two swinstall processes were running. The swlock should have prevented it. Was this overridden in some way?

Many years ago I performed an upgrade from 9.X to 10.X. After that excursion I promised myself that I would never do a full level upgrade again (and I haven't). In my mind a straight install is the only reliable method. It is difficult enough for any software vendor to get things right for a steady state machine let alone one in transition. There are just far to many possible combinations that your environment may have than could ever be fully analysed.

I'm not sure where you are in this upgrade effort, but if you have some known good backups of the previous environment, I would probably elect to proceed with a new install at this point. Unless there is something specific that needs to be gathered from the old environment, I wouldn't bother with the time and trouble to recover it.

[Cheryl Griffin]

It would be interesting to see what was recorded to the /var/adm/sw/swagent.log.