|
Replies:
37
-
Last Post:
Aug 1, 2008 11:44 AM
by: waynel
|
|
|
Posts:
988
From:
US
Registered:
3/9/05
|
|
|
|
http://pkg.opensolaris.org/ package repository
update (build 94)
Posted:
Jul 29, 2008 5:07 PM
|
|
The OpenSolaris development package repository
http://pkg.opensolaris.org/
has been updated to reflect the changes in snv_94 including an update
to Mozilla Firefox 3.0.1 and fixes to the Caiman "Slim Install" and the
Image Packaging System (IPS). Users who wish to update their system to
the development build can do so using the "image-update" facility
provided by the pkg(1) command. For important information about
"image-update", see the instructions below.
IMPORTANT NOTE: The development builds have undergone limited testing
and users should expect to uncover issues as the next release is
developed.
ISO images are not available for this build.
New packages in this repository update
======================================
SUNWerlang Erlang/OTP R12B-1
SUNWerlang-doc Erlang/OTP R12B-1 Documentation
SUNWircii Internet Relay Chat Client
SUNWlibrsync librsync - software library that implements the
SUNWpampkcs11 The OpenSC PKCS#11 PAM Login Tools
SUNWttf-thai-scalable Scalable Thai TrueType fonts
Known issues in this repository update
======================================
2328 Package Manager no longer can install/update packages
http://defect.opensolaris.org/bz/show_bug.cgi?id=2328
As this time, the Package Manager cannot be used to install or
update packages. When an attempt is made to do so, the
application will display an error to standard output ending
with the line
TypeError: __init__() takes at least 4 non-keyword arguments (3 given)
Work-around:
Use the pkg(1) command to install or update packages on the
system.
Image Packaging System (IPS) specific bugs addressed in this repository update
============================================================================= =
993 random CLI test failures (pkgsend 503, Network not reachable)
1249 create snapshot & be after downloading package
1713 Image.get_matching_fmris should provide access to information about which
1867 'pkg list' takes *WAY* too long
1883 pkg list <fmri_pattern> should allow wildcards for packages name
2164 pkg verify returns 0 when both valid and invalid packages are given
2253 With the latest build of the pkg repo, can't install packages from
2257 "pkg info nopkg testpkg" behaves incorrectly with image which has testpkg
2272 pkgrecv should uncompress by default
2344 fmris could be smaller, faster, better
2363 DotSequences compare strangely
2389 SUNWipkg dependency on SUNWinstall-libs
2403 Need a way to set build numbers package by package
2406 man pages are re-installed every time
2543 eliminate unnecessary stat() calls from gen_installed_pkgs()
2546 image-update -n fails if updated catalogs can't be written
2547 image-update asserts if make_install_plan fails
2554 make install could stand to be quieter
2561 X packages could use some manual dependencies
2578 integrate packagemanager into ips gate
2591 resync repository to snv_94
Caiman installer specific bugs addressed in this repository update
==================================================================
1173 Possible to have two instances of installer GUI running at once
2396 TI Python interface has problems parsing the attributes
Notable distribution specific bugs addressed in this repository update
======================================================================
2600 version of lofi(7D) driver in repository out of sync w/Nevada
Enclosed below are instructions for using "pkg image-update" to update
to the latest OpenSolaris development builds via
http://pkg.opensolaris.org/
For more information on this command and the Image Packaging System
(IPS) technology, refer to the pkg(1), beadm(1M) and pkg(5) manual
pages and the following documents
Getting Started With the Image Packaging System
http://dlc.sun.com/osol/docs/content/IPS/ggcph.html
Upgrading and Managing Your Boot Environments
http://dlc.sun.com/osol/docs/content/IPS/snap3.html
General instructions for updating to the latest OpenSolaris development build
=============================================================================
1) Before using the "image-update" subcommand, it is required that the
latest available version of the IPS software be installed for your
current boot environment (BE)
$ BUILD=`uname -v | sed s/snv_//`
$ pfexec pkg refresh
$ pfexec pkg install SUNWipkg@0.5.11-0.${BUILD}
$ pfexec pkg install entire@0.5.11-0.${BUILD}
2) Verify the build of OpenSolaris in the current BE
$ echo ${BUILD}
3) If you are running build 93 or greater, you can use "image-update"
directly as follows
$ pfexec pkg image-update
At this point, you can boot into the updated BE using reboot(1M) or
init(1M) as usual.
4) If you are using a build prior to 93, it is required one apply the
update directly to an alternate BE in order to work-around
2387 libbe.so:beCopy() frees nvlist variables before using them
http://defect.opensolaris.org/bz/show_bug.cgi?id=2387
First, display the list of the existing BEs on the system
$ beadm list
BE Active Active on Mountpoint Space
Name reboot Used
---- ------ --------- ---------- -----
opensolaris no no - 3.92G
opensolaris-1 yes yes - 17.06M
Next, choose the name of a new BE - if the most recently created BE is
of the form "opensolaris-[N]" where [N] is an integer, then a suitable
choice for the new BE is "opensolaris-[N+1]". If the current BE is
simply "opensolaris", then a suitable name for the new BE is
"opensolaris-1".
In the above example, the new BE would be "opensolaris-2".
Finally, execute the following sequence of commands to create, mount
and update the new BE
$ pfexec beadm create opensolaris-[N+1]
$ mkdir /tmp/mnt$$
$ pfexec beadm mount opensolaris-[N+1] /tmp/mnt$$
$ pfexec pkg -R /tmp/mnt$$ image-update
5) If you are running build 86, the following step is required in order
to work-around
1979 libbe: be_activate needs to run installgrub
http://defect.opensolaris.org/bz/show_bug.cgi?id=1979
>>>>>>>>>> IMPORTANT <<<<<<<<<<
Due to changes in the GRUB boot system, one must manually update the
Master Boot Record (MBR) to include these latest changes. Failure to
follow these instructions when updating from 2008.05 (build 86) to a
later build will result in a system that does not boot by default and
instead the original BE must be manually selected.
Update the GRUB configuration on your ZFS boot device(s) using
$ pfexec /t]]http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
Arne Schwabe
arne@rfc2549.org
|
|
|
|
Re: http://pkg.opensolaris.org/ package
repository update (build 94)
Posted:
Jul 29, 2008 6:40 PM
in response to: comay
|
|
> 3) If you are running build 93 or greater, you can use "image-update"
> directly as follows
>
> $ pfexec pkg image-update
>
I tried updating (system is a snv_93 from the global-iso cd image). This
actually the output of the 2nd try. But the first try had exactly the
same problems :/
[...]
DOWNLOAD PKGS FILES XFER (MB)
SUNWttf-thai-scalable 596/597 0/52 0.00/5.69
PHASE ACTIONS
Removal Phase 4197/4197
Update Phase 1690/7999 Action upgrade
failed for 'usr/share/lib/freetts/cmudict04.jar' (pkg:/SUNWgnome-a11y-libs):
error: Error -3 while decompressing: invalid stored block lengths
pkg:
An unexpected error happened during image-update: Error -3 while
decompressing: invalid stored block lengths
The running system has not been modified. Modifications were only made
to a clone of the running system. This clone is mounted at
/tmp/tmpZHfXjY should you wish to inspect it.
Traceback (most recent call last):
File "/usr/bin/pkg", line 1534, in ?
ret = main_func()
File "/usr/bin/pkg", line 1498, in main_func
return image_update(img, pargs)
File "/usr/bin/pkg", line 412, in image_update
img.imageplan.execute()
File "/usr/lib/python2.4/vendor-packages/pkg/client/imageplan.py",
line 479, in execute
p.execute_update(src, dest)
File "/usr/lib/python2.4/vendor-packages/pkg/client/pkgplan.py", line
292, in execute_update
dest.install(self, src)
File "/usr/lib/python2.4/vendor-packages/pkg/actions/file.py", line
110, in install
shasum = misc.gunzip_from_stream(stream, tfile)
File "/usr/lib/python2.4/vendor-packages/pkg/misc.py", line 224, in
gunzip_from_stream
ubuf = dcobj.decompress(buf)
error: Error -3 while decompressing: invalid stored block lengths
[1] 736 exit 99 pfexec pkg image-update -v
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
41
From:
ES
Registered:
4/2/08
|
|
|
|
Re: http://pkg.opensolaris.org/ package
repository update (build 94)
Posted:
Jul 29, 2008 6:43 PM
in response to: Arne Schwabe
|
|
I also tried to update the system from 93 and everything appeared to be fine. When I rebooted the machine (a Sun Ultra 20 M2), the system wouldn't start and a column with 6 "smile characters" was the only thing that was shown on the screen. I deleted the BE and I'm trying to update the image one more time.
On Wed, Jul 30, 2008 at 3:40 AM, Arne Schwabe <arne at rfc2549 dot org> wrote:
> 3) If you are running build 93 or greater, you can use "image-update"
> directly as follows
>
> $ pfexec pkg image-update
>
I tried updating (system is a snv_93 from the global-iso cd image). This
actually the output of the 2nd try. But the first try had exactly the
same problems :/
[...]
DOWNLOAD PKGS FILES XFER (MB)
SUNWttf-thai-scalable 596/597 0/52 0.00/5.69
PHASE ACTIONS
Removal Phase 4197/4197
Update Phase 1690/7999 Action upgrade
failed for 'usr/share/lib/freetts/cmudict04.jar' (pkg:/SUNWgnome-a11y-libs):
error: Error -3 while decompressing: invalid stored block lengths
pkg:
An unexpected error happened during image-update: Error -3 while
decompressing: invalid stored block lengths
The running system has not been modified. Modifications were only made
to a clone of the running system. This clone is mounted at
/tmp/tmpZHfXjY should you wish to inspect it.
Traceback (most recent call last):
File "/usr/bin/pkg", line 1534, in ?
ret = main_func()
File "/usr/bin/pkg", line 1498, in main_func
return image_update(img, pargs)
File "/usr/bin/pkg", line 412, in image_update
img.imageplan.execute()
File "/usr/lib/python2.4/vendor-packages/pkg/client/imageplan.py",
line 479, in execute
p.execute_update(src, dest)
File "/usr/lib/python2.4/vendor-packages/pkg/client/pkgplan.py", line
292, in execute_update
dest.install(self, src)
File "/usr/lib/python2.4/vendor-packages/pkg/actions/file.py", line
110, in install
shasum = misc.gunzip_from_stream(stream, tfile)
File "/usr/lib/python2.4/vendor-packages/pkg/misc.py", line 224, in
gunzip_from_stream
ubuf = dcobj.decompress(buf)
error: Error -3 while decompressing: invalid stored block lengths
[1] 736 exit 99 pfexec pkg image-update -v
-- Ελευθερία ή θάνατος GPG key: 1024D/FD2229AF fpr: 9E07 D40E 33A5 5993 6FC5 09A8 5BCF B1F2 FD22 29AF
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,361
From:
US
Registered:
8/5/05
|
|
|
|
Re: http://pkg.opensolaris.org/ package
repository update (build 94)
Posted:
Jul 29, 2008 8:06 PM
in response to: Arne Schwabe
|
|
On Tue, Jul 29, 2008 at 8:40 PM, Arne Schwabe <arne at rfc2549 dot org> wrote:
> An unexpected error happened during image-update: Error -3 while
> decompressing: invalid stored block lengths
> The running system has not been modified. Modifications were only made
> to a clone of the running system. This clone is mounted at
> /tmp/tmpZHfXjY should you wish to inspect it.
> Traceback (most recent call last):
I've already opened a bug on this one.
http://defect.opensolaris.org/bz/show_bug.cgi?id=2714
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Praveen Kumar
praveen@sun.com
|
|
|
|
beadm activate issue while upgrade to snv_94
Posted:
Jul 29, 2008 6:43 PM
in response to: comay
|
|
I am running snv_93. I tried upgrading to snv_94. Even though I can use
'pkg image-update' on the image, I did the following so that I can
choose the name of the BE instead of getting some arbitrary number suffix.
$ pfexec beadm create opensolaris-snv_94
$ pfexec beadm mount opensolaris-snv_94 /mnt
$ pfexec pkg -R /mnt image-update -v
$ pfexec beadm unmount opensolaris-snv_94
$ pfexec beadm activate opensolaris-snv_94
beadm: Unable to activate opensolaris-snv_94
Is there a chance that this is a bug?
Thanks -
Praveen
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,361
From:
US
Registered:
8/5/05
|
|
|
|
Re: beadm activate issue while upgrade to snv_94
Posted:
Jul 29, 2008 7:38 PM
in response to: Praveen Kumar
|
|
On Tue, Jul 29, 2008 at 8:43 PM, Praveen Kumar <praveen at sun dot com> wrote:
> I am running snv_93. I tried upgrading to snv_94. Even though I can use
> 'pkg image-update' on the image, I did the following so that I can
> choose the name of the BE instead of getting some arbitrary number suffix.
>
> $ pfexec beadm create opensolaris-snv_94
> $ pfexec beadm mount opensolaris-snv_94 /mnt
> $ pfexec pkg -R /mnt image-update -v
> $ pfexec beadm unmount opensolaris-snv_94
> $ pfexec beadm activate opensolaris-snv_94
> beadm: Unable to activate opensolaris-snv_94
>
> Is there a chance that this is a bug?
I bet you are running into the same thing I have whined about, but
have been told it's not a bug.
http://mail.opensolaris.org/pipermail/indiana-discuss/2008-June/007121.html
Try
pfexec truss beadm activate opensolaris-snv_94
And look for ENOSPC. If it is the same thing, read on.
As I just posted to caiman-discuss and pkg-discuss, it seems as though
the only way to have a good deal of certainty that you will be able to
create, update, and activate a new boot environment, you need to be
sure that you have 2x the amount of free space as the amount of space
used by your active boot environment.
http://mail.opensolaris.org/pipermail/caiman-discuss/2008-July/004739.html
I see this as a bug or at least a really important RFE related to how
"zfs promote" works.
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Praveen Kumar
praveen@sun.com
|
|
|
|
Re: beadm activate issue while upgrade to snv_94
Posted:
Jul 29, 2008 8:06 PM
in response to: mgerdts
|
|
Mike Gerdts wrote:
> On Tue, Jul 29, 2008 at 8:43 PM, Praveen Kumar <praveen at sun dot com> wrote:
>> I am running snv_93. I tried upgrading to snv_94. Even though I can use
>> 'pkg image-update' on the image, I did the following so that I can
>> choose the name of the BE instead of getting some arbitrary number suffix.
>>
>> $ pfexec beadm create opensolaris-snv_94
>> $ pfexec beadm mount opensolaris-snv_94 /mnt
>> $ pfexec pkg -R /mnt image-update -v
>> $ pfexec beadm unmount opensolaris-snv_94
>> $ pfexec beadm activate opensolaris-snv_94
>> beadm: Unable to activate opensolaris-snv_94
>>
>> Is there a chance that this is a bug?
>
> I bet you are running into the same thing I have whined about, but
> have been told it's not a bug.
>
> http://mail.opensolaris.org/pipermail/indiana-discuss/2008-June/007121.html
>
> Try
>
> pfexec truss beadm activate opensolaris-snv_94
>
> And look for ENOSPC. If it is the same thing, read on.
Thanks for pointing in the right direction. That seems to be the problem.
> As I just posted to caiman-discuss and pkg-discuss, it seems as though
> the only way to have a good deal of certainty that you will be able to
> create, update, and activate a new boot environment, you need to be
> sure that you have 2x the amount of free space as the amount of space
> used by your active boot environment.
>
> http://mail.opensolaris.org/pipermail/caiman-discuss/2008-July/004739.html
>
> I see this as a bug or at least a really important RFE related to how
> "zfs promote" works.
praveen@athena:~$ beadm list
BE Active Active on Mountpoint Space
Name reboot Used
---- ------ --------- ---------- -----
opensolaris-snv_93 yes yes / 8.67G
opensolaris-snv_94 no no - 1.03G
Does it mean that I should have atleast 17G free before I can activate
my new be? How am I gonna afford that!
Thanks -
Praveen
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,361
From:
US
Registered:
8/5/05
|
|
|
|
Re: beadm activate issue while upgrade to snv_94
Posted:
Jul 29, 2008 8:17 PM
in response to: Praveen Kumar
|
|
On Tue, Jul 29, 2008 at 10:06 PM, Praveen Kumar <praveen at sun dot com> wrote:
>> As I just posted to caiman-discuss and pkg-discuss, it seems as though
>> the only way to have a good deal of certainty that you will be able to
>> create, update, and activate a new boot environment, you need to be
>> sure that you have 2x the amount of free space as the amount of space
>> used by your active boot environment.
>>
>> http://mail.opensolaris.org/pipermail/caiman-discuss/2008-July/004739.html
>>
>> I see this as a bug or at least a really important RFE related to how
>> "zfs promote" works.
>
> praveen@athena:~$ beadm list
>
> BE Active Active on Mountpoint Space
> Name reboot Used
> ---- ------ --------- ---------- -----
> opensolaris-snv_93 yes yes / 8.67G
> opensolaris-snv_94 no no - 1.03G
>
> Does it mean that I should have atleast 17G free before I can activate my
> new be? How am I gonna afford that!
The 2x is the worst case and assumes that everything will be replaced
in the new BE. However, your new BE only used about 1 GB. Before
"zfs promote" (and similar operations by beadm or pkg) will work you
seem to need 8.67 GB free at the time that the promote is done. As
such, rather than 17 GB the total needed to be able to create,
populate, then activate the BE in this case seems to be 9.70 GB
(before the BE is created). When you get done with it, you will still
have the same amount of free.
The essence of the bug that I believe exists is that an unreasonable
amount of free space is required to do a promote. I don't believe
that there is any point in time or failure mode that actually requires
this space - I think it is an erroneous check in the zfs promote code
path. Then again, I don't know that code so others are certainly
better placed to provide an explanation as to why it is required.
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
2,046
From:
US
Registered:
3/9/05
|
|
|
|
Re: beadm activate issue while upgrade to snv_94
Posted:
Jul 30, 2008 8:25 AM
in response to: mgerdts
|
|
Mike Gerdts wrote:
> On Tue, Jul 29, 2008 at 10:06 PM, Praveen Kumar <praveen at sun dot com> wrote:
>>> As I just posted to caiman-discuss and pkg-discuss, it seems as though
>>> the only way to have a good deal of certainty that you will be able to
>>> create, update, and activate a new boot environment, you need to be
>>> sure that you have 2x the amount of free space as the amount of space
>>> used by your active boot environment.
>>>
>>> http://mail.opensolaris.org/pipermail/caiman-discuss/2008-July/004739.html
>>>
>>> I see this as a bug or at least a really important RFE related to how
>>> "zfs promote" works.
>> praveen@athena:~$ beadm list
>>
>> BE Active Active on Mountpoint Space
>> Name reboot Used
>> ---- ------ --------- ---------- -----
>> opensolaris-snv_93 yes yes / 8.67G
>> opensolaris-snv_94 no no - 1.03G
>>
>> Does it mean that I should have atleast 17G free before I can activate my
>> new be? How am I gonna afford that!
>
>
> The 2x is the worst case and assumes that everything will be replaced
> in the new BE. However, your new BE only used about 1 GB. Before
> "zfs promote" (and similar operations by beadm or pkg) will work you
> seem to need 8.67 GB free at the time that the promote is done. As
> such, rather than 17 GB the total needed to be able to create,
> populate, then activate the BE in this case seems to be 9.70 GB
> (before the BE is created). When you get done with it, you will still
> have the same amount of free.
>
> The essence of the bug that I believe exists is that an unreasonable
> amount of free space is required to do a promote. I don't believe
> that there is any point in time or failure mode that actually requires
> this space - I think it is an erroneous check in the zfs promote code
> path. Then again, I don't know that code so others are certainly
> better placed to provide an explanation as to why it is required.
>
I think part of the problem here is that we may be excessively
aggressive in promoting BE's. With the current behavior you end up with
all snapshots attached to the most recent BE, which exacerbates the
issue, I think. Needs some investigation to determine if we can be
smarter about this.
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,361
From:
US
Registered:
8/5/05
|
|
|
|
Re: beadm activate issue while upgrade to snv_94
Posted:
Jul 30, 2008 8:41 AM
in response to: dminer
|
|
On Wed, Jul 30, 2008 at 10:25 AM, Dave Miner <Dave dot Miner at sun dot com> wrote:
> Mike Gerdts wrote:
>> The essence of the bug that I believe exists is that an unreasonable
>> amount of free space is required to do a promote. I don't believe
>> that there is any point in time or failure mode that actually requires
>> this space - I think it is an erroneous check in the zfs promote code
>> path. Then again, I don't know that code so others are certainly
>> better placed to provide an explanation as to why it is required.
>
> I think part of the problem here is that we may be excessively aggressive in
> promoting BE's. With the current behavior you end up with all snapshots
> attached to the most recent BE, which exacerbates the issue, I think. Needs
> some investigation to determine if we can be smarter about this.
>
> Dave
>
In order to free up the space from that initial installation you will
have to promote one of the others. It is probably better to see the
problem right away rather than after you have potentially
image-updated several times. This goes along the same lines as crash
when I dereference a null pointer rather than doing the 0@0 trick to
push the error off to sometime later when the problem is much more
difficult to figure out.
If you find out right away, you may be able to do something like:
beadm destroy newbe
rm /var/crash/*/*
find /var/tmp -type f -mtime +30 | xargs rm -f
pkg image-update
If you find out later, you need to mirror to a bigger disk (which
bricked the system last time I tried) or backup+destroy+restore.
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
2,046
From:
US
Registered:
3/9/05
|
|
|
|
Re: beadm activate issue while upgrade to snv_94
Posted:
Jul 30, 2008 8:22 AM
in response to: Praveen Kumar
|
|
Praveen Kumar wrote:
> I am running snv_93. I tried upgrading to snv_94. Even though I can use
> 'pkg image-update' on the image, I did the following so that I can
> choose the name of the BE instead of getting some arbitrary number suffix.
>
> $ pfexec beadm create opensolaris-snv_94
> $ pfexec beadm mount opensolaris-snv_94 /mnt
> $ pfexec pkg -R /mnt image-update -v
> $ pfexec beadm unmount opensolaris-snv_94
> $ pfexec beadm activate opensolaris-snv_94
> beadm: Unable to activate opensolaris-snv_94
>
A simpler method, which I use, is:
pkg image-update
beadm activate (old be)
beadm rename (old be-1) (desired-be-name)
beadm activate (desired-be-name)
(The above activate dance is a bug in renaming, IMHO).
Bug 1900 is the RFE for image-update to take a desired BE name as an
optional argument.
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Praveen Kumar
praveen@sun.com
|
|
|
|
Re: beadm activate issue while upgrade to snv_94
Posted:
Jul 30, 2008 9:48 AM
in response to: dminer
|
|
Dave Miner wrote:
> Praveen Kumar wrote:
>> I am running snv_93. I tried upgrading to snv_94. Even though I can
>> use 'pkg image-update' on the image, I did the following so that I can
>> choose the name of the BE instead of getting some arbitrary number
>> suffix.
>>
>> $ pfexec beadm create opensolaris-snv_94
>> $ pfexec beadm mount opensolaris-snv_94 /mnt
>> $ pfexec pkg -R /mnt image-update -v
>> $ pfexec beadm unmount opensolaris-snv_94
>> $ pfexec beadm activate opensolaris-snv_94
>> beadm: Unable to activate opensolaris-snv_94
>>
>
> A simpler method, which I use, is:
>
> pkg image-update
In my case, this step would have failed to activate the new BE because
of lack of disk space. This didn't solve the issue. I had to free up a
lot of space. I uninstalled Sun Studio, OpenOffice, etc to make some
room before I succeeded.
Thanks -
Praveen.
> beadm activate (old be)
> beadm rename (old be-1) (desired-be-name)
> beadm activate (desired-be-name)
>
> (The above activate dance is a bug in renaming, IMHO).
>
> Bug 1900 is the RFE for image-update to take a desired BE name as an
> optional argument.
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
19
From:
US
Registered:
2/23/06
|
|
|
|
Re: http://pkg.opensolaris.org/ package
repository update (build 94)
Posted:
Jul 29, 2008 7:48 PM
in response to: comay
|
|
David dot Comay at Sun dot COM wrote:
> 3) If you are running build 93 or greater, you can use "image-update"
> directly as follows
>
> $ pfexec pkg image-update
After doing this I get the following error twice on boot on my Thinkpad
T61p:
/kernel/drv/amd64/nvidia non-zero sect addr in input file
which matches up with what I see when I look at the file (/mnt is the
nv94 BE):
frival@bar:/$ file /mnt/kernel/drv/amd64/nvidia
file: /mnt/kernel/drv/amd64/nvidia: can't read ELF header
/mnt/kernel/drv/amd64/nvidia: data
frival@bar:/$ file /kernel/drv/amd64/nvidia
/kernel/drv/amd64/nvidia: ELF 64-bit LSB relocatable AMD64 Version 1
If I swap the b93 nvidia module I don't get the error on boot but there
is a version mismatch so X doesn't start correctly either. Since I've
tried this twice and gotten the same result I'm leaning in the direction
of something being wrong with the bits in the repository.
- Pete
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
305
From:
US
Registered:
3/9/05
|
|
|
|
Re: http://pkg.opensolaris.org/
package repository update (build 94)
Posted:
Jul 29, 2008 7:59 PM
in response to: frival
|
|
* Peter Rival <Peter dot Rival at sun dot com> [2008-07-30 02:50]:
> David dot Comay at Sun dot COM wrote:
> > 3) If you are running build 93 or greater, you can use "image-update"
> > directly as follows
> >
> > $ pfexec pkg image-update
>
> After doing this I get the following error twice on boot on my Thinkpad
> T61p:
>
> /kernel/drv/amd64/nvidia non-zero sect addr in input file
>
> which matches up with what I see when I look at the file (/mnt is the
> nv94 BE):
>
> frival@bar:/$ file /mnt/kernel/drv/amd64/nvidia
> file: /mnt/kernel/drv/amd64/nvidia: can't read ELF header
> /mnt/kernel/drv/amd64/nvidia: data
> frival@bar:/$ file /kernel/drv/amd64/nvidia
> /kernel/drv/amd64/nvidia: ELF 64-bit LSB relocatable AMD64 Version 1
>
> If I swap the b93 nvidia module I don't get the error on boot but there
> is a version mismatch so X doesn't start correctly either. Since I've
> tried this twice and gotten the same result I'm leaning in the direction
> of something being wrong with the bits in the repository.
So I just updated my home system--an Ultra 24--from
pkg.opensolaris.org and mine's working fine:
$ pkg search /kernel/drv/amd64/nvidia
INDEX ACTION VALUE PACKAGE
path file kernel/drv/amd64/nvidia pkg:/NVDAgraphics@0.5.11-0.94
$ pfexec pkg verify -v NVDAgraphics
PACKAGE STATUS
pkg:/NVDAgraphics OK
What's pkg verify say on your NVDAgraphics package?
- Stephen
--
sch at sun dot com http://blogs.sun.com/sch/
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
19
From:
US
Registered:
2/23/06
|
|
|
|
Re:
http://pkg.opensolaris.org/ package repository update (build 94)
Posted:
Jul 30, 2008 6:31 AM
in response to: sch
|
|
Stephen Hahn wrote:
> * Peter Rival <Peter dot Rival at sun dot com> [2008-07-30 02:50]:
<snip>
>> After doing this I get the following error twice on boot on my Thinkpad
>> T61p:
>>
>> /kernel/drv/amd64/nvidia non-zero sect addr in input file
>>
>> which matches up with what I see when I look at the file (/mnt is the
>> nv94 BE):
>>
>> frival@bar:/$ file /mnt/kernel/drv/amd64/nvidia
>> file: /mnt/kernel/drv/amd64/nvidia: can't read ELF header
>> /mnt/kernel/drv/amd64/nvidia: data
>> frival@bar:/$ file /kernel/drv/amd64/nvidia
>> /kernel/drv/amd64/nvidia: ELF 64-bit LSB relocatable AMD64 Version 1
>>
>> If I swap the b93 nvidia module I don't get the error on boot but there
>> is a version mismatch so X doesn't start correctly either. Since I've
>> tried this twice and gotten the same result I'm leaning in the direction
>> of something being wrong with the bits in the repository.
>
> So I just updated my home system--an Ultra 24--from
> pkg.opensolaris.org and mine's working fine:
>
> $ pkg search /kernel/drv/amd64/nvidia
> INDEX ACTION VALUE PACKAGE
> path file kernel/drv/amd64/nvidia pkg:/NVDAgraphics@0.5.11-0.94
> $ pfexec pkg verify -v NVDAgraphics
> PACKAGE STATUS
> pkg:/NVDAgraphics OK
>
> What's pkg verify say on your NVDAgraphics package?
Problem solved (more or less). The short form is that the downloaded
file was truncated and pkg was happily laying down the corrupt file.
The long story is that you have to first find the file in
/var/pkg/downloads and then delete it. Me, I did this by greping for
kernel/drv/amd64/nvidia in the NVDAgraphics manifest file and then
taking the filename from the "file=XXX(lots-o-Xs)" and doing a "rm
/var/pkg/downloads/*/*/<filename>". Finding that file with ls takes on
the order of several minutes.
This leads me to ask if pkg shouldn't be checking at least the size if
not the hash of downloaded files before installing them. Perhaps that's
an already open bug but if not either it should be or I hope there's an
easier way to figure this out than what I did.
- Pete
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
305
From:
US
Registered:
3/9/05
|
|
|
|
|
|
Posts:
24
From:
US
Registered:
3/3/07
|
|
|
|
Re: http://pkg.opensolaris.org/ package
repositoryupdate (build 94)
Posted:
Jul 30, 2008 9:41 AM
in response to: comay
|
|
I updated to build 94 without issue, however upon booting into the
environment it did not appear to load the nVidia drivers and the Compiz
window manager failed to load, causing the UI to have all 3d disabled. It
complained about not having an X.org file when trying to re-enable visual
effects and I clicked modify. After doing so I can no longer get the UI to
load when booting build 94. I've reverted to booting from build 93 for now.
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
742
From:
Registered:
7/13/07
|
|
|
|
Re: http://pkg.opensolaris.org/ package
repository update (build 94)
Posted:
Jul 30, 2008 4:08 PM
in response to: comay
|
|
David dot Comay at Sun dot COM wrote:
>
> The OpenSolaris development package repository
>
> http://pkg.opensolaris.org/
>
> has been updated to reflect the changes in snv_94 including an update
Upgrading appeared to go ok, no problems reported and no issues
booting up to the new image, but then
$ firefox
ld.so.1: firefox-bin: fatal: /usr/lib/firefox/libxul.so: corrupt or truncated file
ld.so.1: firefox-bin: fatal: libxul.so: open failed: No such file or directory
ld.so.1: firefox-bin: fatal: /usr/lib/firefox/libxul.so: corrupt or truncated file
ld.so.1: firefox-bin: fatal: libxul.so: open failed: No such file or directory
ld.so.1: firefox-bin: fatal: relocation error: file /usr/lib/firefox/firefox-bin: symbol kPStaticModules: referenced symbol not found
$ pkg verify SUNWfirefox
$
$ elfdump /usr/lib/firefox/libxul.so
/usr/lib/firefox/libxul.so: elf_getehdr failed: Format error: shdr table truncated
I tried 'pkg uninstall SUNWfirefox; pkg install SUNWfirefox' in an
optimistic hope it might get working bits this time, but no change.
--
Jyri J. Virkki - jyri dot virkki at sun dot com - Sun Microsystems
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
305
From:
US
Registered:
3/9/05
|
|
|
|
Re: http://pkg.opensolaris.org/
package repository update (build 94)
Posted:
Jul 30, 2008 5:22 PM
in response to: jyri
|
|
* Jyri Virkki <Jyri dot Virkki at Sun dot COM> [2008-07-30 23:10]:
> David dot Comay at Sun dot COM wrote:
> >
> > The OpenSolaris development package repository
> >
> > http://pkg.opensolaris.org/
> >
> > has been updated to reflect the changes in snv_94 including an update
>
>
> Upgrading appeared to go ok, no problems reported and no issues
> booting up to the new image, but then
>
> $ firefox
> ld.so.1: firefox-bin: fatal: /usr/lib/firefox/libxul.so: corrupt or truncated file
> ld.so.1: firefox-bin: fatal: libxul.so: open failed: No such file or directory
> ld.so.1: firefox-bin: fatal: /usr/lib/firefox/libxul.so: corrupt or truncated file
> ld.so.1: firefox-bin: fatal: libxul.so: open failed: No such file or directory
> ld.so.1: firefox-bin: fatal: relocation error: file /usr/lib/firefox/firefox-bin: symbol kPStaticModules: referenced symbol not found
>
> $ pkg verify SUNWfirefox
>
> $
> $ elfdump /usr/lib/firefox/libxul.so
> /usr/lib/firefox/libxul.so: elf_getehdr failed: Format error: shdr table truncated
What are you getting for the following?
$ pkg contents -m SUNWfirefox | grep libxul.so
file a4079185f8611dc39956221d640c6ef3660c4a9b elfarch=i386 elfbits=32 elfhash=a89c576b0431ce08d04f679666123967103179ee group=bin mode=0755 owner=root path=usr/lib/firefox/libxul.so pkg.size=40961288
$ sha1sum /usr/lib/firefox/libxul.so
a4079185f8611dc39956221d640c6ef3660c4a9b /usr/lib/firefox/libxul.so
If those don't match, then we have a verify bug.
> I tried 'pkg uninstall SUNWfirefox; pkg install SUNWfirefox' in an
> optimistic hope it might get working bits this time, but no change.
I wonder if there's a download caching issue here. You might try
removing /var/pkg/repo/a4/, if it exists, and then repeating (or
verify that this file is not in the cache).
- Stephen
--
sch at sun dot com http://blogs.sun.com/sch/
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
742
From:
Registered:
7/13/07
|
|
|
|
Re: http://pkg.opensolaris.org/ package
repository update (build 94)
Posted:
Jul 30, 2008 6:04 PM
in response to: sch
|
|
Stephen Hahn wrote:
>
> > $ pkg verify SUNWfirefox
> >
> > $
> > $ elfdump /usr/lib/firefox/libxul.so
> > /usr/lib/firefox/libxul.so: elf_getehdr failed: Format error: shdr table truncated
>
> What are you getting for the following?
>
> $ pkg contents -m SUNWfirefox | grep libxul.so
> file a4079185f8611dc39956221d640c6ef3660c4a9b elfarch=i386 elfbits=32 elfhash=a89c576b0431ce08d04f679666123967103179ee group=bin mode=0755 owner=root path=usr/lib/firefox/libxul.so pkg.size=40961288
> $ sha1sum /usr/lib/firefox/libxul.so
> a4079185f8611dc39956221d640c6ef3660c4a9b /usr/lib/firefox/libxul.so
>
> If those don't match, then we have a verify bug.
Indeed, they differ.
$ pkg contents -m SUNWfirefox | grep libxul.so
file a4079185f8611dc39956221d640c6ef3660c4a9b elfarch=i386 elfbits=32 elfhash=a89c576b0431ce08d04f679666123967103179ee group=bin mode=0755 owner=root path=usr/lib/firefox/libxul.so pkg.size=40961288
$ sha1sum /usr/lib/firefox/libxul.so
19f608508476b87c6035aee7aaa09ce496efd477 /usr/lib/firefox/libxul.so
$ ls -la /usr/lib/firefox/libxul.so
-rwxr-xr-x 1 root bin 24055717 2008-07-30 16:06 /usr/lib/firefox/libxul.so
I'll file a bug on verify not noticing this.
> > I tried 'pkg uninstall SUNWfirefox; pkg install SUNWfirefox' in an
> > optimistic hope it might get working bits this time, but no change.
>
> I wonder if there's a download caching issue here. You might try
> removing /var/pkg/repo/a4/, if it exists, and then repeating (or
> verify that this file is not in the cache).
No /var/pkg/repo/ but I deleted /var/pkg/download/a4/ and repeated
'pkg uninstall SUNWfirefox; pkg install SUNWfirefox'
and it downloaded correct bits this time (and firefox now works).
--
Jyri J. Virkki - jyri dot virkki at sun dot com - Sun Microsystems
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
988
From:
US
Registered:
3/9/05
|
|
|
|
Re: http://pkg.opensolaris.org/ package
repository update (build 94)
Posted:
Jul 30, 2008 6:32 PM
in response to: jyri
|
|
>> What are you getting for the following?
>>
>> $ pkg contents -m SUNWfirefox | grep libxul.so
>> file a4079185f8611dc39956221d640c6ef3660c4a9b elfarch=i386 elfbits=32 elfhash=a89c576b0431ce08d04f679666123967103179ee group=bin mode=0755 owner=root path=usr/lib/firefox/libxul.so pkg.size=40961288
>> $ sha1sum /usr/lib/firefox/libxul.so
>> a4079185f8611dc39956221d640c6ef3660c4a9b /usr/lib/firefox/libxul.so
>>
>> If those don't match, then we have a verify bug.
>
> Indeed, they differ.
Does "pkg verify -f" report an error though?
dsc
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
742
From:
Registered:
7/13/07
|
|
|
|
Re: http://pkg.opensolaris.org/ package
repository update (build 94)
Posted:
Jul 30, 2008 7:10 PM
in response to: comay
|
|
David dot Comay at Sun dot COM wrote:
>
> >> If those don't match, then we have a verify bug.
> >
> >Indeed, they differ.
>
> Does "pkg verify -f" report an error though?
Yes:
$ pkg verify SUNWfirefox
$ pkg verify -f SUNWfirefox
PACKAGE STATUS
pkg:/SUNWfirefox ERROR
file: usr/lib/firefox/libxul.so
Unexpected Exception: failed to load dynamic section
I hadn't noticed the -f to verify; seems unintuitive that it needs
a flag to do what one would think 'verify' does. Looks like verify
without -f doesn't do much if it fails to detect truncated files.
Anyway, interactive use aside (where aparte from the unintuitiveness I
don't really mind one way or the other), I guess the real bug here is
that install/image-update needs to be calling the code which does
verify -f in order to avoid silently delivering corrupt files onto disk.
--
Jyri J. Virkki - jyri dot virkki at sun dot com - Sun Microsystems
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
560
From:
GB
Registered:
11/6/06
|
|
|
|
Re: http://pkg.opensolaris.org/ package repository update (build 94)
Posted:
Jul 30, 2008 11:26 PM
in response to: jyri
To: Projects » indiana » discuss
|
|
> I hadn't noticed the -f to verify; seems unintuitive
> that it needs
> a flag to do what one would think 'verify' does.
> Looks like verify
> without -f doesn't do much if it fails to detect
> truncated files.
Agreed, -f should probably be the default.. Otherwise pkg verify OKs an otherwise broken installation...
|
|
|
|
|
Posts:
988
From:
US
Registered:
3/9/05
|
|
|
|
Re: http://pkg.opensolaris.org/ package
repository update (build 94)
Posted:
Jul 30, 2008 11:33 PM
in response to: jyri
|
|
> I hadn't noticed the -f to verify; seems unintuitive that it needs
> a flag to do what one would think 'verify' does. Looks like verify
> without -f doesn't do much if it fails to detect truncated files.
We had a similar discussion earlier today and I believe we came to the
same conclusion: -f should probably be the default.
dsc
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Lee Packham
lp-mailinglists@leen...
|
|
|
|
Re: http://pkg.opensolaris.org/ package
repository update (build 94)
Posted:
Jul 30, 2008 11:51 PM
in response to: comay
|
|
So what do the ones of us that have broken installs now do? I've lost firefox (the libxul error) and the GUI package manager - is there any way out of the mess? On Thu, Jul 31, 2008 at 7:33 AM, <David dot Comay at sun dot com> wrote:
> I hadn't noticed the -f to verify; seems unintuitive that it needs
> a flag to do what one would think 'verify' does. Looks like verify
> without -f doesn't do much if it fails to detect truncated files.
We had a similar discussion earlier today and I believe we came to the
same conclusion: -f should probably be the default.
dsc
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Shawn Walker
swalker@opensolaris....
|
|
|
|
Re: http://pkg.opensolaris.org/
package repository update (build 94)
Posted:
Jul 30, 2008 11:56 PM
in response to: Lee Packham
|
|
Lee Packham wrote:
> So what do the ones of us that have broken installs now do? I've lost
> firefox (the libxul error) and the GUI package manager - is there any
> way out of the mess?
Unfortunately, the packagemanager is broken because the code needs
fixing -- not because of this problem. Remember that you are using a
development repository and so the road may be bumpy from time to time.
You should be able to resolve the firefox error thusly:
pfexec rm -Ir /var/pkg/download
pfexec pkg uninstall SUNWfirefox
pfexec pkg install SUNWfirefox
Thanks for your patience.
Cheers,
--
Shawn Walker
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Lee Packham
lp-mailinglists@leen...
|
|
|
|
Re: http://pkg.opensolaris.org/ package
repository update (build 94)
Posted:
Jul 31, 2008 12:01 AM
in response to: Shawn Walker
|
|
I barely used the UI package manager anyway - thanks for the fixit tip :) On Thu, Jul 31, 2008 at 7:56 AM, Shawn Walker <swalker at opensolaris dot org> wrote:
Lee Packham wrote:
So what do the ones of us that have broken installs now do? I've lost firefox (the libxul error) and the GUI package manager - is there any way out of the mess?
You should be able to resolve the firefox error thusly:
pfexec rm -Ir /var/pkg/download
pfexec pkg uninstall SUNWfirefox
pfexec pkg install SUNWfirefox
Thanks for your patience.
Cheers,
--
Shawn Walker
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
560
From:
GB
Registered:
11/6/06
|
|
|
|
Re: http://pkg.opensolaris.org/ package repository update (build 94)
Posted:
Jul 30, 2008 11:24 PM
in response to: sch
To: Projects » indiana » discuss
|
|
I'm having a similar issue but with different files:
$ firefox
ld.so.1: firefox-bin: fatal: /usr/lib/firefox/libsqlite3.so: corrupt or truncated file
ld.so.1: firefox-bin: fatal: libsqlite3.so: open failed: No such file or directory
ld.so.1: firefox-bin: fatal: relocation error: file /usr/lib/firefox/libxul.so: symbol sqlite3_enable_shared_cache: referenced symbol not found
/usr/lib/firefox/run-mozilla.sh: line 143: 931: Killed
$ pfexec pkg verify -f
...
PACKAGE STATUS
pkg:/SUNWcsl ERROR
file: lib/amd64/libc.so.1
Unexpected Exception: failed to load dynamic section
pkg:/SUNWfirefox ERROR
file: usr/lib/firefox/libsqlite3.so
Unexpected Exception: failed to load dynamic section
...
|
|
|
|
|
Shawn Walker
swalker@opensolaris....
|
|
|
|
Re:
http://pkg.opensolaris.org/ package repository update (build 94)
Posted:
Jul 30, 2008 11:32 PM
in response to: phigamma
|
|
Lurie wrote:
> I'm having a similar issue but with different files:
>
> $ firefox
> ld.so.1: firefox-bin: fatal: /usr/lib/firefox/libsqlite3.so: corrupt or truncated file
> ld.so.1: firefox-bin: fatal: libsqlite3.so: open failed: No such file or directory
> ld.so.1: firefox-bin: fatal: relocation error: file /usr/lib/firefox/libxul.so: symbol sqlite3_enable_shared_cache: referenced symbol not found
> /usr/lib/firefox/run-mozilla.sh: line 143: 931: Killed
>
> $ pfexec pkg verify
> ...
> PACKAGE STATUS
> pkg:/SUNWcsl ERROR
> file: lib/amd64/libc.so.1
> Unexpected Exception: failed to load dynamic section
> pkg:/SUNWfirefox ERROR
> file: usr/lib/firefox/libsqlite3.so
> Unexpected Exception: failed to load dynamic section
Performing this set of steps should resolve (allow you to workaround)
your issue for SUNWfirefox:
1) clear your download cache
pfexec rm -Ir /var/pkg/download
2) reinstall SUNWfirefox
pfexec pkg uninstall SUNWfirefox
pfexec pkg install SUNWfirefox
3) Fix SUNWcsl:
Fixing SUNWcsl is a lot trickier since that's a core system package.
This may help (stolen partially from the release notes) -- ***untested,
please ensure you have valuable date backed up***:
First, display the list of the existing BEs on the system
$ beadm list
BE Active Active on Mountpoint Space
Name reboot Used
---- ------ --------- ---------- -----
opensolaris no no - 3.92G
opensolaris-1 yes yes - 17.06M
Next, choose the name of a new BE - if the most recently created BE is
of the form "opensolaris-[N]" where [N] is an integer, then a suitable
choice for the new BE is "opensolaris-[N+1]". If the current BE is
simply "opensolaris", then a suitable name for the new BE is
"opensolaris-1".
In the above example, the new BE would be "opensolaris-2".
Finally, execute the following sequence of commands to create, mount
and update the new BE
$ pfexec beadm create opensolaris-[N+1]
$ mkdir /tmp/mnt$$
$ pfexec beadm mount opensolaris-[N+1] /tmp/mnt$$
$ pfexec pkg -R /tmp/mnt$$ uninstall SUNWcsl
$ pfexec pkg -R /tmp/mnt$$ install SUNWcsl
Unmount and activate the newly created BE
$ pfexec beadm unmount opensolaris-[N+1]
$ pfexec beadm activate opensolaris-[N+1]
At this point, you can boot into the updated BE using reboot(1M) or
init(1M) as usual.
If the process fails, at least you can fallback to the old boot environment.
Cheers,
--
Shawn Walker
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
560
From:
GB
Registered:
11/6/06
|
|
|
|
Re: http://pkg.opensolaris.org/ package repository update (build 94)
Posted:
Jul 31, 2008 1:28 AM
in response to: Shawn Walker
To: Projects » indiana » discuss
|
|
Thanks, I already had the firefox fixed by extracting the libsqllite3.so from the firefox 3.0.1 contrib package, as for the SUNWcsl, I'll probably wait for a new build and will update from b93 again.
I guess the best way to fix it, is for pkg to verify the checksum upon dowloading/installing.
On the other hand, it would also be great if IPS would have:
$ pfexec pkg repair -f SUNWcsl
|
|
|
|
|
Posts:
773
From:
US
Registered:
8/22/06
|
|
|
|
Re: http://pkg.opensolaris.org/ package
repository update (build 94)
Posted:
Jul 31, 2008 8:39 AM
in response to: Shawn Walker
|
|
Shawn Walker wrote:
> Lurie wrote:
>> I'm having a similar issue but with different files:
>>
>> $ firefox
>> ld.so.1: firefox-bin: fatal: /usr/lib/firefox/libsqlite3.so: corrupt or truncated file
>> ld.so.1: firefox-bin: fatal: libsqlite3.so: open failed: No such file or directory
>> ld.so.1: firefox-bin: fatal: relocation error: file /usr/lib/firefox/libxul.so: symbol sqlite3_enable_shared_cache: referenced symbol not found
>> /usr/lib/firefox/run-mozilla.sh: line 143: 931: Killed
I'm seeing something very similar when attempting to start firefox:
ld.so.1: firefox-bin: fatal: relocation error: file
/usr/lib/firefox/libxul.so: symbol sqlite3_prepare_v2: referenced symbol
not found
/usr/lib/firefox/run-mozilla.sh: line 143: 2175: Killed
"pkg verify" complains about SUNWpython:
PACKAGE STATUS
pkg:/SUNWPython ERROR
file: usr/lib/python2.4/ConfigParser.pyc
Group: 'root' should be 'bin'
Hash: e5d8daa86c36cf9c7ec51124317a7c742e059486 should be
22bf2aab02829e3f10e9e20a3552c0272b79d0a8
file: usr/lib/python2.4/StringIO.pyc ..... --
Group: 'root' should be 'bin'
Hash: fc6e9849bcecd5ba4deb8a00c69fe29a5107758f should be
6edd25462f086eb6de04116d1490228680830a0a
file: usr/lib/python2.4/UserDict.pyc
Group: 'root' should be 'bin'
Hash: cba9b4441554ed6b3a076becfb3ed9e904179f13 should be
4f72be09c9d348e9638761c381009cc55f50912c
[ ... ]
as I understand it, pkg itself makes use of python2.4, so do I need to
re-install SUNWpython into a different BE (which I already have anyway), or
am I hosed, since we don't know whether pkg will do the right thing now
that python may be "bad"?
Michael
--
Michael Schuster http://blogs.sun.com/recursion
Recursion, n.: see 'Recursion'
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Shawn Walker
swalker@opensolaris....
|
|
|
|
Re: http://pkg.opensolaris.org/ package
repository update (build 94)
Posted:
Jul 31, 2008 10:17 AM
in response to: schuster
|
|
Michael Schuster wrote:
> Shawn Walker wrote:
>> Lurie wrote:
>>> I'm having a similar issue but with different files:
>>>
>>> $ firefox
>>> ld.so.1: firefox-bin: fatal: /usr/lib/firefox/libsqlite3.so: corrupt
>>> or truncated file
>>> ld.so.1: firefox-bin: fatal: libsqlite3.so: open failed: No such file
>>> or directory
>>> ld.so.1: firefox-bin: fatal: relocation error: file
>>> /usr/lib/firefox/libxul.so: symbol sqlite3_enable_shared_cache:
>>> referenced symbol not found
>>> /usr/lib/firefox/run-mozilla.sh: line 143: 931: Killed
>
>
> I'm seeing something very similar when attempting to start firefox:
>
> ld.so.1: firefox-bin: fatal: relocation error: file
> /usr/lib/firefox/libxul.so: symbol sqlite3_prepare_v2: referenced symbol
> not found
> /usr/lib/firefox/run-mozilla.sh: line 143: 2175: Killed
>
> "pkg verify" complains about SUNWpython:
>
> PACKAGE STATUS
> pkg:/SUNWPython ERROR
> file: usr/lib/python2.4/ConfigParser.pyc
> Group: 'root' should be 'bin'
> Hash: e5d8daa86c36cf9c7ec51124317a7c742e059486 should be
> 22bf2aab02829e3f10e9e20a3552c0272b79d0a8
> file: usr/lib/python2.4/StringIO.pyc ..... --
> Group: 'root' should be 'bin'
> Hash: fc6e9849bcecd5ba4deb8a00c69fe29a5107758f should be
> 6edd25462f086eb6de04116d1490228680830a0a
> file: usr/lib/python2.4/UserDict.pyc
> Group: 'root' should be 'bin'
> Hash: cba9b4441554ed6b3a076becfb3ed9e904179f13 should be
> 4f72be09c9d348e9638761c381009cc55f50912c
>
> [ ... ]
>
> as I understand it, pkg itself makes use of python2.4, so do I need to
> re-install SUNWpython into a different BE (which I already have anyway),
> or am I hosed, since we don't know whether pkg will do the right thing
> now that python may be "bad"?
You can ignore the pyc file errors, they are caused by Python
recompiling the .py files. See this bug for more information:
2589 pyc files generate lots of verify chaff
http://defect.opensolaris.org/bz/show_bug.cgi?id=2589
Cheers,
--
Shawn Walker
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
742
From:
Registered:
7/13/07
|
|
|
|
|
|
Posts:
2,257
From:
US
Registered:
6/24/05
|
|
|
|
Re: http://pkg.opensolaris.org/ package repository
update (build 94)
Posted:
Aug 1, 2008 2:35 AM
in response to: comay
To: Projects » indiana » discuss
|
|
> 3) If you are running build 93 or greater, you can use "image-update"
> directly as follows
> $ pfexec pkg image-update
> At this point, you can boot into the updated BE using reboot(1M) or
> init(1M) as usual.
> 4) If you are using a build prior to 93, it is required one apply tihe
> update directly to an alternate BE in order to work-around
> 2387 libbe.so:beCopy() frees nvlist variables before using them
> http://defect.opensolaris.org/bz/show_bug.cgi?id=2387
> First, display the list of the existing BEs on the sysem
<snip>
I think many of us would appreciate that some of the fundamental rules in posting notices are being followed:
WARNINGS BEFORE DIRECTIONS!
Step 4 should go before Step 3.
|
|
|
|
|
Posts:
2,257
From:
US
Registered:
6/24/05
|
|
|
|
Re: http://pkg.opensolaris.org/ package repository update (build 94)
Posted:
Aug 1, 2008 2:55 AM
in response to: waynel
To: Projects » indiana » discuss
|
|
Further, after upgrading to build 94, the fonts look . .funny. They look very . . . "un-Solaris". Now Indiana looks like . . . Linux? The good 'ol professional looking is GONE. :-(
|
|
|
|
|
Posts:
2,257
From:
US
Registered:
6/24/05
|
|
|
|
Re: http://pkg.opensolaris.org/ package repository update (build 94)
Posted:
Aug 1, 2008 9:35 AM
in response to: waynel
To: Projects » indiana » discuss
|
|
> Further, after upgrading to build 94, the fonts look
> . .funny. They look very . . . "un-Solaris". Now
> Indiana looks like . . . Linux? The good 'ol
> professional looking is GONE. :-(
The fonts now look pretty good after a reboot (perhaps a restart of X will do, too).
|
|
|
|
|
Posts:
5,829
From:
US
Registered:
3/9/05
|
|
|
|
Re: http://pkg.opensolaris.org/ package
repository update (build 94)
Posted:
Aug 1, 2008 9:42 AM
in response to: waynel
|
|
W. Wayne Liauh wrote:
> Further, after upgrading to build 94, the fonts look . .funny. They look very . . . "un-Solaris". Now Indiana looks like . . . Linux? The good 'ol professional looking is GONE. :-(
They should look like fonts affected by the FreeType 2.3.6 bug that hit
all OS'es, and should look better in build 96 which has FreeType 2.3.7.
Changing the GNOME font appearance preferences from "Best Contrast"
to "Best Shapes" may help.
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
2,257
From:
US
Registered:
6/24/05
|
|
|
|
Re: http://pkg.opensolaris.org/ package repository update (build 94)
Posted:
Aug 1, 2008 11:44 AM
in response to: waynel
To: Projects » indiana » discuss
|
|
Sorry for the outburst. It was almost mid-night (Hawaii time) & I thought I had to go thru the entire image-update process again. But, perhaps thanks to the ZFS, Step 4 (following the mistakenly applied Step 3) took only a few minutes. After the second image-update, I did beadm unamount and destroy of opensolaris-1.
Because of video suspend problem, I'll probably go back to OS 08.05, however. But thanks for the workaround solutions.
|
|
|
|
|
