Re: [osol-discuss] Nevada and VMware Woes

[Kevin Duffey]

Sorry Steve, I honestly don't know. I have yet to install a 64-bit Solaris on 
bare metal, so not sure if it takes a lot longer to boot than 32-bit, but I am 
guessing not by much. If we find anything out, I'll report back to this list 
regarding the issue. Glad you have a work-a-round for the time being.


- Original Message 
From: Steven Stallion <[EMAIL PROTECTED]>
To: Kevin Duffey <[EMAIL PROTECTED]>
Cc: opensolaris-discuss@opensolaris.org
Sent: Thursday, November 29, 2007 9:14:00 PM
Subject: Re: [osol-discuss] Nevada and VMware Woes


Thanks for the response Kevin.

It appears that the issue is indeed 64bit booting in Nevada.

This time around I modified my grub config to boot the 32bit kernel
(easily accomplished by removing $ISADIR as in Ian Murdock's post) -
this seems to have fixed the issue.

Any ideas if VMware/Sun is aware of the issue and is working to resolve
it? I have not decided yet whether sacrificing 64bit support is worth
switching over to Nevada from Solaris 10, so well see.

Thanks!

Steve


Kevin Duffey wrote:
> Hi Steve,
> 
> I am working with the Virtual Appliance group here at Sun. We are
> presently using VMWare Fusion 1.1 as well. I recall having a similar
> issue with the long delay. My colleague had a different image that
> booted up quite fast. The only thing we can think of is that the
 64-bit
> version of the OS seems to take forever to boot. The 32-bit install
> comes up within a minute or so. You may want to check to see if your
> installing the 64-bit version or not. My colleague wrote a little bit
> about it, not sure it will help:
> 
> http://blogs.sun.com/edwingo/entry/installing_sxde_on_vmware_fusion
> 
> There may also be a log file that you can examine to see what might
 be
> the hangup if there is one. I'd be interested in knowing as well if
> there is some issue other than the 64-bit kernel just requiring a lot
> more time booting.
> 
> Hope that helps.
> 
> 
> - Original Message 
> From: Steven Stallion <[EMAIL PROTECTED]>
> To: opensolaris-discuss@opensolaris.org
> Sent: Wednesday, November 28, 2007 11:08:55 PM
> Subject: Re: [osol-discuss] Nevada and VMware Woes
> 
> Sorry for the self-reply, but I thought of one more detail that may
 be
> useful:
> 
> After the system is installed, if I boot into failsafe, the long
 pause
> does not occur.
> 
> Steve
> 
> Steven Stallion wrote:
>> All,
>>
>> For quite some time now, I have run snv builds through VMware
>> Workstation 5 & 6 without any problems.
>>
>> Lately, I've been using VMware Fusion 1.1 (Stable) on my MacBook
 Pro. I
>> have noticed some rather odd behavior:
>>
>> After the kernel banner (and subsequent console font change), there
 is a
>> very long (and inconsistent) pause which can take anywhere from 5 to
 15
>> minutes; during this time a ridiculous amount of processor time is
 taken
>> up on both cores (the VM is currently configured for 2 virtual
>> processors). Once the system is fully booted, it is business as
 usual -
>> except for the long wait, and a piping hot laptop ;)
>>
>> The strange thing is, this behavior is not present during
 installation,
>> only after the system has been installed and rebooted. I have tried
>> numerous configuration options in VMware, including forcing 32bit
>> behavior, using a single virtual processor, and tweaking dma
 defaults in
>> eeprom in the event this could be some odd virtual controller issue
 -
>> still no luck!
>>
>> Solaris 10 8/07 runs like a charm with the same VM configuration.
>>
>> Any Fusion users out there notice similar behavior? Anyone have any
>> ideas or tips on how I could resolve this issue?
>>
>> Thanks in Advance,
>>
>> Steve
>>
> 
> -- 
> Yet magic and hierarchy
> arise from the same source,
> and this source has a null pointer.
> 
> Reference the NULL within NULL,
> it is the gateway to all wizardry.
> ___
> opensolaris-discuss mailing list
> opensolaris-discuss@opensolaris.org
> 
> 
> 
>
 
> Be a better pen pal. Text or chat with friends inside Yahoo! Mail.
 See
> how.
 

-- 
Yet magic and hierarchy
arise from the same source,
and this source has a null pointer.

Reference the NULL within NULL,
it is the gateway to all wizardry.






  

Be a better sports nut!  Let your teams follow you 
with Yahoo Mobile. Try it now.  
http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] LDOM ldmd refuses to start

[Doug Baker - Sun UK - Support Engineer]

Lisa wrote:
> I have a T2000 (SUNW,Sun-Fire-T200) with firmware 6.4.6 and with all LDOM 
> required patches. I installed LDoms_Manager-1_0_1, but ldmd crashes and dumps 
> core during startup (see error below) (fatal error: HV MD major version 
> mismatch: found version 0, can only support version 1.)
> 
> Can anyone tell what is going on?

LDOMs 1.0.1 requires the 6.5.x firmware from patch 127576

The links to the latest firmware patches for all the Sparc and some x86 systems 
are available from Infodoc 18474

http://sunsolve.sun.com/search/document.do?assetkey=1-9-18474-1

Regards,

Douglas

> 
> # svcs -xv
> svc:/ldoms/ldmd:default (Logical Domain Manager)
>  State: maintenance since Sat Dec 01 15:05:12 2007
> Reason: Start method failed repeatedly, last exited with status 1.
>See: http://sun.com/msg/SMF-8000-KS
>See: /var/svc/log/ldoms-ldmd:default.log
> Impact: This service is not running.
> 
> svc:/ldoms/vntsd:default (virtual network terminal server)
>  State: maintenance since Sat Dec 01 15:05:07 2007
> Reason: Start method failed repeatedly, last exited with status 1.
>See: http://sun.com/msg/SMF-8000-KS
>See: man -M /usr/share/man -s 1M vntsd
>See: /var/svc/log/ldoms-vntsd:default.log
> Impact: This service is not running.
> 
> # /opt/SUNWldm/bin/ldmd_start 
> Added to channel ds, service dr-cpu, versions 1.0 
> Added to channel ds, service fma-cpu-service, versions 1.0 
> Added to channel fmactl, service fma-phys-cpu-service, versions 1.0 
> Added to channel ds, service fma-mem-service, versions 1.0 
> Added to channel fmactl, service fma-phys-mem-service, versions 1.0 
> Added to channel fmactl, service fma-pri-service, versions 1.0 
> Added to channel spds, service mdstore, versions 1.0 
> Added to channel ds, service md-update, versions 1.0 
> Added to channel ds, service domain-shutdown, versions 1.0 
> Added to channel ds, service domain-panic, versions 1.0 
> Added to channel spds, service pri, versions 1.0 
> Added to channel ds, service var-config, versions 1.0 
> fatal error: HV MD major version mismatch: found version 0,
> can only support version 1.
>  
>  
> This message posted from opensolaris.org
> ___
> opensolaris-discuss mailing list
> opensolaris-discuss@opensolaris.org


-- 
D. J. Baker
Sun Microsystems Systems Support Engineer.
UK Mission Critical Solution Centre.
Tel : 0870 600 3222
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] frequency scalling in opensolaris

[Dr. David Kirkby]

