Robert Milkowski wrote:
So in order to regain a disk space, in many cases where several
image-update's were performed, a user will basically have to get rid
of most BEs I think (I haven't thought it thru but I think it is the case).
But of course deleting old BEs may make your system un-upgradable.
http://defect.opensolaris.org/bz/show_bug.cgi?id=10807
http://defect.opensolaris.org/bz/show_bug.cgi?id=11221
And of course if you were foolish enough to upgrade your rpool,
the older BEs might not even boot, and there might not be any
live CD versions that can see it either. As long as the possibility
of this kind of bug exists, the only solution seems to be to keep
snapshots of each BE around, and hope you can restore one
that can still be upgraded. This means you never get to to an
incremental upgrade, /var/pkg/download is completely useless
or you run out of space in a hurry.
I understand that the preceding bugs have been fixed, but IMO
the whole upgrade process architecture needs to be revisited. If
someone actually deleted all their old BEs to gain some space
(say they boot from a 32GB SSD) without making snapshots, or
perhaps updated their rpool so the old BE can't boot, then they
may be completely unable to do an image-update. As a minimum
beadm should be separately updatable. and something needs
to be done about /var/pkg/download. Making it a separate file
system does have a certain appeal and it sounds like it would be
relatively easy to do. Then it could be on a separate data pool
where space might not be at a premium and for SSD users
it would avoid some wear and tear on the SSD itself.
Until now it has been possible to use a current sxce release
to repair a failed image-update, but I understand there may not be
may more of them. IMO the image-update architecture needs to be
looked at as a matter of some urgency before a few irate users start
firing up blogs. The ultimate solution I suppose would be a rescue CD,
but until one exists, I would be wary of deleting old BEs, at least
without keeping a snapshot
Cheers -- Frank
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
