Can't get a GUI window to open up.

[David Guntner]

Well, my system is mostly updated. Have hit the Next Great Snag. :-)

[***@janet ~ ]# rpm -qa|egrep nvidia
dkms-nvidia-current-280.13-4-mdv2011.0.x86_64
nvidia-current-doc-html-280.13-4-mdv2011.0.x86_64
x11-driver-video-nvidia-current-280.13-4-mdv2011.0.x86_64
[***@janet ~ ]#

There's the current drivers. I've run XFdrake in the console window and
select "test," and a nice graphic display comes up with the little "Is
this correct?" window with the yes/no button to click on and all that
comes up just fine. However, actually issuing a "telinit 5" results in
a few messages, but then nothing - no GUI. Hitting F12 to bring up the

Oct 24 16:52:05 janet init: Switching to runlevel: 5
Oct 24 16:52:06 janet udevd[2121]: kernel-provided name 'capi' and NAME= 'capi/' disagree, please use SYMLINK+= or change the kernel to provide the proper name
Oct 24 16:52:06 janet udevd[2121]: mknod '/dev/capi/.udev-tmp' 68:0 020600 failed: Operation not permitted
Oct 24 16:52:06 janet kdm[6991]: X server died during startup
Oct 24 16:52:06 janet kdm[6991]: X server for display :0 cannot be started, session disabled

So, any ideas on what's causing the current headache, and what can be
done to clear it up?

--Dave

[Jim Beard]

Post by David Guntner
Well, my system is mostly updated. Have hit the Next Great Snag. :-)
dkms-nvidia-current-280.13-4-mdv2011.0.x86_64
nvidia-current-doc-html-280.13-4-mdv2011.0.x86_64
x11-driver-video-nvidia-current-280.13-4-mdv2011.0.x86_64
There's the current drivers. I've run XFdrake in the console window and
select "test," and a nice graphic display comes up with the little "Is
this correct?" window with the yes/no button to click on and all that
comes up just fine. However, actually issuing a "telinit 5" results in
a few messages, but then nothing - no GUI. Hitting F12 to bring up the

Oct 24 16:52:05 janet init: Switching to runlevel: 5
Oct 24 16:52:06 janet udevd[2121]: kernel-provided name 'capi' and NAME= 'capi/' disagree, please use SYMLINK+= or change the kernel to provide the proper name
Oct 24 16:52:06 janet udevd[2121]: mknod '/dev/capi/.udev-tmp' 68:0 020600 failed: Operation not permitted
Oct 24 16:52:06 janet kdm[6991]: X server died during startup
Oct 24 16:52:06 janet kdm[6991]: X server for display :0 cannot be started, session disabled

So, any ideas on what's causing the current headache, and what can be
done to clear it up?

You might try deleting old cruft. I would do this from within
run level 3.

