Oh my god, I think you solved the problem. You are incorrect in that /var/sadm might be getting destroyed in the cloned filesystem, but it *is* /var/sadm related, infact, /var/sadm/system/admin/INST_RELEASE related.
As I stated, my work around was to zpool export the data pool, then zpool import it later. Why does this affect it?! Well... our fileserver has a little crontab (well, a rather big one actually) and one of the things it runs is a shell script called 'host-pull' with a parameterized list of hostnames. The shell script iterates over its commandline arguments, and does an rsync --inplace root at hostname and pulls in /var, /etc, /root. Then a snapshot is taken. Its more or less how we backup our various linux, freebsd, and the 3 solaris servers. LU is finding this /var/sadm deeply nested under /datapool/systems/hosts/hostname/var/sadm/ and getting confused. In fact, I've seen an error when it goes to reboot and tries to update the boot archive in there... (god knows how it finds it.) So. Problem solved. But is this a bug in LU? Should Solaris even be PICKING UP this crap deeply nested in a filesystem somewhere? Is this exploitable? Solaris clearly gets confused or tries to upgrade a backup of /etc, /root, and /var on a data pool, and even tries to update a boot archive there! -- This message posted from opensolaris.org