> Try adding the following to your /etc/power.conf
> file:
> 
> cpupm enable
> cpu-threshold 15s
> 
> I believe these keywords are in the the power.conf(4)
> man page shipping 
> with snv_70b.
> 
> Then execute /usr/pmconfig. I think you'll find that
> code has already 
> been written to reduce the speed of your CPU. And
> we're working on 
> improving it and Solaris power management in general.
> We've got a bit of 
> catching up to do.
> 
> Mark

Hi, 
after adding those commands, and executing /usr/sbin/pmconfig, the clock rate 
in my laptop does change up/down, so it appears to work. I've seen it running 
at 1.000, 1.333, 1.667 and 2.000 GHz which are all the supported frequencies. 

This Sony Vaio VGN-SZ4XWN/C laptop is rather odd in that it has two graphics 
chips - both a low power/low performance Intel GMA 950 chipset and a higher 
performance, but more power hungry Nvida GeForce Go 7400 GPU. There is  a 
switch on the front panel which selects which one is used (under Vista, one 
needs a reboot for it to change). I'[ll have to try to get the integrated 
chipset to work, as I think that will save quite a bit of power. I notice under 
Vista the laptop runs much hotter if the GeForce GPU is used. But during the 
Solaris install, it reported my graphics was unsupported when I had the switch 
in the 'Stamina' (i.e. Intel GMA 950) position, so I had to switch to the 
'Speed' (i.e. Nvida) position. Since installation, it boots in either position, 
but I *think* it is using the power hungry Nvida all the time. 

Also I notice this in /var/adm/messages: 

