On 11/19/10 17:10, Dave Miner wrote:
60+ successful updates on this U24 says I'm just a really lucky guy :-)
Quite! Actually, AFAIK there are 3 scenarios
1) rpool/ROOT/be-name/opt mounted on /opt
2) Some other dataset mounted on /opt
3) /opt as a directory under /.
It turned out that somehow
On 11/19/10 02:10 PM, Dave Miner wrote:
On 11/19/10 04:59 PM, Shawn Walker wrote:
On 11/19/10 01:52 PM, Dave Miner wrote:
...
Having /opt on a separate dataset can work, as we have systems that were
originally installed that way under 2008.05 when we did create that
separate dataset, and they c
On 11/19/10 04:59 PM, Shawn Walker wrote:
On 11/19/10 01:52 PM, Dave Miner wrote:
...
Having /opt on a separate dataset can work, as we have systems that were
originally installed that way under 2008.05 when we did create that
separate dataset, and they continue to be upgradeable today (I'm writ
On 11/19/10 01:52 PM, Dave Miner wrote:
...
Having /opt on a separate dataset can work, as we have systems that were
originally installed that way under 2008.05 when we did create that
separate dataset, and they continue to be upgradeable today (I'm writing
this on one of them that's running 151a
On 11/19/10 02:49 PM, Frank Middleton wrote:
On 11/19/10 01:42, Shawn Walker wrote:
If you have multiple BEs or ZFS datasets that share the same name that's
going to confuse the heck out of libbe, which in turn is going to create
problems for pkg(1).
Oh I really hope we don't have multiple BE
On 11/19/10 11:49 AM, Frank Middleton wrote:
On 11/19/10 01:42, Shawn Walker wrote:
If you have multiple BEs or ZFS datasets that share the same name that's
going to confuse the heck out of libbe, which in turn is going to create
problems for pkg(1).
Oh I really hope we don't have multiple BE
On 11/19/10 01:42, Shawn Walker wrote:
If you have multiple BEs or ZFS datasets that share the same name that's
going to confuse the heck out of libbe, which in turn is going to create
problems for pkg(1).
Oh I really hope we don't have multiple BEs or ZFS datasets that share
the same name! Th
On 11/18/10 08:58 PM, Frank Middleton wrote:
Got another slightly unhelpful message you might be able to explain:
# pkg image-update --be-name b134b
DOWNLOAD PKGS FILES XFER (MB)
Completed 1601/1601 33161/33161 666.0/666.0
pkg: Unable to clone the current boot environment.
# beadm list
BE Activ
Got another slightly unhelpful message you might be able to explain:
# pkg image-update --be-name b134b
DOWNLOAD PKGS FILESXFER (MB)
Completed 1601/1601 33161/33161 666.0/666.0
pkg: Unable to clone the current boot environm
On 11/17/10 06:25 PM, Frank Middleton wrote:
On 11/17/10 19:57, Shawn Walker wrote:
...
Send me the output of 'pkg list' and 'pkg publisher' privately.
Given the following, I won't waste your time with it unless you
would really like to see them.
Since Bart's reply solved your problem, I do
On 11/17/10 19:57, Shawn Walker wrote:
The failure message you encountered was intentional, if unhelpful.
If you're referring to something else, you'll have to be explicit.
Sorry, mea culpa for trying not to be too verbose.
Is it a bug or a feature that doing an image-update on a non-live
On 11/17/10 16:40, Frank Middleton wrote:
If it is a broken package, does that mean no one else has tried to
do an image-update for SPARC for this release? Hard to believe!
I hope you have some other things to try :-).
Frank -
You're upgrading from build 105, which is two years old, and
preda
On 11/17/10 04:40 PM, Frank Middleton wrote:
On 11/17/10 19:29, Shawn Walker wrote:
That's exactly right. Don't tell me it would have worked without the
--be-name!
Indeed, it should have.
Is that a bug or a feature? :-)
The failure message you encountered was intentional, if unhelpful.
I
On 11/17/10 19:29, Shawn Walker wrote:
That's exactly right. Don't tell me it would have worked without the
--be-name!
Indeed, it should have.
Is that a bug or a feature? :-)
# pkg image-update --be-name snv134b
Creating Plan /
pkg:
'pkg://opensolaris.org/sunwxsun-keytab...@0.5.11,5.11-0
On 11/17/10 04:21 PM, Frank Middleton wrote:
On 11/17/10 19:02, Shawn Walker wrote:
pkg:Naming a boot environment when operating on a non-live image is
not
In short then, you only saw the message because you tried to use
--be-name with something that wasn't the live BE.
That's exactly righ
On 11/17/10 19:02, Shawn Walker wrote:
pkg:Naming a boot environment when operating on a non-live image is not
In short then, you only saw the message because you tried to use
--be-name with something that wasn't the live BE.
That's exactly right. Don't tell me it would have worked without
On 11/17/10 03:42 PM, Frank Middleton wrote:
On 11/17/10 17:01, Shawn Walker wrote:
On 11/17/10 08:14 AM, Frank Middleton wrote:
This gets you
pkg:Naming a boot environment when operating on a non-live image is not
allowed.
Are you using -R / by chance?
Well, IIRC PKG_IMAGE, but isn't that
On 11/17/10 17:01, Shawn Walker wrote:
On 11/17/10 08:14 AM, Frank Middleton wrote:
This gets you
pkg:Naming a boot environment when operating on a non-live image is not
allowed.
Are you using -R / by chance?
Well, IIRC PKG_IMAGE, but isn't that the same? AFAIK that's the only
way to get pk
On 11/17/10 08:14 AM, Frank Middleton wrote:
This gets you
pkg:Naming a boot environment when operating on a non-live image is not
allowed.
Are you using -R / by chance?
-Shawn
___
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.op
Frank Middleton wrote:
> This gets you
>
> pkg:Naming a boot environment when operating on a non-live image is not
> allowed.
>
> Why is this and is there a workaround?
>
> Sorry if it's been asked before but if it has, maybe my Google-fu is off
> today...
When you use the --be-name argument
20 matches
Mail list logo
