>I regularly use less than 5GB for my ABEs on systems with SUNWCall >installed. I suspect you've got some trash on your root partition -- >core and system dumps or huge log files, perhaps?
The initial install is < 5GB but my partitions range from 4.6-8GB. And how they come about doesn't really matter; what matters to me is that in practice I have learned that if I don't allocate 10GB that after a few builds upgrade will fail with "not enough space" because it wants a cushion of 1.5GB. >> I've had upgrades fail and require considerable cleanup with 10GB >> root partitions. So I consider 15GB "ample, but not excessive" >> and 10GB "the absolute minimum". > >Strange. That experience seems extreme to me. Have you filed a bug? Yes, years ago and it has still not been fixed. >> >Minus, of course, the miniroot construction, testing, and the support >> >to make sure that it works from release to release. >> >> But we must do the miniroot construction and testing anyway. > >Yes, but only for initial install. > >Unfortunately, this is another point of bad design: initial install >and upgrade are very different in operation. Hm. Upgrade clearly looks different from install. (But it's a shame we can't just "pkgrm" everything and then "pkgadd" every thing back in) >Better questions would be: > > - Can you use Live Upgrade? > > - If not, then what specific issues are blocking you from using it? Fair enough. >I have no way of knowing. At least for myself, I stopped doing >regular upgrade years ago because it's just too painful and life- >threatening. I've had tons of issues with liveupgrade; far more than with regular upgrade. (Why does live upgrade use find/cpio with all the dangers of copying stuff outside the partition? Are there any cases when liveupgrade actually has to copy more than a particular filesystem or filesystems? Why does it copy more or less random crap from one partition to the other but not all the stuff you might want?) I just find the fact that you suggested doing ludelete/lumake quite awful. For some people the "downtime counts"; but for me the "production time" is more important; that's much longer if you need to ludelete/lumake for each upgrade. >I think the motivation may be to simplify: by removing bits that are >no longer needed. But the argument is that we need the ordinary upgrade installs. liveupgrades are MUCH more operator intensive, they take longer (with less down time) and they are error prone. Forcing liveupgrade on all users will increase TCO. And I am not convinced that the marginal cost savings we may have can even be measured. Casper