[ID 314293 kern.info] device pci8086,[EMAIL PROTECTED](display#0) keeps up 
device [EMAIL PROTECTED],0(sd#0), but the latter is not power managed

I suspect there are a few things that eat the power which with some effort can 
probably be reduced - just needs a bit of tweaking in places. 

Thanks for your help. I seem to be making some progress with this now. 

It's amazing how much quicker this 2 GHz dual core laptop with 2 GB of RAM is 
under Solaris than Vista. It is not old (< 6 months old) and was not a budget 
laptop (cost around $3200), but the combination of Vista and Sony's useless 
software made it run rather slowly.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Wireless drivers tries to set Tx power when it knows transmitter is off

[Dr. David Kirkby]

I have a Sony VGN-SZ4XWN/C laptop, which has integrated WiFi. The WiFi 
basically works - I am sending this post via the WiFi. It uses the Intel 
PRO/Wireless 3945ABG chip.

There is a switch on the front panel to turn the transmitter on/off. Trying to 
boot with this in the off position is problematic at best, with it often 
printing almost endless error messages on the scrren. 

So I tend to keep the wireless on, even if on a train with no hope of using 
WiFi. Then I get an irritating popup evey time the train passes a wireless 
transmitter. 

Looking at /var/adm/messages below one can deduce transmitter is off, then 
surprise suprise it can't set the power. 

Nov 26 22:14:36 kingfisher wpi: [ID 644114 kern.notice] NOTICE: wpi: Radio 
transmitter is off
Nov 26 22:14:38 kingfisher mac: [ID 486395 kern.info] NOTICE: wpi0 link down
Nov 26 22:14:40 kingfisher wpi: [ID 644114 kern.notice] NOTICE: wpi: Radio 
transmitter is off
Nov 26 22:14:42 kingfisher wpi: [ID 514036 kern.warning] WARNING: wpi_config(): 
failed to set txpower
Nov 26 22:14:42 kingfisher wpi: [ID 913098 kern.warning] WARNING: wpi_init(): 
failed to configure device
Nov 26 22:14:44 kingfisher wpi: [ID 644114 kern.notice] NOTICE: wpi: Radio 
transmitter is off
Nov 26 22:14:46 kingfisher wpi: [ID 514036 kern.warning] WARNING: wpi_config(): 
failed to set txpower
Nov 26 22:14:46 kingfisher wpi: [ID 913098 kern.warning] WARNING: wpi_init(): 
failed to configure device
Nov 26 22:14:48 kingfisher wpi: [ID 644114 kern.notice] NOTICE: wpi: Radio 
transmitter is off
Nov 26 22:14:50 kingfisher wpi: [ID 514036 kern.warning] WARNING: wpi_config(): 
failed to set txpower
Nov 26 22:14:50 kingfisher wpi: [ID 913098 kern.warning] WARNING: wpi_init(): 
failed to configure device

Is there any special actions one should take to enable/disable the wireless on 
a laptop? Just using the on/off switch on the top does not work too well for 
me. 

Dave
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] "Indiana" review

[UNIX admin]

The unthinkable has happened: SunOS backwards compatibility has been broken.

Broken:

`uname -a` returns some funky "opensolaris bla bla bla" string instead of the 
standard
SunOS hostname 5.11 snv_## i86pc i386 i86pc.

Broken:
root's home directory is in /root; this is a SEVERE ERROR. We're not on Linux, 
and this isn't Linux land!

Broken:
all my System V compliant packages are no longer installable, instead `pkgadd` 
exits with exit code 1 (fatal error), because /var/sadm/install/contents is 
empty.

Broken:
after the installation, the system was rendered unbootable. I had to go into 
the BIOS and play Russian roulette (I have four identical drives) to find the 
drive "Indiana" was on, and edit GRUB lines with the correct "root (hd3,0,a)" 
to be able to boot. No trace of detecting Windows XP professional on my first 
drive (this is a documented issue though, but the first one isn't).

Broken:
even after editing /boot/grub/menu.lst, GRUB still "wouldn't take"; changes 
weren't visible in the GRUB boot menu.

Broken:
default shell given to root and to myself is /bin/bash; this is a SEVERE ERROR 
(the worst of all). Not only do I not want to have to go and modify the system 
to remove that bash GARBAGE of a shell, it's unacceptable to have to do that 
for every engineering cycle of a new build.

As an added "bonus", we'll have BASH garbage scripts, incompatible with 
Bourne-family shells, be encouraged and propagate -- on Solaris. The future 
looks just LOVELY in that respect.

If this is the future that awaits us, I shudder at it. If I wanted to run a 
*UNIX-like* operating system, I'd go ahead and run that GNU/Linux garbage, not 
SunOS!
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[UNIX admin]

Oh yeah: and I can no longer log in as root. On the CONSOLE. Because if I 
create an account for myself during the install, root will be turned into a 
"role".

If that wasn't bad enough, it's not a sudo role, that I could use and transfer 
to HP-UX or IRIX, or AIX, oh no.
We have to be stubborn and plough on with RBAC, which is overcomplicated and a 
nightmare to set up and administer, even for people like me who've used Solaris 
for 12+ years. As an added bonus, RBAC doesn't exist on any other UNIX(R) 
system, so all the work I do with it I can't use on another UNIX(R) system. 
Lovely.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[Lukas Oboril]

Hi

On Dec 2, 2007 12:50 PM, UNIX admin <[EMAIL PROTECTED]> wrote:
> The unthinkable has happened: SunOS backwards compatibility has been broken.
>
> Broken:
>
> `uname -a` returns some funky "opensolaris bla bla bla" string instead of the 
> standard
> SunOS hostname 5.11 snv_## i86pc i386 i86pc.
>
> Broken:
> root's home directory is in /root; this is a SEVERE ERROR. We're not on 
> Linux, and this isn't Linux land!
>

This is debatable ... Can you provide pros and cons for this from your
point of view?


> Broken:
> all my System V compliant packages are no longer installable, instead 
> `pkgadd` exits with exit code 1 (fatal error), because 
> /var/sadm/install/contents is empty.
>

I believe that will be fixed.

> Broken:
> after the installation, the system was rendered unbootable. I had to go into 
> the BIOS and play Russian roulette (I have four identical drives) to find the 
> drive "Indiana" was on, and edit GRUB lines with the correct "root (hd3,0,a)" 
> to be able to boot. No trace of detecting Windows XP professional on my first 
> drive (this is a documented issue though, but the first one isn't).
>

Same as previous.

> Broken:
> even after editing /boot/grub/menu.lst, GRUB still "wouldn't take"; changes 
> weren't visible in the GRUB boot menu.
>
> Broken:
> default shell given to root and to myself is /bin/bash; this is a SEVERE 
> ERROR (the worst of all). Not only do I not want to have to go and modify the 
> system to remove that bash GARBAGE of a shell, it's unacceptable to have to 
> do that for every engineering cycle of a new build.
>

Yes, why we don't have Bourne or KornShell93  as default. I vote
against Bash. This is really terrible.

> As an added "bonus", we'll have BASH garbage scripts, incompatible with 
> Bourne-family shells, be encouraged and propagate -- on Solaris. The future 
> looks just LOVELY in that respect.

Same, I hate bash too.

>
> If this is the future that awaits us, I shudder at it. If I wanted to run a 
> *UNIX-like* operating system, I'd go ahead and run that GNU/Linux garbage, 
> not SunOS!
>
>
:(


-- 
Lukas 'Luc' Oboril
IRC nickname: luc^ at freenode


When dealing with people, let us remember we are not dealing with
creatures of logic. We are dealing with creatures of emotions,
creatures bristling with prejudices and motivated by pride and vanity.
  Dale Carnegie
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[Lukas Oboril]

On Dec 2, 2007 1:00 PM, UNIX admin <[EMAIL PROTECTED]> wrote:
> Oh yeah: and I can no longer log in as root. On the CONSOLE. Because if I 
> create an account for myself during the install, root will be turned into a 
> "role".
>
> If that wasn't bad enough, it's not a sudo role, that I could use and 
> transfer to HP-UX or IRIX, or AIX, oh no.
> We have to be stubborn and plough on with RBAC, which is overcomplicated and 
> a nightmare to set up and administer, even for people like me who've used 
> Solaris for 12+ years. As an added bonus, RBAC doesn't exist on any other 
> UNIX(R) system, so all the work I do with it I can't use on another UNIX(R) 
> system. Lovely.

Someone must be the First

-- 
Lukas 'Luc' Oboril
IRC nickname: luc^ at freenode


When dealing with people, let us remember we are not dealing with
creatures of logic. We are dealing with creatures of emotions,
creatures bristling with prejudices and motivated by pride and vanity.
  Dale Carnegie
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[Gary Gendel]

> The unthinkable has happened: SunOS backwards
> compatibility has been broken.
> 
> Broken:
> 
> `uname -a` returns some funky "opensolaris bla bla
> bla" string instead of the standard
> SunOS hostname 5.11 snv_## i86pc i386 i86pc.

Understandable change for a non Sun OS. But I tend to agree that this will make 
things bad for current scripts.

> Broken:
> root's home directory is in /root; this is a SEVERE
> ERROR. We're not on Linux, and this isn't Linux
> land!

I actually find this a blessing since all the window manager garbage doesn't go 
to /.

> Broken:
> all my System V compliant packages are no longer
> installable, instead `pkgadd` exits with exit code 1
> (fatal error), because /var/sadm/install/contents is
> empty.

It's worse than that.  For example SunStudio can't install using pkg because of 
missing dependencies in the base system.  I think the plan is to provide new 
packages.  The pkg "refresh" did fix a lot of problems.

> Broken:
> after the installation, the system was rendered
> unbootable. I had to go into the BIOS and play
> Russian roulette (I have four identical drives) to
> find the drive "Indiana" was on, and edit GRUB lines
> with the correct "root (hd3,0,a)" to be able to boot.
> No trace of detecting Windows XP professional on my
> first drive (this is a documented issue though, but
> the first one isn't).

Can't comment here. I didn't have issues, but my Indiana "test" machine is 
dedicated to this OS.

> Broken:
> even after editing /boot/grub/menu.lst, GRUB still
> "wouldn't take"; changes weren't visible in the GRUB
> boot menu.
> 
> Broken:
> default shell given to root and to myself is
> /bin/bash; this is a SEVERE ERROR (the worst of all).
> Not only do I not want to have to go and modify the
> system to remove that bash GARBAGE of a shell, it's
> unacceptable to have to do that for every engineering
> cycle of a new build.

We've discussed this already and beaten it to death (bug #74). I beleive the 
plan is to allow you to choose the default shell upon installation.

> As an added "bonus", we'll have BASH garbage scripts,
> incompatible with Bourne-family shells, be encouraged
> and propagate -- on Solaris. The future looks just
> LOVELY in that respect.

I believe that the default "sh" will be ksh93 which can have script semantic 
extensions as well.  I don't like bash because it has flaky job control and is 
bloat-ware.  At least ksh will accept old "sh" scripts without failure (I hope).

> If this is the future that awaits us, I shudder at
> it. If I wanted to run a *UNIX-like* operating
> system, I'd go ahead and run that GNU/Linux garbage,
> not SunOS!

This was my first reaction.  My hope is that there will be a dual path for 
those of us that actually like SunOS.  Keep in mind that this is a preview and 
everything is subject to change.  I'm surprised that you didn't complain about 
/usr/gnu/bin at the head of PATH and populated with conflicting utilities.  
This scares me more than anything for SunOS compatibility. This may break 
scripts even worse than using bash.

BTW, everything you've mentioned is probably old-hat in the indiana-discuss 
forum.

Gary
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[UNIX admin]

> Understandable change for a non Sun OS. But I tend to
> agree that this will make things bad for current
> scripts.

OK, well, if that's the case, then there needs to be no further discussion. 
I'll go back to my Solaris 10 and wait for Solaris 11 to come out. Buh-bye 
OpenSolaris.

If that's the case, I'll see if I can sign a NDA contract directly with Sun to 
get the stuff I need into *Solaris*, and forget I ever saw or knew anything 
about this OpenSolaris "Indiana" debacle.

> It's worse than that.  For example SunStudio can't
> install using pkg because of missing dependencies in
> the base system.  I think the plan is to provide new
> packages.  The pkg "refresh" did fix a lot of
> problems.

The first thing I did was look at what documentation was there, but couldn't 
figure out how to install/remove software based on that documentation. And 
while I'm very grateful that Stephen Hahn did listen to my suggestions as far 
as the new packaging is concerned, without the documentation, it's a lot of 
effort to figure stuff out.

> We've discussed this already and beaten it to death
> (bug #74). I beleive the plan is to allow you to
> choose the default shell upon installation.

IRIX 6.5. Yes! That'd be cool.

> I believe that the default "sh" will be ksh93 which
> can have script semantic extensions as well.  I don't
> like bash because it has flaky job control and is
> bloat-ware.  At least ksh will accept old "sh"
> scripts without failure (I hope).

ksh and ksh93 is fine. Those are Bourne shell compatible.

> This was my first reaction.  My hope is that there
> will be a dual path for those of us that actually
> like SunOS.  Keep in mind that this is a preview and
> everything is subject to change.  I'm surprised that
> you didn't complain about /usr/gnu/bin at the head of
> PATH and populated with conflicting utilities.  This
> scares me more than anything for SunOS compatibility.
> This may break scripts even worse than using bash.

I saw that. It sucks dead bunnies through a bent straw sideways.

Luckily, my builds have a package which delivers /etc/PATH and /etc/MANPATH, 
and the corresponding /etc/cshrc and /etc/login which read those files.

This technology was assimilated from HP-UX, and it works beautifully, system 
wide, so long as either the users are using /bin/csh or /bin/tcsh. There is 
additional code that gets executed to detect whether we are interactive and 
configure the terminal settings if that's the case.

So, since I deliver a preconfigured PATH and MANPATH that are always correct (I 
even made sure /opt/blablabla/bin comes *after* /usr/ccs/bin), I would be 
unaffected by this /usr/gnu/bin coming in front of normal /usr/bin.

Other customers are not so fortunate. Not only will they be getting GNU garbage 
for commands, they also won't be learning System V, a far superior system to 
anything GNU.
That is very unfortunate, and in that long run, it is unfortunate for all of 
us, because just like on Microsoft with Windows, it will lead to the GNU 
hegemony.

> BTW, everything you've mentioned is probably old-hat
> in the indiana-discuss forum.

Possibly. I just tried "Indiana" for the first time yesterday, since I didn't 
have a chance to try it earlier.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[UNIX admin]

> This is debatable ... Can you provide pros and cons
> for this from your
> point of view?

For example, I have a package that delivers /.cshrc, /.login and /.logout. 
Determining root's home directory via public interfaces is unreliable, namely 
because such public interfaces aren't well defined. I could look directly into 
/etc/passwd, but as "Indiana" clearly shows now, there is no guarantee 
whatsoever, that home directory field will be at a fixed position. I could also 
use `finger`, but there's no guarantee that the output won't change, thereby 
breaking my regex parser for it. For crying out loud, they broke the output of 
`uname -a`.

And so what if there are a few /.*rc files laying around in /? How is that a 
problem? But moving root's home account around does break customer's software.

The promise of SunOS is that it would remain backward and forward compatible; 
that is why environments that need to be super-stable and super-reliable prefer 
it over any other operating system.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] disk read + timout errors. A bug, or something to be concerned about?

[Dr. David Kirkby]

Since the very first time I booted Solaris Express Developer Edition 9/07 
snv_70b X86 on this laptop (Sony VAIO VGN-Sz4XWN/C) there has been a long delay 
in the boot process. The messages indicate something is amiss, but since it has 
done this all the time, and it boots OK, I'm not sure how much I should concern 
myself with it. See below. Its the last 20 or so lines where the problems 
occur, but I have pasted the very first line from boot, rather than omit 
something that might be useful. 

Dec  2 09:42:45 kingfisher genunix: [ID 540533 kern.notice] ^MSunOS Release 
5.11 Version snv_70b 64-bit
Dec  2 09:42:45 kingfisher genunix: [ID 943907 kern.notice] Copyright 1983-2007 
Sun Microsystems, Inc.  All rights reserved.
Dec  2 09:42:45 kingfisher Use is subject to license terms.
Dec  2 09:42:45 kingfisher unix: [ID 126719 kern.info] features: 
15f7fff
Dec  2 09:42:45 kingfisher unix: [ID 168242 kern.info] mem = 2086972K 
(0x7f60f000)
Dec  2 09:42:45 kingfisher rootnex: [ID 466748 kern.info] root nexus = i86pc
Dec  2 09:42:45 kingfisher rootnex: [ID 349649 kern.info] pseudo0 at root
Dec  2 09:42:45 kingfisher genunix: [ID 936769 kern.info] pseudo0 is /pseudo
Dec  2 09:42:45 kingfisher rootnex: [ID 349649 kern.info] scsi_vhci0 at root
Dec  2 09:42:45 kingfisher genunix: [ID 936769 kern.info] scsi_vhci0 is 
/scsi_vhci
Dec  2 09:42:45 kingfisher rootnex: [ID 349649 kern.info] isa0 at root
Dec  2 09:42:45 kingfisher pci_autoconfig: [ID 466951 kern.warning] WARNING: No 
ACPI obj for bus1, ACPI OFF?
Dec  2 09:42:45 kingfisher pci_autoconfig: [ID 769584 kern.warning] WARNING: 
detected unsupported configuration: non-empty bridge (bus 0x0, dev 0x1c, func 
0x1) without I/O resources assigned by bios for secondary bus 0x6
Dec  2 09:42:45 kingfisher pci_autoconfig: [ID 130646 kern.warning] WARNING: 
devices under bridge bus 0x0, dev 0x1c, func 0x1 will not be assigned I/O ports
Dec  2 09:42:45 kingfisher pci_autoconfig: [ID 771164 kern.info] NOTICE: 
reprogram pci device [9/4/0] (pcic)
Dec  2 09:42:45 kingfisher pcplusmp: [ID 658230 kern.info] NOTICE: apic: local 
nmi: 0 1 1 1
Dec  2 09:42:45 kingfisher pcplusmp: [ID 658230 kern.info] NOTICE: apic: local 
nmi: 1 1 1 1
Dec  2 09:42:45 kingfisher pcplusmp: [ID 177709 kern.info] pcplusmp: vector 0x9 
ioapic 0x1 intin 0x9 is bound to cpu 1
Dec  2 09:42:45 kingfisher pseudo: [ID 129642 kern.info] pseudo-device: ppm0
Dec  2 09:42:45 kingfisher genunix: [ID 936769 kern.info] ppm0 is 
/pseudo/[EMAIL PROTECTED]
Dec  2 09:42:45 kingfisher rootnex: [ID 349649 kern.info] npe0 at root: space 0 
offset 0
Dec  2 09:42:45 kingfisher genunix: [ID 936769 kern.info] npe0 is /[EMAIL 
PROTECTED],0
Dec  2 09:42:45 kingfisher pcplusmp: [ID 803547 kern.info] pcplusmp: pci-ide 
(pci-ide) instance 1 vector 0x16 ioapic 0x1 intin 0x16 is bound to cpu 0
Dec  2 09:42:45 kingfisher pcplusmp: [ID 803547 kern.info] pcplusmp: pci-ide 
(pci-ide) instance 1 vector 0x16 ioapic 0x1 intin 0x16 is bound to cpu 1
Dec  2 09:42:45 kingfisher genunix: [ID 640982 kern.info]   IDE device at 
targ 0, lun 0 lastlun 0x0
Dec  2 09:42:45 kingfisher genunix: [ID 846691 kern.info]   model 
ST9120821AS
Dec  2 09:42:45 kingfisher genunix: [ID 479077 kern.info]   ATA/ATAPI-7 
supported, majver 0xfe minver 0x0
Dec  2 09:42:47 kingfisher npe: [ID 236367 kern.info] PCI Express-device: 
[EMAIL PROTECTED], ata2
Dec  2 09:42:47 kingfisher genunix: [ID 936769 kern.info] ata2 is /[EMAIL 
PROTECTED],0/[EMAIL PROTECTED],2/[EMAIL PROTECTED]
Dec  2 09:42:47 kingfisher genunix: [ID 773945 kern.info]   UltraDMA mode 5 
selected
Dec  2 09:42:47 kingfisher gda: [ID 243001 kern.info] Disk0:
Dec  2 09:42:47 kingfisher ata: [ID 496167 kern.info] cmdk0 at ata2 target 0 
lun 0
Dec  2 09:42:47 kingfisher genunix: [ID 936769 kern.info] cmdk0 is /[EMAIL 
PROTECTED],0/[EMAIL PROTECTED],2/[EMAIL PROTECTED]/[EMAIL PROTECTED],0
Dec  2 09:42:48 kingfisher unix: [ID 190185 kern.info] SMBIOS v2.4 loaded (995 
bytes)
Dec  2 09:42:48 kingfisher genunix: [ID 408114 kern.info] /cpus (cpunex0) online
Dec  2 09:42:48 kingfisher acpica: [ID 785475 kern.notice] ACPI 
(exconfig-0558): Dynamic SSDT Load - OemId [  Sony] OemTableId [VAIO] 
[20060721]
Dec  2 09:42:48 kingfisher last message repeated 1 time
Dec  2 09:42:48 kingfisher cpunex: [ID 114370 kern.info] cpu0 at cpus0
Dec  2 09:42:48 kingfisher genunix: [ID 408114 kern.info] /cpus/[EMAIL 
PROTECTED] (cpudrv0) online
Dec  2 09:42:48 kingfisher pseudo: [ID 129642 kern.info] pseudo-device: dld0
Dec  2 09:42:48 kingfisher genunix: [ID 936769 kern.info] dld0 is 
/pseudo/[EMAIL PROTECTED]
Dec  2 09:42:49 kingfisher genunix: [ID 830136 kern.info] NOTICE: drm: 
Initialized i915 1.4.0 20060929 
Dec  2 09:42:49 kingfisher pcplusmp: [ID 803547 kern.info] pcplusmp: i8042 
(i8042) instance 0 vector 0x1 ioapic 0x1 intin 0x1 is bound to cpu 0
Dec  2 09:42:49 kingfisher pcplusmp: [ID 444295 kern.info] pcplusmp: i8042 
(i8042) instance #0 vector 0xc ioapic 0x1 intin 0xc is bound to cpu 0
Dec  2 09:

Re: [osol-discuss] "Indiana" review

[W. Wayne Liauh]

"Broken, Broken, Broken, Broken, . . . ."

Now I know why I am so compellingly addicted to Solaris.  Kudos Sun's 
management for their willingness to take such bold actions, undoubtedly 
accompanied by tons of well-oxidized midnight oil, that will finally take 
Solaris to world dominance, or even world ubiquitance.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[Patrick Ale]

On Dec 2, 2007 6:30 PM, W. Wayne Liauh <[EMAIL PROTECTED]> wrote:

> "Broken, Broken, Broken, Broken, . . . ."
>
> Now I know why I am so compellingly addicted to Solaris.  Kudos Sun's
> management for their willingness to take such bold actions, undoubtedly
> accompanied by tons of well-oxidized midnight oil, that will finally take
> Solaris to world dominance, or even world ubiquitance.
>
>
Maybe I am a bit the devil's advocate here and I never bothered with Indiana
to start with but... Indiana is  not Solaris or THE SXCE binary outcome
(hence the long lasting discussions that were around when people made more
or less the statement that Indiana was "the" binary distribution outcome
derived from the Opensolaris community work)..Therefor whatever you'd expect
to work in SXCE or Solaris 10 or future 11 and isn't working in Indiana
doesn't have to get the stamp 'broken'. It's only broken if the result is
different from what you should expect of Indiana. In my opinion it has been
made very loud and clear that the packaging system of Indiana is different
from that of SXCE and Solaris. Or maybe I should do more about life and less
about IRC and fora. As for scripts, it has been wildely established as well
that PATHs and directories where binaries reside is a bit off from what you
can expect from a Solaris binary distribution or SXCE.

So yes, if you want everything to work as in your binary Solaris
distribution and/or SXCE, stick with them.


Patrick
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[Patrick Ale]

On Dec 2, 2007 7:03 PM, Patrick Ale <[EMAIL PROTECTED]> wrote:



Is Sun even sure it's self what will do what and what will replace what? I
just get an email from somebody of this list saying Indiana will replace
SXCE and will be the basis for Solaris 11. Which is ff-ing funny since
people who work at Sun (and highly placed functions) assured me less than
four weeks ago that SXCE would stay around, that they needed the community
to do what they are doing now and how they cant do things with out them and
that SXCE would be the basis for Solaris 11 and Indiana was merrely a
product derived from SXCE.

If Indiana is going to substitute SXCE, then I'd be very very bitter, so to
say. Not only cause it'd mean heaps of people working on SXCE who worked
their ass of to make a stable product with features we should all cheer
about have been being used to make a Linux-like distro but also (from what I
can read on fora and IRC0 what they stand for is totally voided by this
decision. Again, if it's true that Indiana will replace SXCE.

MEH.

Patrick
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Middle management at Sun destroys OpenDS is OpenSolaris next?

[Chris Mahan]

On Dec 1, 2007 9:23 PM, Ben McGinnes <[EMAIL PROTECTED]> wrote:

>
> 1) The cited project hasn't been closed down, just restructured (along
> with other large chunks of Sun recently).
>
> 2) OpenSolaris' licensing has resulted in all released code
> effectively being "in the wild" - those horses have bolted.
>
> 3) Development of OpenSolaris isn't just spread across two or three
> Sun offices, which could be readily consolidated like the Directory
> Services projects have been.  It really is a worldwide development
> process, so all Sun could do is reassign developers to other projects
> which still wouldn't prevent those developers from contributing
> privately.
>
> 4) From a PR point of view, shutting down OpenSolaris would be
> foolhardy at best.  Sun management are well aware of what happened to
> The SCO Group and a public backlash from the FOSS community is a
> serious issue these days.
>
> 5) The OpenSolaris Project provides a very real vector for future Sun
> growth.  By introducing Solaris to a wider user base than that
> traditionally generated through the employees of existing clients,
> they have a natural entry point into market segments not usually
> targetted.  Small to medium enterprises, for example, may now start
> acquiring low end Sun servers and/or thin client services if their IT
> staff/consultants are already aware of the benefits through working
> with OpenSolaris.
>
> 6) There's no real market value in selling the operating system alone.
> Not with the development of the many GNU/Linux distributions and a
> solid base of GNU/BSD systems already freely available.  The operating
> system's value is only realised in conjunction with the hardware it
> leverages.
>
> It's not a matter of "Sun's goodwill," regardless of how Sun's
> attitude may be spun that way, it's simply enlightened self-interest.
>
>
> Regards,
> Ben
>
>
> P.S.  Disclaimer:  I am currently contracted to Sun Microsystems via a
> third party.  All opinion is my own and not speaking in any way for
> Sun (hence the post from my home address).  Neither am I speaking for
> any of the FOSS organisations I am involved with at an organisational
> level (e.g. Open Source Victoria) or have been involved with in the
> past (e.g. Linux Users of Victoria).
>
>
I thank you for your point of view on the matter.