cd
rm -f .*auth*
rm -rf tmp/* /tmp/* /var/tmp/*

Then check the contents of /etc/X11/xorg.conf and see if all
makes sense. If you have some old versions lying around, use
diff xorg.conf xorg.conf.something
to see how they differ.

I know that there have been recent problems with some of the
nvidia installers, but I currently use only ATI cards and cannot
help beyond general guidance from years past.

For proprietary drivers:

1. Do not install both the Mandriva nVidia installer package and
the nVidia installer package from the nVidia website. Just
having both on the system can results in problems, even if you
only use one.

2. You must have installed the kernel-devel package for the
exact kernel you are running. In times long past, I had to
create the symlink from /usr/src/version_of_kernel to
/usr/src/linux before the installer would find the devel files.
That should not be needed (the installer should find the devel
header files even if the linux link is missing) but "should not"
sometimes fails.

3. You must check /etc/X11/xorg.conf and see if all is well there.

Alternate drivers are the nv and nouveau drivers. You may find
that of the three possibilities, proprietary, nv, and nouveau,
only one will work with the current system.

If you change drivers, remember to always remove the old cruft
(stuff in the tmp directories, $HOME/.*auth*).

Cheers!

jim b.

[David Guntner]

Post by David Guntner
There's the current drivers. I've run XFdrake in the console window and
select "test," and a nice graphic display comes up with the little "Is
this correct?" window with the yes/no button to click on and all that
comes up just fine. However, actually issuing a "telinit 5" results in
a few messages, but then nothing - no GUI. Hitting F12 to bring up the

Oct 24 16:52:05 janet init: Switching to runlevel: 5
Oct 24 16:52:06 janet udevd[2121]: kernel-provided name 'capi' and
NAME= 'capi/' disagree, please use SYMLINK+= or change the kernel to
provide the proper name
Oct 24 16:52:06 janet udevd[2121]: mknod '/dev/capi/.udev-tmp' 68:0
020600 failed: Operation not permitted
Oct 24 16:52:06 janet kdm[6991]: X server died during startup
Oct 24 16:52:06 janet kdm[6991]: X server for display :0 cannot be
started, session disabled

So, any ideas on what's causing the current headache, and what can be
done to clear it up?

You might try deleting old cruft. I would do this from within run level 3.

Yes, I'm currently in run level 3. I'm trying to switch to run level 5
in order to start up X, which is the part that's failing. :-)

cd
rm -f .*auth*
rm -rf tmp/* /tmp/* /var/tmp/*

I will keep that in mind, but at the moment I don't believe it's at the
point where those files matter for anything (I did check for any stray
.xauth files, etc., though). XFdrake (which configures your xorg.conf
file) can display a test screen to make sure things are configured
properly. I suspect it uses X to do this. :-) But when it comes time
to actually full-on start it up (via "telinit 5"), nothing happens and
the log shows the above messages.

I can't help but think those udevd messages might be some kind of clue,
but I'm not sure how to fix what it's complaining about.

Then check the contents of /etc/X11/xorg.conf and see if all makes
sense. If you have some old versions lying around, use
diff xorg.conf xorg.conf.something
to see how they differ.

No old versions at this point. What's in there seems to make sense.
And as I said, a test run from XFdrake *will* bring up what's clearly a
graphic window to make sure things are configured properly. This is
part of what makes it so maddening.

I know that there have been recent problems with some of the nvidia
installers, but I currently use only ATI cards and cannot help beyond
general guidance from years past.

Fair enough. :-)

1. Do not install both the Mandriva nVidia installer package and the
nVidia installer package from the nVidia website. Just having both on
the system can results in problems, even if you only use one.

Oh yea, learned that one a long time ago. :-)

Again, my currently-installed driver packages are:
[***@janet ~ ]# rpm -qa|egrep nvidia
dkms-nvidia-current-280.13-4-mdv2011.0.x86_64
nvidia-current-doc-html-280.13-4-mdv2011.0.x86_64
x11-driver-video-nvidia-current-280.13-4-mdv2011.0.x86_64
[***@janet ~ ]#

That very last one is used as part of the dkms-nvidia-current package.

2. You must have installed the kernel-devel package for the exact
kernel you are running. In times long past, I had to create the symlink
from /usr/src/version_of_kernel to
/usr/src/linux before the installer would find the devel files. That
should not be needed (the installer should find the devel header files
even if the linux link is missing) but "should not" sometimes fails.

There were no errors reported when the install of the dkms package was
building its headers, etc., for the kernel in order to lodge the NVIDIA
drivers there. During boot, I see the usual message about the driver
being installed in the kernel.

3. You must check /etc/X11/xorg.conf and see if all is well there.
Alternate drivers are the nv and nouveau drivers. You may find that of
the three possibilities, proprietary, nv, and nouveau, only one will
work with the current system.
If you change drivers, remember to always remove the old cruft (stuff in
the tmp directories, $HOME/.*auth*).

I'll look into those, thanks, but I really don't think it's a driver
issue at the moment. It seems to me that a *driver* issue would cause
XFdrake to not be able to open up a test graphic display, and it's able
to do that. It's not until I try to start up X (not *login* to a
session as a user or anything, just start the server) that I see those
error messages in the log. When I run the XFdrake test screen, the log
is quiet a a church mouse. :-)

--Dave

[Jim Beard]

Post by David Guntner

If you change drivers, remember to always remove the old cruft (stuff in
the tmp directories, $HOME/.*auth*).

I'll look into those, thanks, but I really don't think it's a driver
issue at the moment. It seems to me that a *driver* issue would cause
XFdrake to not be able to open up a test graphic display, and it's able
to do that. It's not until I try to start up X (not *login* to a
session as a user or anything, just start the server) that I see those
error messages in the log. When I run the XFdrake test screen, the log
is quiet a a church mouse. :-)

I have to disagree with you on this one. I have often had
XFdrake show me a good test screen but startx fail to bring up a
gui desktop. The problem has usually been left-over .*auth*
files in the home directory.

It seems that XFdrake sets up things and tests what it has set
up. Then startx reads in the .*auth* stuff lying around and
x-windws takes a walk through the woods.

Removing the old cruft is something I have found often to be
essential.

Cheers!

jim b.

[David Guntner]

Post by David Guntner

If you change drivers, remember to always remove the old cruft (stuff in
the tmp directories, $HOME/.*auth*).

I'll look into those, thanks, but I really don't think it's a driver
issue at the moment. It seems to me that a *driver* issue would cause
XFdrake to not be able to open up a test graphic display, and it's able
to do that. It's not until I try to start up X (not *login* to a
session as a user or anything, just start the server) that I see those
error messages in the log. When I run the XFdrake test screen, the log
is quiet a a church mouse. :-)

I have to disagree with you on this one. I have often had XFdrake show
me a good test screen but startx fail to bring up a gui desktop. The
problem has usually been left-over .*auth* files in the home directory.

To be clear, I'm not trying to do a "startx" as a logged in user to
bring up my personal userspace GUI. I'm, as root, issuing a "telinit 5"
command to put the system into GUI-by-default mode, with a login screen
waiting for someone to login. I did look in to those .xauth* files as I
said I would and have removed them. Regrettably, it didn't make any
difference. X is still not starting, and I'm still getting that log
message. Which still makes me wonder if there's some kind of udevd
problem that's keeping the server from connecting to something it needs
to connect to. For purposes of refreshing the memory, the log messages

Oct 24 16:52:05 janet init: Switching to runlevel: 5
Oct 24 16:52:06 janet udevd[2121]: kernel-provided name 'capi' and NAME= 'capi/' disagree, please use SYMLINK+= or change the kernel to provide the proper name
Oct 24 16:52:06 janet udevd[2121]: mknod '/dev/capi/.udev-tmp' 68:0 020600 failed: Operation not permitted
Oct 24 16:52:06 janet kdm[6991]: X server died during startup
Oct 24 16:52:06 janet kdm[6991]: X server for display :0 cannot be started, session disabled

The time and date are different as of when I just tried again 5 minutes
ago, but they're the exact same message.

It seems that XFdrake sets up things and tests what it has set up. Then
startx reads in the .*auth* stuff lying around and x-windws takes a walk
through the woods.
Removing the old cruft is something I have found often to be essential.

I did. And this time, it didn't work. :-) I do agree with you on the
principle of that, BTW. So no slam intended; it just didn't solve the
problem this particular time.

--Dave

[Charles A Edwards]

On Mon, 24 Oct 2011 16:55:11 -0700

Post by David Guntner
So, any ideas on what's causing the current headache, and what can be
done to clear it up?

David did you reboot after running XFdrake and Before you tried moving
to init 5?

The kernels in 2011.0 are all configured with, and boot, with kms
enabled.
When you switch from from a 'free' driver to a proprietary driver,
either nvidia or fglrx, there can/will be major issues with X when
kms is enabled.....thus the need for the reboot.

When you use XFdrake to select a proprietary driver it will auto add
'nokmsboot' append to the kernel which disables kms on subsequent boots.


Charles

[David Guntner]

Hi, Charles! I was wondering if you were still around. :-)

Post by Charles A Edwards
On Mon, 24 Oct 2011 16:55:11 -0700

Post by David Guntner
So, any ideas on what's causing the current headache, and what can be
done to clear it up?

David did you reboot after running XFdrake and Before you tried moving
to init 5?

I've rebooted so many times I've lost count. :-)

Post by Charles A Edwards
The kernels in 2011.0 are all configured with, and boot, with kms
enabled.
When you switch from from a 'free' driver to a proprietary driver,
either nvidia or fglrx, there can/will be major issues with X when
kms is enabled.....thus the need for the reboot.
When you use XFdrake to select a proprietary driver it will auto add
'nokmsboot' append to the kernel which disables kms on subsequent boots.

I did notice that append in my lilo.conf file; was wondering what it was
or what had put it there. I just tried taking it out, running lilo, and
rebooting again. However, a "telinit 5" is still failing to start X up.

--Dave

[Jim Beard]

Post by David Guntner

Post by Charles A Edwards
When you use XFdrake to select a proprietary driver it will auto add
'nokmsboot' append to the kernel which disables kms on subsequent boots.

I did notice that append in my lilo.conf file; was wondering what it was
or what had put it there. I just tried taking it out, running lilo, and
rebooting again. However, a "telinit 5" is still failing to start X up.

When you are having problems with the graphics desktop/run level
5, boot to run level 3 (add a 3 to the options for the kernel),
always. Then, in run level 3, log in to at least two ttys (tty1
plus Cntl-Alt-F2 to get a second tty and log in there). The
shift to runlevel 5 (or use of startx) will send your display to
tty7 (or maybe tty8), but if that fails you can use Cntl-Alt-F2
to get to a working terminal (usually, that too can be bolluxed)
or use Cntl-Alt-F1 to look for any messages of interest, and of
course you can try Cntl-Alt-12 to look for messages there, as
well as look in /var/log/ messages and Xorg.0.log.

Cheers!

jim b.

[David Guntner]

Post by David Guntner

Post by Charles A Edwards
When you use XFdrake to select a proprietary driver it will auto add
'nokmsboot' append to the kernel which disables kms on subsequent boots.

I did notice that append in my lilo.conf file; was wondering what it was
or what had put it there. I just tried taking it out, running lilo, and
rebooting again. However, a "telinit 5" is still failing to start X up.

When you are having problems with the graphics desktop/run level 5, boot
to run level 3 (add a 3 to the options for the kernel), always.

Yes, I've been booting to run level 3 and then trying to switch via a
telinit command. :-)

Then,
in run level 3, log in to at least two ttys (tty1 plus Cntl-Alt-F2 to
get a second tty and log in there). The shift to runlevel 5 (or use of
startx) will send your display to tty7 (or maybe tty8), but if that
fails you can use Cntl-Alt-F2 to get to a working terminal (usually,
that too can be bolluxed) or use Cntl-Alt-F1 to look for any messages of
interest, and of course you can try Cntl-Alt-12 to look for messages
there, as well as look in /var/log/ messages and Xorg.0.log.

Ok, I tried running a tail -f on /var/log/Xorg.0.log. When executing a
"telinit 5" command, nothing new appeared there. The syslog did show
the error messages again.

Also, upon issuing a "telinit 3" to restore the system to a non-GUI
state (even though there isn't one running), the log showed the

Oct 25 19:18:27 janet init: Switching to runlevel: 3
Oct 25 19:18:29 janet udevd[5616]: kernel-provided name 'capi' and NAME= 'capi/' disagree, please use SYMLINK+= or change the kernel to provide the proper name
Oct 25 19:18:29 janet udevd[5616]: mknod '/dev/capi/.udev-tmp' 68:0 020600 failed: Operation not permitted

It's been doing that all along, too. I just don't think I've mentioned
it before. *Again* with the udevd complaints here (in the log). I'd
almost be willing to bet money that there's something supposed to be
happening with udevd (that isn't happening) to set up some kind of
connection that X needs to use when running in runlevel 5 mode....

Now, for an *interesting* tid bit. I decided, "What the heck is it
going to hurt?," and as my standard user I did a startx command. I did
get a GUI screen. Nothing new appeared in Xorg.0.log, there were no
error messages showing up in the syslog, and I have *no* idea what
desktop manager I was in. It sure as heck wasn't my usual KDE session,
though, I'll tell you that. :-)

Is there any way to tell startx what desktop manager to use?

--Dave

[Charles A Edwards]

On Tue, 25 Oct 2011 19:35:34 -0700

Post by David Guntner
Is there any way to tell startx what desktop manager to use

startx startkde for kde
startx starte16 for enlightenment
startx startlxde for lxde
startx startxfce4 for xfce
startx starticewm for icewm (the default if no wm is
specified)

/etc/X11/wmsession.d/ will show all the wm's installed



Charles

[David Guntner]

Post by Charles A Edwards
On Tue, 25 Oct 2011 19:35:34 -0700

Post by David Guntner
Is there any way to tell startx what desktop manager to use

startx startkde for kde
startx starte16 for enlightenment
startx startlxde for lxde
startx startxfce4 for xfce
startx starticewm for icewm (the default if no wm is
specified)
/etc/X11/wmsession.d/ will show all the wm's installed

Cool, thanks. The files there consist of:

01KDE
07IceWM
16evilwm
29drak3d

Based on your comment above, I guess my unknown desktop manager was
IceWM. :-)

Well, I did a "startx startkde" to fire it up, and got my interface. At
least, my wallpaper was there and it remembered my last set of windows
and virtual desktops and so on. I'll definitely say that the new KDE
looks different! :-)

I'm not sure if this was just a fluke of timing, but I did see the
following in the syslog once I selected the logout option to return to

Post by Charles A Edwards
Oct 25 20:53:06 janet kernel: akonadi_agent_l[13126]: segfault at 7f5471ee22b0 ip 00007f5471ee22b0 sp 00007fffb47d9bd8 error 15 in libstdc++.so.6.0.16[7f5471edc000+8000]
Oct 25 20:53:06 janet kernel: akonadi_agent_l[13182]: segfault at 7f608ff5f2b0 ip 00007f608ff5f2b0 sp 00007fff44487fa8 error 15 in libstdc++.so.6.0.16[7f608ff59000+8000]
Oct 25 20:53:06 janet kernel: akonadi_agent_l[13127]: segfault at 7fa731de02b0 ip 00007fa731de02b0 sp 00007fffff308278 error 15 in libstdc++.so.6.0.16[7fa731dda000+8000]
Oct 25 20:53:06 janet kernel: akonadi_agent_l[13156]: segfault at 7fd27fac62b0 ip 00007fd27fac62b0 sp 00007ffff6844fd8 error 15 in libstdc++.so.6.0.16[7fd27fac0000+8000]
Oct 25 20:53:06 janet kernel: akonadi_agent_l[13128]: segfault at 7f7a02f7d2b0 ip 00007f7a02f7d2b0 sp 00007fff68ce3308 error 15 in libstdc++.so.6.0.16[7f7a02f77000+8000]
Oct 25 20:53:06 janet kernel: akonadi_agent_l[13129]: segfault at 7f7800b992b0 ip 00007f7800b992b0 sp 00007fff32e2b1a8 error 15 in libstdc++.so.6.0.16[7f7800b93000+8000]
Oct 25 20:53:06 janet kernel: akonadi_agent_l[13200]: segfault at 7f21dd4402b0 ip 00007f21dd4402b0 sp 00007fff71f29518 error 15 in libstdc++.so.6.0.16[7f21dd43a000+8000]
Oct 25 20:53:13 janet mdkapplet[13085]: Received SIGHUP (probably an upgrade has finished), restarting applet.

So, the big question becomes: If I can startx into the GUI, *why* can't
I set my system to run level 5 without the X desktop error messages in
the log (and a lack of a sign-on window when nobody is logged in)....?

--Dave

[Jim Beard]

Post by David Guntner
I'm not sure if this was just a fluke of timing, but I did see the
following in the syslog once I selected the logout option to return to

Post by Charles A Edwards
Oct 25 20:53:06 janet kernel: akonadi_agent_l[13126]: segfault at 7f5471ee22b0 ip 00007f5471ee22b0 sp 00007fffb47d9bd8 error 15 in libstdc++.so.6.0.16[7f5471edc000+8000]
Oct 25 20:53:06 janet kernel: akonadi_agent_l[13182]: segfault at 7f608ff5f2b0 ip 00007f608ff5f2b0 sp 00007fff44487fa8 error 15 in libstdc++.so.6.0.16[7f608ff59000+8000]
Oct 25 20:53:06 janet kernel: akonadi_agent_l[13127]: segfault at 7fa731de02b0 ip 00007fa731de02b0 sp 00007fffff308278 error 15 in libstdc++.so.6.0.16[7fa731dda000+8000]
Oct 25 20:53:06 janet kernel: akonadi_agent_l[13156]: segfault at 7fd27fac62b0 ip 00007fd27fac62b0 sp 00007ffff6844fd8 error 15 in libstdc++.so.6.0.16[7fd27fac0000+8000]
Oct 25 20:53:06 janet kernel: akonadi_agent_l[13128]: segfault at 7f7a02f7d2b0 ip 00007f7a02f7d2b0 sp 00007fff68ce3308 error 15 in libstdc++.so.6.0.16[7f7a02f77000+8000]
Oct 25 20:53:06 janet kernel: akonadi_agent_l[13129]: segfault at 7f7800b992b0 ip 00007f7800b992b0 sp 00007fff32e2b1a8 error 15 in libstdc++.so.6.0.16[7f7800b93000+8000]
Oct 25 20:53:06 janet kernel: akonadi_agent_l[13200]: segfault at 7f21dd4402b0 ip 00007f21dd4402b0 sp 00007fff71f29518 error 15 in libstdc++.so.6.0.16[7f21dd43a000+8000]
Oct 25 20:53:13 janet mdkapplet[13085]: Received SIGHUP (probably an upgrade has finished), restarting applet.

So, the big question becomes: If I can startx into the GUI, *why* can't
I set my system to run level 5 without the X desktop error messages in
the log (and a lack of a sign-on window when nobody is logged in)....?

libstdc++.so.6.0.16 is a standard (critical) library. The
segfault indicates something is out of kilter. It could be you
do not have the latest version of libstdc++ (not likely) or that
there is a piece of code lying around that expects the old version.

If the new version of libstdc++ was recently installed, you may
need to logout out of the desktop and back in, or maybe log out
and in as you/user, or possibly reboot to get the new version
fully integrated. If the problem is old cruft lying around, you
may need a new version of something, or need to get rid of tmp
files, or maybe need to remove old config files with something like
rm -rf $HOME/.kde4
and let the system create them anew.

Cheers!

jim b.

[David Guntner]

Post by Jim Beard
libstdc++.so.6.0.16 is a standard (critical) library. The
segfault indicates something is out of kilter. It could be you do not
have the latest version of libstdc++ (not likely) or that there is a
piece of code lying around that expects the old version.
If the new version of libstdc++ was recently installed, you may need to
logout out of the desktop and back in, or maybe log out and in as
you/user, or possibly reboot to get the new version fully integrated.
If the problem is old cruft lying around, you may need a new version of
something, or need to get rid of tmp files, or maybe need to remove old
config files with something like
rm -rf $HOME/.kde4
and let the system create them anew.

Well, thanks to you for all the time, help & info. Thanks also to
Charles & David for their input as well. However, I've gotten to the
point where I'm Just Giving Up.

I can't get "telinit 5" to bring the system into a normal GUI mode.
While I *can*, as it turns out, do a startx to get into it after logging
in as a normal user in run level 3 (which is not the desirable scenario
for me anyway), I can't get any sound to work. Any sounds coming out
don't actually play until I cntrl-alt-f1 back to the terminal where I
started X - then anything that played is all queued up and I get to hear
it. Upon logging out and returning to terminal 1 (and it won't really
log out until I manually switch back so the "shutting down" sound can
play), there's tons and tons and tons of various error messages that
blast out at this point.

This particular upgrade is well and truly borked. At this point, I
think that while time-consuming, simply burning the DVD .iso file &
using that to do a clean install and then adding back in the missing
stuff from the online mirrors, and painstakingly putting all the config
files back from a copy of /etc (as well as restoring users by copying
over their passwd and shadow entries to preserve their passwords), etc.,
etc., etc., will actually consume LESS time than trying to get this
abortion of an upgrade working fully again.

I haven't had an in-place upgrade go this badly since the last time I
tried to upgrade a Windows system (and I don't bother trying with those
any more - it's always a clean install now since upgrades there NEVER
work). :-( I've always like the fact that with Linux (or at least
Mandriva; I don't know about the other distros), I *could* upgrade in
place with only a relatively few kinks that had to be worked out and
cleaned up afterwords. That sure wasn't the case this time around....

--Dave

[Jim Beard]

Post by Charles A Edwards
On Tue, 25 Oct 2011 19:35:34 -0700

Post by David Guntner
Is there any way to tell startx what desktop manager to use

startx startkde for kde
startx starte16 for enlightenment
startx startlxde for lxde
startx startxfce4 for xfce
startx starticewm for icewm (the default if no wm is
specified)
/etc/X11/wmsession.d/ will show all the wm's installed

startx KDE4
startx GNOME

You can also put the choice of desktop in .desktop in your home
directory and let the x-startup script /etc/X11/Xsession find
that. (Look below line 82 that reads,
# now, we see if xdm/gdm/kdm has asked for a specific environment

Cheers!

jim b.