cindy.swearin...@sun.com wrote: > Hi Seymour, > > I didn't get a chance to reproduce this until today and I noticed > that originally you used zfs destroy to remove the unwanted BE (b99). > > I tested these steps by using beadm destroy with the auto snapshots > running and didn't see the problems listed below. I think your > eventual beadm destroy failed because the original zfs destroy > failed and/or stuff was left mounted.
I suspect there could be something else causing the mount error during that beadm destroy failure. After the failure, its mountpoint was set to an internally created mountpoint, "/tmp/.be.xxxxxx", so that means we tried to mount the BE somewhere to gather data from it, and that mount failed (or a subordinate dataset failed to mount --like /opt or a zone dataset) Seymour, do you have zones on this system? Can you enable debug and try the destroy again? # BE_PRINT_ERR=true I'm also curious as to how the boot environment you're currently booted to (b103pre) shows up as being the 'active on reboot' BE yet its a dependent of b99. If at any point you did a beadm activate of b103pre, it should have promoted b103pre above every other boot environments' datasets. > > With auto snapshots running, do the following: > > 1. Create a new BE > # beadm create opensolaris2 > > 2. Activate the new BE > # beadm activate opensolaris2 > > 3. Reboot to the new BE > > 4. Identify the BEs > # beadm list > BE Active Mountpoint Space Policy Created > -- ------ ---------- ----- ------ ------- > opensolaris - - 6.40M static 2008-11-13 14:38 > opensolaris2 NR / 2.58G static 2008-12-16 14:51 > > 4. Use beadm destroy > # beadm destroy opensolaris > > My test is simpler than your scenario, but it looks to me like beadm > destroy deals correctly with any dependency issues. Yes, its supposed to. We find and promote the "right" clone of the dataset we need to destroy before attempting to destroy it. I've never had issues with beadm destroy wrt dependents, though I don't enable TS on my boot environment datasets. -ethan _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