-- 
Chris Mahan
http://www.christophermahan.com/
[EMAIL PROTECTED]
[EMAIL PROTECTED]
cell 818.943.1850
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[Casper . Dik]

I too find /root an extremely poor choice; which part of "root" do
these people not understand?

Of course, if you then say "but all the window and browser garbage in /?"

I can only say that I think that /.mozilla should be linked to /dev/*mem
in order to ensure maximum damage when you start a browser or window system
as root.

Casper

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[W. Wayne Liauh]

> Is Sun even
> sure it's self what will do what and what will
> replace what?

I am definitely the least qualified person to comment on what Sun should or 
should not have done.  But I think if there is any doubt, there is always the 
good 'ol faithful "Solaris 10" (which is also surprisingly modern--as Sun is 
constantly back-porting many of the new features from Solaris Express).

In a separate thread, there are discussions on dual-booting b/t Solaris 10 and 
Solaris Express.  This is, IMO, one of very rare instances that you can 
actually have a cake and eat it at the same time.  My mother runs Solaris 10u4 
on her little IBM ThinkPad notebook.  (Interestingly, this is the only system 
that she feels comfortable with, vis-a-vis Windows, Mac, and various Linux 
distros.)  Her system is indeed "modern" enough that I don't see any need of 
moving into Solaris 11.  In the foreseeable future anyway.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[UNIX admin]

> "Broken, Broken, Broken, Broken, . . . ."
> 
> Now I know why I am so compellingly addicted to
> Solaris.  Kudos Sun's management for their
> willingness to take such bold actions, undoubtedly
> accompanied by tons of well-oxidized midnight oil,
> that will finally take Solaris to world dominance, or
> even world ubiquitance.

Yes, broken. It can't have anything about "OpenSolaris" in it if it's not 
supposed to be based on SunOS.
If it is based on SunOS, then it's broken.

And look, I purposely stayed out of the whole OpenSolaris vs. "Indiana" debacle 
because I couldn't care less about some guy who founded Debian-something or 
other, since his product means absolutely nothing to me.

I'd much rather have technical presentations on using and mastering the modular 
debugger and debugging the kernel at the next OpenSolaris user group meeting, 
than hear about this "Indiana" debacle.

The technical things that I have looked at so far do not work the way SunOS 
works. That's an error.
And should "Indiana" become the next Solaris 11, well... I'll just go for the 
*real* thing and switch to CentOS GNU/Linux, why settle for a copy? Or I'll go 
over to the hp camp and stick with HP-UX.

But I will not stick with a bastardized Solaris, I can damn well guarantee that.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Why is my Intel GMA 950 graphics not being reconisded (driver exists)

[Dr. David Kirkby]

I've a Sony VAIO VGN-SZ4XWN/C laptop which is quite an odd laptop in that it 
has two graphics chipsets. It has a high performance/high power consumption 
Nvidia GeForce Go 7400 as well as a lower performance/low power consumption 
integrated graphics in the form of the Intel GMA 950. There is a switch on the 
laptop marked 'Stamina/Speed' which selects the appropiate graphics chip. 

When I first tried to install Solaris Express Developer Edition 9/07 snv_70b 
X86 I had the switch in the 'Stamina' (Intel GMA 950) position. However, the 
installer reported the graphics adapter was not recognised and gave me the 
option of installing in text mode. 

I then switched the switch to the 'Speed' (Nvidia GeForce Go 7400) position and 
the installation went fine. 

I would however like to get the lower power consumption chipset working, as I 
rarely need the performance the Nvida GPU provides. 

Funny thing is, if I switch to the 'Stamina' position and reboot, the laptop 
finds the Nvida GPU and uses that - I rather expected it to boot only into text 
mode. 

I believe the driver has been in OpenSolaris for some time, so I would expect 
it is present. So I have two questions.

1) Can I verify if the driver exists on the system?
2) Any tips on how I might be able to get the driver to work with this chip 
set? Ideally it would be nice to be able to have the system find the right 
driver if I switch this switch over, but failing that, I'd prefer to use the 
Intel to the Nvida I am currently using, as power consumption is more important 
to me than performance. 

Dave
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] frequency scalling in opensolaris

[Dr. David Kirkby]

> Well, there is an mdb hack (enable cpudrv_direct_pm)
> along with a couple 
> of ioctl(2) calls (PM_DIRECT_PM and
> PM_SET_CURRENT_POWER) that could 
> give you direct control over the frequency. I'm not
> convinced you really 
> want to go there though

I would like to 'go there'. I think it would be useful to fix the frequency at 
1 GHz on my laptop, and not let it wander up to 2 GHz. I know Vista can limit 
the maximum CPU speed used, as I have run a very CPU intensive benchmark in one 
of the power saving positions and know it scores lower. Hence I assume the CPU 
speed was throttled back, and not allowed to increase even though the system 
was running the CPU flat out. 

If you can provide a way for the user to set the upper frequency, I personally 
think it would be useful. 

> as I think you are misreading
> the messages from 
> dmesg.
> 
> The messages you've listed are printed to the system
> log whenever the 
> maximum power level changes ...

I can't speak for the original poster, but I did not interpret them correctly. 

I can't critisise the words your driver uses, but if you can think of a way of 
rewording it, to make it clearer what the message exactly means, I guess it 
would be a good thing. Whilst the wording seems accurate, I think a lot of 
people will interpret it incorrectly. 

PS, I'm not sure why there are now two threads with this title going on - it is 
quite confusing. I notice that with some of the other threads too - they get 
split up. 

Dave
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[Shawn Walker]

On Dec 2, 2007 5:50 AM, UNIX admin <[EMAIL PROTECTED]> wrote:
> The unthinkable has happened: SunOS backwards compatibility has been broken.

You are aware that Indiana hasn't gone through ARC yet and is an early
prototype; right?

> Broken:
> root's home directory is in /root; this is a SEVERE ERROR. We're not on 
> Linux, and this isn't Linux land!

I wasn't aware that Sun had any documentation that guaranteed root's
home. How does this break backwards compatibility? Personal
preferences do not count here.

> Broken:
> all my System V compliant packages are no longer installable, instead 
> `pkgadd` exits with exit code 1 (fatal error), because 
> /var/sadm/install/contents is empty.

There was a bug in the version of pkgadd that was initially released,
an update is available. Look here for instructions to update:
http://mail.opensolaris.org/pipermail/indiana-discuss/2007-November/003777.html

I have installed a few System V packages myself without an issue.

However, yes, it is likely that there will not be 100% package
dependency compliance. However, I don't think Sun has ever guaranteed
that either.

> Broken:
> after the installation, the system was rendered unbootable. I had to go into 
> the BIOS and play Russian roulette (I have four identical drives) to find the 
> drive "Indiana" was on, and edit GRUB lines with the correct "root (hd3,0,a)" 
> to be able to boot. No trace of detecting Windows XP professional on my first 
> drive (this is a documented issue though, but the first one isn't).
>

Please file a bug at http://defect.opensolaris.org

I did not have this issue personally.

> Broken:
> even after editing /boot/grub/menu.lst, GRUB still "wouldn't take"; changes 
> weren't visible in the GRUB boot menu.

Again, this is an early prototype "Developer Preview" not a final
release, and not a fully QA'd one.

> Broken:
> default shell given to root and to myself is /bin/bash; this is a SEVERE 
> ERROR (the worst of all). Not only do I not want to have to go and modify the 
> system to remove that bash GARBAGE of a shell, it's unacceptable to have to 
> do that for every engineering cycle of a new build.
>

This was a last minute change that hasn't gone through ARC yet.
Discussions are still under way as to what the shell will be. It is
premature to call this a severe error until a comittment has been made
for this interface change.

In short, why didn't you send this to indiana-discuss? This is not a
final QA'd, and ARC'd release.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"We don't have enough parallel universes to allow all uses of all
junction types--in the absence of quantum computing the combinatorics
are not in our favor..." --Larry Wall
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[Shawn Walker]

On Dec 2, 2007 12:20 PM, Patrick Ale <[EMAIL PROTECTED]> wrote:
>
>
> On Dec 2, 2007 7:03 PM, Patrick Ale <[EMAIL PROTECTED]> wrote:
>
> 
>
> Is Sun even sure it's self what will do what and what will replace what? I
> just get an email from somebody of this list saying Indiana will replace
> SXCE and will be the basis for Solaris 11. Which is ff-ing funny since
> people who work at Sun (and highly placed functions) assured me less than
> four weeks ago that SXCE would stay around, that they needed the community
> to do what they are doing now and how they cant do things with out them and
> that SXCE would be the basis for Solaris 11 and Indiana was merrely a
> product derived from SXCE.

It is true according to other high ranking folks at Sun. The plan is
to eventually phase out SXCE and replace it with Indiana according to
them.

This was discussed at the OpenSolaris Developer's Summit.

> If Indiana is going to substitute SXCE, then I'd be very very bitter, so to
> say. Not only cause it'd mean heaps of people working on SXCE who worked
> their ass of to make a stable product with features we should all cheer
> about have been being used to make a Linux-like distro but also (from what I
> can read on fora and IRC0 what they stand for is totally voided by this
> decision. Again, if it's true that Indiana will replace SXCE.

You are aware that a large number of individuals work on Indiana some
of those whom used to work on SXCE, so how is Indiana a betlittlement
of any of that work?

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"We don't have enough parallel universes to allow all uses of all
junction types--in the absence of quantum computing the combinatorics
are not in our favor..." --Larry Wall
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[Josh Lange]

>
> On Dec 2, 2007 7:40 AM, UNIX admin <[EMAIL PROTECTED]> wrote:
>
> > > This is debatable ... Can you provide pros and cons
> > > for this from your
> > > point of view?
> >
> > For example, I have a package that delivers /.cshrc, /.login and
> > /.logout. Determining root's home directory via public interfaces is
> > unreliable, namely because such public interfaces aren't well defined. I
> > could look directly into /etc/passwd, but as "Indiana" clearly shows now,
> > there is no guarantee whatsoever, that home directory field will be at a
> > fixed position. I could also use `finger`, but there's no guarantee that the
> > output won't change, thereby breaking my regex parser for it. For crying out
> > loud, they broke the output of `uname -a`.
> >
>

"getent passwd root" should be a little more reliable, this works if the
user is in ldap/nis.


>
>
>
> >
> > And so what if there are a few /.*rc files laying around in /? How is
> > that a problem? But moving root's home account around does break customer's
> > software.
>
>
In our case, we have several public solaris 10 shell servers. We have been
changing the path of root, to /root so we have a secure place to put files
we don't want to give users access to (rsa keys, etc, before they are
installed). It's a lot cleaner than setting the umask, and safer than
remembering to check file permissions every time (not to mention cluttering
"/").

In the case that you're complaining about (just a few .rc files, whats the
problem?), it seems very unlikely that root's home directory would be used
for any application critical scripts anyway.

In the case where it is *too hard* to find root's home dir, making the bold
assumption of "/" would still work, as long as they were consistent, and
used absolute paths.


>
>
> >
> > The promise of SunOS is that it would remain backward and forward
> > compatible; that is why environments that need to be super-stable and
> > super-reliable prefer it over any other operating system.
> >
>
getent seems to work in all cases. As long as whatever custom scripts exist
on the system don't make bold assumptions about this, there shouldn't be  a
problem.


>
> >
> > This message posted from opensolaris.org
> > ___
> > opensolaris-discuss mailing list
> > opensolaris-discuss@opensolaris.org
> >
>
>
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[Shawn Walker]

On Dec 2, 2007 5:22 PM, Josh Lange <[EMAIL PROTECTED]> wrote:
>
>
>
>
> >
> >
> >
> >
> > On Dec 2, 2007 7:40 AM, UNIX admin < [EMAIL PROTECTED]> wrote:
> >
> > >
> > > > This is debatable ... Can you provide pros and cons
> > > > for this from your
> > > > point of view?
> > >
> > > For example, I have a package that delivers /.cshrc, /.login and
> /.logout. Determining root's home directory via public interfaces is
> unreliable, namely because such public interfaces aren't well defined. I
> could look directly into /etc/passwd, but as "Indiana" clearly shows now,
> there is no guarantee whatsoever, that home directory field will be at a
> fixed position. I could also use `finger`, but there's no guarantee that the
> output won't change, thereby breaking my regex parser for it. For crying out
> loud, they broke the output of `uname -a`.
> > >
> >
> >
>
>
> "getent passwd root" should be a little more reliable, this works if the
> user is in ldap/nis.
>
> >
> >
> >
> >
> >
> > >
> > > And so what if there are a few /.*rc files laying around in /? How is
> that a problem? But moving root's home account around does break customer's
> software.
> >
>
>  In our case, we have several public solaris 10 shell servers. We have been
> changing the path of root, to /root so we have a secure place to put files
> we don't want to give users access to (rsa keys, etc, before they are
> installed). It's a lot cleaner than setting the umask, and safer than
> remembering to check file permissions every time (not to mention cluttering
> "/").

I always change any Solaris systems I setup to use /root for root's
home for this very reason.

I like being confident that any files created when logged in as root
will go to a relatively "secure place."

Considering Solaris' rbac capabilities as well, I look for root to be
extinct in the not too distant future.

Roles / Profiles are a far better way to accomplish this.

The days of an all-powerful must end if we are to embrace security.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"We don't have enough parallel universes to allow all uses of all
junction types--in the absence of quantum computing the combinatorics
are not in our favor..." --Larry Wall
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[W. Wayne Liauh]

> But I will not stick with a bastardized Solaris, I
> can damn well guarantee that.

As my fellow Hawaiian Tim Scanlon suggested in a separate thread, when we get 
frustrated with Solaris Express (I don't think Indiana is even ready for 
discussion yet--outside the Indiana Forum) we can always seek the comfort of 
Solaris 10.  Sometime into the future, we may even see SPARC clones.  The "new" 
Solaris movement is going to become very big b/y you and I could ever imagine.  
Just be patient.

"Patient."  Of course, it's much easier said than done.  Tomorrow it may be my 
turn to explode.  We all understand.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] frequency scalling in opensolaris

[Mark Haywood]

Dr. David Kirkby wrote:

Well, there is an mdb hack (enable cpudrv_direct_pm)
along with a couple 
of ioctl(2) calls (PM_DIRECT_PM and
PM_SET_CURRENT_POWER) that could 
give you direct control over the frequency. I'm not
convinced you really 
want to go there though


I would like to 'go there'. I think it would be useful to fix the frequency at 1 GHz on my laptop, and not let it wander up to 2 GHz. I know Vista can limit the maximum CPU speed used, as I have run a very CPU intensive benchmark in one of the power saving positions and know it scores lower. Hence I assume the CPU speed was throttled back, and not allowed to increase even though the system was running the CPU flat out. 

If you can provide a way for the user to set the upper frequency, I personally think it would be useful. 


Take a look at the setfreq program in the attached tar file. You can run 
it as is or use it to create your own improved version for what you 
want. This is totally unsupported as it is just some code I threw 
together a long time ago to allow me to force the processors to 
different frequencies.


You'll want to disable cpupm in /etc/power.conf and run 
/usr/sbin/pmconfig before running the setfreq program. I could modify 
the program to do this, but so can you.


We intend to add a supported policy to Solaris to allow you to do this 
kind of thing, but in the meantime I'm afraid you'll have to settle for 
this.


One warning ... once the program enables cpupm_direct_pm (take a look at 
the source and look for "echo cpudrv_direct_pm/W1") , the automatic 
power management of CPUs will no longer function as documented (which of 
course is what you want). If you ever want to get back to the documented 
behavior, then you will have to reboot or use mdb to disable 
cpupm_direct_pm ("echo cpudrv_direct_pm/W0") and you will have to enable 
cpupm in /etc/power.conf.


One last note ... if I remember correctly, in order to change the 
frequency of dual core chips, you have to change them both. In other 
words, run setfreq twice. The first time, set the frequency of CPU 
instance 0. The second, set the frequency of CPU instance 1 and both 
instance 0 and 1 will change frequency at this point.



as I think you are misreading
the messages from 
dmesg.


The messages you've listed are printed to the system
log whenever the 
maximum power level changes ...


I can't speak for the original poster, but I did not interpret them correctly. 

I can't critisise the words your driver uses, but if you can think of a way of rewording it, to make it clearer what the message exactly means, I guess it would be a good thing. Whilst the wording seems accurate, I think a lot of people will interpret it incorrectly. 


Actually, I'm sure you could criticize the wording, but there is no 
need, as I'm planning on removing the message entirely and am likely 
replacing it with a kstat. The system error log really isn't the right 
place for this information and I honestly didn't give it much thought 
(obviously) when I added it to the code.


PS, I'm not sure why there are now two threads with this title going on - it is quite confusing. I notice that with some of the other threads too - they get split up. 


I'm only aware of one thread.

Mark


freq.tar.gz
Description: GNU Zip compressed data
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Why is my Intel GMA 950 graphics not being reconisded (driver exists)

[Dr. David Kirkby]

> I've a Sony VAIO VGN-SZ4XWN/C laptop which is quite
> an odd laptop in that it has two graphics chipsets.
> It has a high performance/high power consumption
> Nvidia GeForce Go 7400 as well as a lower
> performance/low power consumption integrated graphics
> in the form of the Intel GMA 950. There is a switch
> on the laptop marked 'Stamina/Speed' which selects
> the appropiate graphics chip. 

After further investigation, I am convinced this is working as expected. When 
switched to Speed, there is a large Nvida configuration utility that can be 
accessed from 

All Aplications -> System Tools ->NVIDIA X server Settings. 

It can read the CPU temperature and allows me to set loads of things if I want 
to. 

In contrast, when I boot in the Stamina position, which uses the Intel chip 
set, there is very little that can be set on this Nvidia utility - not even 
resolution. The GPU temperature can't be read. 

It is also running warmer in the Speed position and the fan running louder, so 
it seems this Speed/Stamina switch is selecting the correct graphics chip set 
(Intel 950 or Nvidia GeForce Go 7400). 

Dave
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[Willem van Schaik]

Personally I really like the /root thing. But, big but, that's only 
because I hate all those "/.ghatever" :) files in my root filesystem. 
And that  just because the root user used a browser or some other GUI 
program.

And that brings me to my main point, why would 'root' ever, ever use a 
browser, do XxxxOffice, etc. IMHO root should be blocked fom using GNOME 
or any GUI and only be allowed to do CLI / console access. Which in 
reality would probably mean that only 'normal' users will login at the 
the Gnome login prompt and then you can open a terminal and do a 'su'. 
Which is what Indiana is currently doing, but my guess is that that's 
because of a bug.

I know this would be pretty drastic, and please see this only as a 
personal "brainstorm". Nothing else!! Just a vent of idea's. And I do 
have some others that are way, way more drastic. :-)

On the topic of the default shell, yep you can make it a question during 
install. I don't understand why people hate bash, I like it as a user. 
But  for scripting I still use /bin/sh all the time. So my preference 
would be to go for /bin/sh as the default shell for root and then 
/bin/bash as the default for 'normal' (who is normal here? :-) users.

And for the rest, I see Indiana as a nice pre-pre-pre-release to open 
up. Which is a good thing!! Why always first discuss things to death and 
them implement it, instead of first doing a prototype, releasing that 
and then see what everybody likes or not. No need to become agitated 
here, it will take some time and good discussion before what is put on 
the table with Indiana will find its way into production Solaris. This 
is healthy!!

Just my two cents.
Willem




[EMAIL PROTECTED] wrote:
>
> I too find /root an extremely poor choice; which part of "root" do
> these people not understand?
>
> Of course, if you then say "but all the window and browser garbage in /?"
>
> I can only say that I think that /.mozilla should be linked to /dev/*mem
> in order to ensure maximum damage when you start a browser or window system
> as root.
>
> Casper
>
> ___
> opensolaris-discuss mailing list
> opensolaris-discuss@opensolaris.org
>   

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Strip Solaris off non-essential drivers!

[Bhaskar Jayaraman]

Hi I need some assistance in the following: -

I am trying to strip the current solaris build off the drivers which may not be 
really essential. I would like to not make the audio drivers, crypto drivers, 
1394, the dtrace binaries etc. a part of the final tar ball.

If any one can add on to this list please (maybe remove solaris LVM from the 
build??) do so and the main reason I am doing this is because I want to have a 
very lightweight kernel which I can use for a diskless client.

Thanks and regards.
Bhaskar.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Strip Solaris off non-essential drivers!

[Gangadhar Mylapuram]

Bhaskar,

You might be interested in these blogs.

http://blogs.sun.com/szhou/entry/build_a_minimal_solaris_image
http://solaristhings.blogspot.com/2006/07/how-small-can-you-make-open-solaris_21.html

-Gangadhar


Bhaskar Jayaraman wrote:
> Hi I need some assistance in the following: -
>
> I am trying to strip the current solaris build off the drivers which may not 
> be really essential. I would like to not make the audio drivers, crypto 
> drivers, 1394, the dtrace binaries etc. a part of the final tar ball.
>
> If any one can add on to this list please (maybe remove solaris LVM from the 
> build??) do so and the main reason I am doing this is because I want to have 
> a very lightweight kernel which I can use for a diskless client.
>
> Thanks and regards.
> Bhaskar.
>  
>  
> This message posted from opensolaris.org
> ___
> opensolaris-discuss mailing list
> opensolaris-discuss@opensolaris.org
>   
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] "Indiana" review

[Alan Coopersmith]

UNIX admin wrote:
> The unthinkable has happened: SunOS backwards compatibility has been broken.
> 
> Broken:
> 
> `uname -a` returns some funky "opensolaris bla bla bla" string instead of the 
> standard
> SunOS hostname 5.11 snv_## i86pc i386 i86pc.

Given all the other incompatibilities you note (and you missed a few
known incompatibilities, like libX11 & libXext in the Preview breaking
binary compatibility with Solaris X apps), isn't it a good thing that
uname warns you this isn't SunOS, so you know it's not compatible and
your scripts don't go assuming it is?

-- 
 -Alan Coopersmith-   [EMAIL PROTECTED]
  Sun Microsystems, Inc. - X Window System Engineering
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org