Frank Middleton wrote:
> The scenario is that you do a zfs recv of a root pool snapshot to
> a spare disk, and it happens to have the same beName as (say)
> the booted root pool. It could even be a copy of it.
Doing this with a snapshot would not cause a BE name collision on
the second pool since it doesn't see snapshots as BE's. However if
what is sent is a clone then yes it's possible to have a name
collision.
That being said since you would be doing this manually and outside
the tools and utilities provided this would not be supportable and
you would be forcing the duplicate name. If you used the -p option
to beadm then the duplicate name would not be allowed and there
would be no issue. The -p option makes use of zfs send/receive and
should be the method used to copy the BE to a second pool.
>
> Currently, AFAIK (have not dared try this), beadm list will
> simply list the two identical names, but there would be no
> method to, e.g., activate the second BE, or even rename it.
This is correct, if you manually added this BE you would have to
manually rename it.
>
> Is this a real problem? There's a "-p" flag on create, but not
> on any of the other commands, so it suggests that pkg -R might
> actually allow --be-name to be set to an existing beName and
> then fail in some horribly obscure way.
pkg -R won't fail with the --be-name option if it's not an already
existing BE name but it does print out an error:
# pkg -R /a image-update --be-name mybe
DOWNLOAD PKGS FILES XFER (MB)
Completed 694/694 15972/15972 454.3/454.3
allowed.
Attempting to use the --be-name option with or without the -R option
produces the same traceback since the BE name already exists. If this
is a bug it's a bug in pkg(5). Shouldn't it be printing out an error
saying that the BE name already exists instead of this traceback?
# beadm mount testBE /a
# pkg -R /a image-update --be-name testBE
Traceback (most recent call last):
File "/bin/pkg", line 2816, in handle_errors
__ret = func(*args, **kwargs)
File "/bin/pkg", line 2750, in main_func
return image_update(img, pargs)
File "/bin/pkg", line 786, in image_update
if not __api_plan_exception(op, noexecute=noexecute):
File "/bin/pkg", line 784, in image_update
update_index=update_index, be_name=be_name)
File "/usr/lib/python2.4/vendor-packages/pkg/client/api.py", line 425, in
plan_update_all
self.__plan_common_exception(
File "/usr/lib/python2.4/vendor-packages/pkg/client/api.py", line 357, in
plan_update_all
self.check_be_name(be_name)
File "/usr/lib/python2.4/vendor-packages/pkg/client/api.py", line 142, in
check_be_name
bootenv.BootEnv.check_be_name(be_name)
File "/usr/lib/python2.4/vendor-packages/pkg/client/bootenv.py", line 210,
in
check_be_name
raise api_errors.DuplicateBEName(be_name)
DuplicateBEName: The boot environment 'testBE' already exists.
pkg: This is an internal error. Please let the developers know about this
problem by filing a bug at http://defect.opensolaris.org and including the
above traceback and this message. The version of pkg(5) is '4190930d418d'.
Thanks,
-evan
