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
> 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 :/
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
mo
[EMAIL PROTECTED] 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
whi
* Peter Rival <[EMAIL PROTECTED]> [2008-07-30 02:50]:
> [EMAIL PROTECTED] 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
> T
On Tue, Jul 29, 2008 at 8:40 PM, Arne Schwabe <[EMAIL PROTECTED]> 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. Th
Stephen Hahn wrote:
> * Peter Rival <[EMAIL PROTECTED]> [2008-07-30 02:50]:
>> 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 t
* Peter Rival <[EMAIL PROTECTED]> [2008-07-30 13:32]:
> 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 figu
[EMAIL PROTECTED] 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
$ fi
* Jyri Virkki <[EMAIL PROTECTED]> [2008-07-30 23:10]:
> [EMAIL PROTECTED] 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 pro
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?
>
>> 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=
[EMAIL PROTECTED] 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
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/fi
> 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 bro
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: reloc
> 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 s
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, <[EMAIL PROTECTED]> wrote:
> > I hadn't noticed the -f to verify; seems unintuitive that it needs
> > a
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. Re
I barely used the UI package manager anyway - thanks for the fixit tip :)
On Thu, Jul 31, 2008 at 7:56 AM, Shawn Walker <[EMAIL PROTECTED]>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 manag
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.
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
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 su
Lurie & other wrote:
>
> I'm having a similar issue but with different files:
FYI I filed
http://defect.opensolaris.org/bz/show_bug.cgi?id=2726
yesterday so those of you interested can add yourself to the cc list.
--
Jyri J. Virkki - [EMAIL PROTECTED] - Sun Microsystems
> 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 d
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. :-(
--
This message posted from opensolaris.org
___
indiana-discuss ma
> 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).
--
This message po
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,
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 d
29 matches
Mail list logo
