<div dir="ltr"><div>Jim, Alex,<br><br>thanks for your replies. It was, as you both wrote, zone image assigned to previous BE. Quickly rebooted into old BE and retrieved the files. Now I'm off to create another zpool for homedir.<br>
<br></div><div>Thanks again for your help!<br><br>Cheers, Erol<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 26 June 2013 15:58, Jim Klimov <span dir="ltr"><<a href="mailto:jimklimov@cos.ru" target="_blank">jimklimov@cos.ru</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 2013-06-26 15:23, Erol Zavidic wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I had my build zone up and running and started pkg update on GZ. All<br>
went fine, just that I waited with the reboot. I was working on<br>
libmemcached last night late and had some progress there.<br>
<br>
This morning I booted up by desktop (with the new image), booted build<br>
zone and my files are lost, filesystem was reset to state of aprox. two<br>
days ago.<br>
</blockquote>
<br>
<br></div>
Similar to what Alexander wrote, but in more detail: the package update<br>
process may create a snapshot and/or clone of the BEs it changes. Each<br>
BE has a unique GUID (as a ZFS attribute), and zone datasets reference<br>
it so that proper zone filesystem versions are mounted along with the<br>
root BE. I think it is so, at least - though would moderately not make<br>
sense if you didn't pkgupdate the zone environments as well.<br>
<br>
You continued your work in the mounted zone's dataset, but another clone<br>
was mounted after you rebooted. Your work should not be lost, however,<br>
and you should be able to explicitly mount and/or clone and mount the<br>
zone's "current" state and extract those files, or take a light risk and<br>
fix the zbe/root's attributes which link a particular clone dataset to<br>
the "parent BE" GUID, so that your zone with working files is mounted.<br>
<br>
Systematically, it might be better to do development and data storage<br>
not in the BE datasets (global or local zone system datasets), but in<br>
a separately defined and mounted datasets which are not impacted by<br>
beadm and packaging activities. For example, it may be convenient to<br>
lofs-mount the whole /export tree into the local zones (especially if<br>
you are the only user of the machine and/or trust all users equally),<br>
so that user homes are identical in all of your operating environments.<br>
<br>
HTH,<br>
//Jim<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
oi-dev mailing list<br>
<a href="mailto:oi-dev@openindiana.org" target="_blank">oi-dev@openindiana.org</a><br>
<a href="http://openindiana.org/mailman/listinfo/oi-dev" target="_blank">http://openindiana.org/<u></u>mailman/listinfo/oi-dev</a><br>
</div></div></blockquote></div><br></div>