On 10/ 6/09 02:29 PM, Shawn Walker wrote:
Which /var/pkg/download was not empty? The one in '/var/pkg/download'
or did you mount the new boot environment immediately after image
update and check to see if its /var/pkg/download was empty?
The /var/pkg/download at '/' that is present immediate after
image-update is complete (before you reboot) should *not* be empty.
It would never have occurred to me to mount the new BE after doing
image-update, so perhaps that's why I'm not being clear. No idea what
was in /var/pkg/download before rebooting; it was not empty afterwards.
Is there some post-boot process that empties it? If so, there was no i/o
going on at all (zpool iostat showed all zeros) before doing rm -rf).
Because of the beadm bug, did something like the following quite a few
times, although did step 6 only once, going from snv111b to snv124.
1. Restore snv111b baseline snapshot and boot it
2. Destroy all snapshots and all but the current BE (snv111b)
3. rm -rf /var/pkg/download
4. pkg image-update (fails as expected because pkg version is old)
5. update pkg
6. pkg set-property flush-content-cache-on-success true
7. pkg image-update (fails because it can't find rpool/boot/menu.lst)
8. mkdir rpool/boot; touch rpool/boot/menu.lst
9. pkg image-update (succeeds)
10. reboot
11. do post-update administration and make a baseline snapshot
12. Start zpool iostat and observe negligible activity
13. Notice that the rpool is much bigger than expected and
see that /var/pkg/download is still there
14. Destroy baseline snapshot, rm -rf /var/pkg/download/....
Now the beadm bug has been fixed, it should be possible to go
directly from snv124 to snv125. Are there any additional steps
that you'd like to see done when doing this update? If the
menu.lst problem has been fixed, maybe the update will succeed
in one cycle...
... moving all of /var to another pool and see what happens....
Don't do that. It will break.
OK, I won't. Is there anything specfic, or are there a slew of things
that would cause problems? Curious because the text mode installer
for sxce snv123 specifically has an option to have /var in a separate
dataset, so presumably the issues are unique to Open Solaris. Without
moving most of /var it will be impossible to go from snv124 to snv125
using a 16GB disk - time to replace it with a 32Gb ssd :-). I guess the
issues are actually pretty obvious. Any idea when the cache options
will be available?
Thanks -- Frank
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
