Seymour Krebs wrote:
> Ethan,
>
> 1. No zones.
>
> 2. with BE_PRINT_ERR=true (sorry destroy now works)
>
> ~# beadm list
> BEActive Mountpoint SpacePolicy Created
> ---- -- --- ---
> b101b - - 6.14G
Ethan,
1. No zones.
2. with BE_PRINT_ERR=true (sorry destroy now works)
~# beadm list
BEActive Mountpoint SpacePolicy Created
---- -- --- ---
b101b - - 6.14Gstatic 2008-11-14 09:17
b103pre NR
1. sorry for the delay in replying.
2. the reason that I was originally using zfs destroy was that beadm destroy
failed.
3. Current state of affairs:
~# beadm list
BEActive Mountpoint SpacePolicy Created
---- -- --- ---
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 proble
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 des
>> we should either promote immediately on creation, or perhaps beadm destroy
>> could do the promotion behind the covers.
>> - Tim
> If I understand this right, the latter option looks
> better to me. Why
> consume the disk space before you have to?
> What does LU do?
> -Kyle
However, if you
On Tue, 9 Dec 2008, Tim Haley wrote:
>
> ludelete doesn't handle this any better than beadm destroy does, it
> fails for the same reasons. lucreate does not promote the clone it
> creates when a new BE is spawned, either.
Live upgrade's luactivate command is meant to promote the BE during init 6
Kyle McDonald wrote:
> Tim Haley wrote:
>> Ross wrote:
>>
>>> While it's good that this is at least possible, that looks horribly
>>> complicated to me.
>>> Does anybody know if there's any work being done on making it easy to
>>> remove obsolete
>>> boot environments?
>>>
>> If the cl
Tim Haley wrote:
> Ross wrote:
>
>> While it's good that this is at least possible, that looks horribly
>> complicated to me.
>> Does anybody know if there's any work being done on making it easy to remove
>> obsolete
>> boot environments?
>>
>
> If the clones were promoted at the time
Ross wrote:
> While it's good that this is at least possible, that looks horribly
> complicated to me.
> Does anybody know if there's any work being done on making it easy to remove
> obsolete
> boot environments?
If the clones were promoted at the time of their creation the BEs would
stay i
While it's good that this is at least possible, that looks horribly complicated
to me. Does anybody know if there's any work being done on making it easy to
remove obsolete boot environments?
--
This message posted from opensolaris.org
___
zfs-discuss
Will, thanks for the info on the 'zfs get origin' command. I had previously
tried to promote the BEs but saw no effect. I can now see with 'origin' that
there is a sequential promotion scheme and some fo the BEs had to be promoted
twice to free them from their life of servitude and disgrace.
On Mon, Dec 8, 2008 at 13:03, Seymour Krebs <[EMAIL PROTECTED]> wrote:
> ~# zfs destroy -r rpool/ROOT/b99
> cannot destroy 'rpool/ROOT/b99': filesystem has dependent clones
Take a look at the output of "zfs get origin" for the other
filesystems in the pool. One of them is a clone of rpool/ROOT/b99
Please if anyone can help with this mess, I'd appreciate it.
~# beadm list
BE Active Mountpoint SpacePolicy Created
-- -- -- --- ---
b100- - 6.88Gstatic 2008-10-30 13:59
b101a - - 960.
14 matches
Mail list logo
