> > >Casper.Dik at Sun.COM writes: > > > I meant: "I don't understand how liveupgrade and > in-place upgrade are > any different from an implementation perspective". > In-place upgrades do a huge amount of space checking since a failure due to in sufficient space would essentially render dead system. These assumptions in the current code are pervasive and complex. Live Upgrade by-passes this code (albeit in a rather ugly manner). If LU was the only way to upgrade, then the simplification around this would be huge. > > It seems that for an additional investment on the > order of 1% of resources > (yes, I mean *one* percent), you can have a common > live upgrade/in-place > upgrade architecture. > > >That's not true. Use 'lumake' to copy the > configuration rather than > >maintaining two independent environments and this > problem goes away. > > > That makes a system "down" in my book; the > performance degradation while > doing a lumake is considerable. > > While for "the testbed" the amount of testing that > needs to be done > goes down, the amount of testing in the field will > drop so dramatically > that any gain will be offset by a dramatic drop in > quality of the > Solaris release. > > Is that a price we are willing to pay? > > In my case it will cause the removal of 3/4 of my > test machines; and I > do find a considerable number of bugs because I have > so many test machines I am assuming you are saying this because of limited disk space ? On x86 systems, a full install takes about 3.3GB. Double that it's 6GB. So what size disks are on these systems ?
-Sanjay > > > And no, I cannot afford to do fresh installs on those > machines either; > I really don't want to have to reinvent the keying > material each time > and carry the considerable burden of doing so. > > (Plus the burden of reinstalling the pieces of > software I still find > important and which are still missing) > > > You can be sure that 80% of the Solaris laptops in > this company will never > by upgraded again. > > (With Windows, Ubuntu and one Solaris partition, > typical people can't spare > another 15GB for an alternate boot environment on > their systems) > > It's the worst possible decision we can make for > Solaris Nevada testing; > and only because we want to skimp on some additional > in-place upgrade > testing. > > And, as far as I can tell, in-place upgrade is > nothing more than: > > - boot from network/DVD media > - establish existing root as "alternate liveupgrade > e root" > - perform liveupgrade > > and this will even work better than current in-place > upgrade because > you no longer have to answer all the questions about > timezones, locales > and root passwords the answers to which the system > ignores anyway. > > But I'd rather have the system support this by itself > rather than requiring > people to cobble something like this together > themselves. > > Some customers care a lot about downtime for *some* > of their systems; but > the enthusiasts really could not careless if it's for > a planned upgrade. > > > Casper > > _______________________________________________ > install-discuss mailing list > install-discuss at opensolaris.org > http://opensolaris.org/mailman/listinfo/install-discus > s > This message posted from opensolaris.org
