On 5/8/08, John W. Bales <[EMAIL PROTECTED]> wrote:
> I forgot to add that the GUI actually *freezes* when the progress bar reads 
> 84%,
> stopping the desktop clock  and rendering all icons and menus unclickable--the
> CDROM drive light and the hard drive light continue to come on and go off at
> regular intervals as if the installer were still operating. However, this 
> behavior
> continues for hours. I left it in this state overnight and it was still in 
> the same state
> in the morning. Pressing Alt-F2, etc. does not bring up  a terminal as in a 
> linux
> install, so I don't know whats going on when it's in this state. The only 
> working key
> combination when it is in this state is Ctrl-F8 which, I think, pertains to 
> alternate
> monitors. When I turn off the computer, remove the CDROM and reboot, I get
> a PBR error. I'm assuming this stands for Primary Boot Record.
>
>  Should installation normally take a couple of hours? This seems a bit 
> excessive.
> It takes an hour and forty minutes to reach the 84% point where the GUI 
> freezes.
> Should it take so long to transfer files from the CDROM to the hard drive?

I installed OpenSolaris 2008.05 on two different machines (a "no
name", and a Sun
Ultra 20) and a virtual machine (under VirtualBox 1.6) without
problem.  Interestingly,
on a third machine I encountered the _very_ same problem as you've described (I
even get the same percentage metric at installation hang: 84%).

This machine is a Fujitsu Siemens "Scenic N/Scenico N" with an Intel Pentium 4
at 1.80GHz, and 512MB of RAM.  Although the installation ends as
described above,
the LiveCD is not working very well, too.  It doesn't crash, but is
unusable.  I mean I
can't use it because it so *slow* launching all kind of applications:
FireFox, GNOME
Terminal, or even UNIX commands from the CLI (psrinfo, for example).

>From the Device Driver Utility, only one device has no corresponding
driver found: a
Intel PRO/100 VM (LOM) Ethernet Controller, which is of no interest
(at least for me).
I can't see any error reported by SMF, the system (dmesg, /var/adm/messages), or
from the local disk (format, iostat).  I just found curious the very
high use of memory.
After booting from the LiveCD, here are some notes I found interesting:

1/ Each time an application is loaded, I can observe a very, very high number of
scan rate (more than 60000). After ten minutes trying to launch two
terminals and
FireFox, I can see a growing number of threads swapped out (more than
40, "kthr:w"
of vmstat).

2/ I found the information obtained from MDB for the 'freelist' very strange:

# echo "::memstat" | mdb -k
Page Summary                Pages                MB  %Tot
------------     ----------------  ----------------  ----
Kernel                      12915                50   10%
Anon                        38189               149   30%
Exec and libs                2117                 8    2%
Page cache                  25614               100   20%
Free (cachelist)             1285                 5    1%
Free (freelist)      781684094486      158913789952  593207482625556480%
Total                      126734               495
Physical                   126733               495

So, is 512MB of RAM an acceptable amount of memory for OpenSolaris 2008.05?
Can this be a (more general) hardware problem?

As a last note, I can say that I am sure of the recorded ISO image (I check the
md5 before to burn it, then dd'it again to disk and check the md5
again).  But when
attempting the same thing from the running LiveCD system, I got an I/O error in
the middle of the dd when trying to create the ISO from the CDROM to
disk (really,
really curious...).


As I can't see nothing about these things on the Release Notes for the
OpenSolaris
2008.05 Release (and currently don't know the origin of the problem),
I just add these
"me too" informations, hoping this will help to track and/or explain
the encountered
problem.

-- 
julien.
http://blog.thilelli.net/
_______________________________________________
opensolaris-help mailing list
[email protected]

Reply via email to