id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
686	EasyPBI cannot clean up .chroot dataset if snapshots exist (PCBSD 9.1)	gja	kris	"I just used EasyPBI under PCBSD 9.1 (DVD x64 version) for the first time and stumbled across a quirk during ""zfs destroy"" after a build is successful.

I tweak my FreeBSD desktops to make zfs snapshots of all mounted zfs datasets every 15 minutes (and delete them every few hours). EasyPBI created a .chroot zfs dataset for its own use when I initiated ""Build PBI"". So now, while EasyPBI is doing its thing, my snapshot'ing script starts creating snapshots of the .chroot dataset every 15min.

When EasyPBI finishes building the local PBI, it trys to ""zfs destroy"" the .chroot dataset and fails. In particular, the log ends with:


{{{
	[...]
  Cleaning /usr/pbi/tetex-base-amd64.chroot
  cannot destroy 'tank1/usr/pbi/tetex-base-amd64.chroot': filesystem has children
  use '-r' to destroy the following datasets:
  tank1/usr/pbi/tetex-base-amd64.chroot@121230_0845
  tank1/usr/pbi/tetex-base-amd64.chroot@121230_0800
  tank1/usr/pbi/tetex-base-amd64.chroot@121230_0900
  tank1/usr/pbi/tetex-base-amd64.chroot@121230_0945
  tank1/usr/pbi/tetex-base-amd64.chroot@121230_0815
  tank1/usr/pbi/tetex-base-amd64.chroot@121230_0915
  tank1/usr/pbi/tetex-base-amd64.chroot@121230_0930
  tank1/usr/pbi/tetex-base-amd64.chroot@121230_0830
}}}


I suspect the solution is for EasyPBI to use ""zfs destroy -r"" rather than ""zfs destroy"", just to catch oddball cases like mine where the .chroot dataset ends up with children that really don't need to survive after the PBI build has succeeded.


"	PBI Packaging Bug	new	minor	9.1	PBI Creator	9.1-RC3		EasyPBI	trac-bugs@…