having trouble with JRE
by Sriram Bhamidipati
Hi folks
I am new to Java installation as i was a windows user and I didnt install
java before.
I am now using Fedora8 and trying to get JRE running Java applets launched
via firefox3
I havent been successful, despite installing jre package using both rpm and
yum installers couple of times.
jre-6u6-linux-i586.rpm
i have the following output of java version:
[root@localhost opt]# java -version
java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)
I see that the java is installed in below folder:
[root@localhost bin]# pwd
/usr/java/latest/bin
I tried the below executable:
[root@localhost bin]# ./java_vm
java_vm process: You need to set both JAVA_HOME and PLUGIN_HOME
[root@localhost bin]#
what should the above variables set to? Why yum installation take care of
this? I cant find the relevant documentation
Can some one help me go thru steps
Thanks in advance!
---Sriram
16 years
selinux update generates strange error message
by Petrus de Calguarium
After applying Sunday evening's updates, selinux-policy generated this error:
Updating : selinux-policy-targeted [ 9/18]
libsemanage.semanage_fc_sort: WARNING: semanage_fc_sort: Incomplete context.
libsemanage.semanage_fc_sort: WARNING: semanage_fc_sort: Incomplete context.
libsemanage.semanage_fc_sort: WARNING: semanage_fc_sort: Incomplete context.
libsepol.context_from_record: type prelude_lm is not defined
libsepol.context_from_record: could not create context structure
libsepol.context_from_string: could not create context structure
libsepol.sepol_context_to_sid: could not convert system_u:object_r:prelude_lm
to sid
invalid context system_u:object_r:prelude_lm
libsemanage.semanage_install_active: setfiles returned error code 1.
semodule: Failed!
16 years
Selinux / NM denial
by SternData
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I don't get this. What is Network Manager doing with /dev/root? Also,
Network Manager is not enabled in chkconfig.
Summary:
SELinux is preventing nm-system-setti (NetworkManager_t) "getattr" to
/dev/root
(fixed_disk_device_t).
Detailed Description:
SELinux denied access requested by nm-system-setti. It is not expected
that this
access is required by nm-system-setti and this access may signal an
intrusion
attempt. It is also possible that the specific version or configuration
of the
application is causing it to require additional access.
Allowing Access:
Sometimes labeling problems can cause SELinux denials. You could try to
restore
the default system file context for /dev/root,
restorecon -v '/dev/root'
If this does not work, there is currently no automatic way to allow this
access.
Instead, you can generate a local policy module to allow this access -
see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can
disable
SELinux protection altogether. Disabling SELinux protection is not
recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.
Additional Information:
Source Context
system_u:system_r:NetworkManager_t:s0-s0:c0.c1023
Target Context system_u:object_r:fixed_disk_device_t:s0
Target Objects /dev/root [ blk_file ]
Source nm-system-setti
Source Path /usr/sbin/nm-system-settings
Port <Unknown>
Host sds-desk.sterndata.com
Source RPM Packages NetworkManager-0.7.0-0.9.4.svn3675.fc9
Target RPM Packages
Policy RPM selinux-policy-3.3.1-64.fc9
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name catchall_file
Host Name sds-desk.sterndata.com
Platform Linux sds-desk.sterndata.com
2.6.25.6-55.fc9.i686
~ #1 SMP Tue Jun 10 16:27:49 EDT 2008 i686 i686
Alert Count 2
First Seen Sat 14 Jun 2008 02:12:27 PM CDT
Last Seen Sun 15 Jun 2008 09:06:17 AM CDT
Local ID 4eb3e516-3a69-4a76-8905-f2485b0e86ef
Line Numbers
Raw Audit Messages
host=sds-desk.sterndata.com type=AVC msg=audit(1213538777.704:14): avc:
~ denied { getattr } for pid=3063 comm="nm-system-setti"
path="/dev/root" dev=tmpfs ino=318
scontext=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023
tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file
host=sds-desk.sterndata.com type=SYSCALL msg=audit(1213538777.704:14):
arch=40000003 syscall=195 success=no exit=-13 a0=28e467d a1=bff648dc
a2=58fff4 a3=28e467d items=0 ppid=1 pid=3063 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295
comm="nm-system-setti" exe="/usr/sbin/nm-system-settings"
subj=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 key=(null)
- --
~ Steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkhVLe4ACgkQeERILVgMyvBTUQCfZD/VgciX19wxN06yvx9XsxO8
vSUAnjU/XZsEKB3lcVMVrT/N3VLERcpK
=WgdM
-----END PGP SIGNATURE-----
16 years
Re: (fedora) vpnc on fedora9 drops frequently
by Jouk Jansen
superprad(a)gmail.com wrote on 20-JUN-2008 18:49:04.54
>Has anyone noticed this on fedora-9. I use vpnc and it drops my network
>connection every few minutes of inactivity. I'll have to restart my network
>and reconnect through vpnc again.
Does it drop the network or only the VPN-connection. Normally the
VPN-servers are configured to drop the connection on inactivity (so they
will also drop when the client dies). I normally solve this by running a
"dummy" process which keeps activity on the line : i.e. a remote xclock
displaying on the remote vpn-client.
Jouk
Bush : All votes are equal but some votes are more equal than others.
>------------------------------------------------------------------------------<
Jouk Jansen
joukj(a)hrem.nano.tudelft.nl
Technische Universiteit Delft tttttttttt uu uu ddddddd
Kavli Institute of Nanoscience tttttttttt uu uu dd dd
Nationaal centrum voor HREM tt uu uu dd dd
Lorentzweg 1 tt uu uu dd dd
2628 CJ Delft tt uu uu dd dd
Nederland tt uu uu dd dd
tel. 31-15-2782272 tt uuuuuuu ddddddd
>------------------------------------------------------------------------------<
16 years
Yum upgrade from F8 to F9 with KDE desktop - installation notes
by Claude Jones
My apologies for double posting but correcting the subject with a fresh thread
seemed the best.
Maybe this might help others:
I'm starting from a Fedora 8 box that's been in continuous use since F6 using
yum upgrade to move up through each distro version - my desktop is KDE though
Gnome is also installed - I had installed the early beta packages of KDE4
from kde-redhat on this machine and had some problems, so I'd removed them.
Probably left some detritus behind, but, the box was running smoothly with no
major issues - the machine is a dual-core with 2GB ram, and my IP connection
is a 3mb/s DSL - the whole process took about three hours with a little
additional cleanup the next morning - currently, I'm typing these notes with
my newly upgraded system and I have no major issues. I use the proprietary
nVidia drivers from Freshrpms, and I had to install the latest nVidia driver
from Freshrpms along the way, which I did right after the installation of the
kernel in step 5; once I did that, the dkms package (which gets installed from
Freshrpms as a dependency to their package of the nVidia driver) took care of
building my kernel-module for the new kernel on the next reboot with no
intervention on my part. Building the nVidia kernel module adds about 15-20
seconds to booting but requires no user intervention and only happens when a
new kernel is installed.
I post this because I've always found the process of collecting all the
relevant info to do a yum upgrade a bit daunting. There is no guarantee this
will work on your machine, and I would strongly suggest you wait a spell
before trying this, to see if any of the more knowledgeable folk on this list
spot any mistakes or omissions in my procedure.
1) Download fedora 9 release rpm: here's one link
ftp://ftp.software.umn.edu/linux/fedora/releases/9/Fedora/i386/os/Package...
release-9-2.noarch.rpm
OR http://tinyurl.com/6yv9gd
2) Use your preferred method to install the above file:
rpm -Uvh fedora-release-9-2.noarch.rpm
from a root command prompt works for me
3) Navigate to /etc/yum.repos.d and use your preferred text editor to open
each *.repo file in there; you want to examine each mirror list or baseurl
line. If they are using dollar sign symbols to indicate version and
architecture, you're good (example:
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-
debug-$releasever&arch=$basearch) - leave things as they are. Some repos may
use specific version numbers (example:
http://download.fedora.redhat.com/pub/fedora/linux/updates/9/i386/)
In each case like this, you need to make sure that the number right before the
/i386 is a '9' -- I didn't have to modify any of my current *.repo files but I
did have to modify my smart channels as described just above.
4) Reboot, and when the 'Grub' line appears in your upper left hand screen tap
your space bar; that should present you a list of kernels. Highlight the
topmost kernel and press the letter 'a'; that will open a command line with
that kernel line and the cursor at the end of the line; press the spacebar and
then enter the number '3' then press enter.
You will boot to a command prompt.
Log in as 'root'
5) Run 'yum update kernel' - for me this resulted in a clean install of the
latest F9 kernel along with a couple of dependent packages - it also removed a
couple of kernel modules in the process which I allowed (I happen to run the
nVidia drivers and this was related to that - after installing the latest
kernel is a good time to install the nVidia proprietary drivers from freshrpms
if you use them - see opening paragraph up above for more regarding nVidia)
6) Repeat step 4 and run yum update; in my case this produced a ton of
activity and then a failure message due to dependency issues; read the screen
carefully at this point! Remove packages that can't install due to dependency
problems with 'yum remove [name of package]' - in my case, I had to remove
compat-gcc-34-c++, aquamarine, tellico, all beryll packages, mozilla-totem-
xine, and kdebase (your removals won't be exactly the same); I had to remove
kdebase because of issues with a package called extragear-plasma that was
failing due to dependencies. That took a little research, but was easily
figured out with the help of google. This was some of the detritus left over
from my trying the early KDE4 beta referred to above.
7) Eventually, you should get to a state where the update should proceed; mine
required 1393 package updates and installs plus some removals
8) Repeat step 4; you want to rename /etc/X11/xorg.conf - I used
mv xorg.conf xorg.conf.F8 to simply rename it and take it out of the picture
(xorg.conf used to be the configuration file for the xserver but it's no
longer used and keeping the file active can introduce font issues
that prevent many programs from opening)
9) Try a normal reboot
This is not intended as a definitive method, but, was derived from a careful
read of this webpage: http://fedoraproject.org/wiki/YumUpgradeFaq
plus reference to various posts from this mailing list. There are new tools
out there, and this may not be the best way to upgrade, but, having limited
time, and being familiar with this general process, I chose to go ahead this
way rather than investigate preupgrade and other methods I've heard reference
to.
One last note: I find the latest improvements to KDE4 to have resolved most of
the major issues I had with the first releases, and look forward to the
restoration of various functions that didn't get in yet. I'm running the
version that is made available from kde-redhat-unstable currently at 4.0.83
--
Claude Jones
Brunswick, MD, USA
16 years
Yum upgrade from F8 to F8 with KDE desktop - installation notes
by Claude Jones
Maybe this might help others:
I'm starting from a Fedora 8 box that's been in continuous use since F6 using
yum upgrade to move up through each distro version - my desktop is KDE though
Gnome is also installed - I had installed the early beta packages of KDE4
from kde-redhat on this machine and had some problems, so I'd removed them.
Probably left some detritus behind, but, the box was running smoothly with no
major issues - the machine is a dual-core with 2GB ram, and my IP connection
is a 3mb/s DSL - the whole process took about three hours with a little
additional cleanup the next morning - currently, I'm typing these notes with
my newly upgraded system and I have no major issues - I use the proprietary
nVidia drivers from Freshrpms, and I had to install the latest nVidia driver
from Freshrpms along the way, which I did right after the installation of the
kernel in step 5; once I did that, the dkms package (which gets installed from
Freshrpms as a dependency to the nVidia driver) took care of building my
kernel-module for the new kernel on the next reboot with no intervention on my
part. Building the nVidia kernel module adds about 15-20 seconds to booting
but requires no user intervention. It only happens when a new kernel is
installed.
I post this because I've always found the process of collecting all the
relevant info to do a yum upgrade a bit daunting. There is no guarantee this
will work on your machine, and I would strongly suggest you wait a spell
before trying this, to see if any of the more knowledgeable folk on this list
spot any mistakes or omissions in my procedure.
1) Download fedora 9 release rpm: here's one link
ftp://ftp.software.umn.edu/linux/fedora/releases/9/Fedora/i386/os/Package...
release-9-2.noarch.rpm
OR http://tinyurl.com/6yv9gd
2) Use your preferred method to install the above file:
rpm -Uvh fedora-release-9-2.noarch.rpm
from a root command prompt works for me
3) Navigate to /etc/yum.repos.d and use your preferred text editor to open
each *.repo file in there; you want to examine each mirror list or baseurl
line. If they are using dollar sign symbols to indicate version and
architecture, you're good (example:
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-
debug-$releasever&arch=$basearch) - leave things as they are. Some repos may
use specific version numbers (example:
http://download.fedora.redhat.com/pub/fedora/linux/updates/9/i386/)
In each case like this, you need to make sure that the number right before the
/i386 is a '9' -- I didn't have to modify any of my current *.repo files but I
did have to modify my smart channels as described just above.
4) Reboot, and when the 'Grub' line appears in your upper left hand screen tap
your space bar; that should present you a list of kernels. Highlight the
topmost kernel and press the letter 'a'; that will open a command line with
that kernel line and the cursor at the end of the line; press the spacebar and
then enter the number '3' then press enter.
You will boot to a command prompt.
Log in as 'root'
5) Run 'yum update kernel' - for me this resulted in a clean install of the
latest F9 kernel along with a couple of dependent packages - it also removed a
couple of kernel modules in the process which I allowed (I happen to run the
nVidia drivers and this was related to that - after installing the latest
kernel is a good time to install the nVidia proprietary drivers from freshrpms
if you use them - see opening paragraph up above for more regarding nVidia)
6) Repeat step 4 and run yum update; in my case this produced a ton of
activity and then a failure message due to dependency issues; read the screen
carefully at this point! Remove packages that can't install due to dependency
problems with 'yum remove [name of package]' - in my case, I had to remove
compat-gcc-34-c++, aquamarine, tellico, all beryll packages, mozilla-totem-
xine, and kdebase (your removals won't be exactly the same); I had to remove
kdebase because of issues with a package called extragear-plasma that was
failing due to dependencies. That took a little research, but was easily
figured out with the help of google. This was some of the detritus left over
from my trying the early KDE4 beta referred to above.
7) Eventually, you should get to a state where the update should proceed; mine
required 1393 package updates and installs plus some removals
8) Repeat step 4; you want to rename /etc/X11/xorg.conf - I used
mv xorg.conf xorg.conf.F8 to simply rename it and take it out of the picture
(xorg.conf used to be the configuration file for the xserver but it's no
longer used and keeping the file active can introduce font issues
that prevent many programs from opening)
9) Try a normal reboot
This is not intended as a definitive method, but, was derived from a careful
read of this webpage: http://fedoraproject.org/wiki/YumUpgradeFaq
plus reference to various posts from this mailing list. There are new tools
out there, and this may not be the best way to upgrade, but, having limited
time, and being familiar with this general process, I chose to go ahead this
way rather than investigate preupgrade and other methods I've heard reference
to.
One last note: I find the latest improvements to KDE4 to have resolved most of
the major issues I had with the first releases, and look forward to the
restoration of various functions that didn't get in yet. I'm running the
version that is made available from kde-redhat-unstable currently at 4.0.83
--
Claude Jones
Brunswick, MD, USA
16 years
GDM/X server question
by Reid Rivenburgh
I have a fairly obscure question that I may have asked here months
ago. It was probably mixed in with a bunch of other issues that I've
resolved, so I thought I'd ask again, just in case.
I'm always logged in to my machine (F9). I use gdmflexiserver to
switch to the gdm greeter when I leave the machine. I also run a
process that checks for idleness (using dbus-monitor) in case I walk
away and forget to switch; after 10 minutes, it runs gdmflexiserver.
It works well, but for one small detail: If I switch to the gdm
greeter but don't hit a key or move the mouse, DPMS never kicks in to
turn off the monitor. The server is configured to do that after a
period of time. If I move the mouse, then it seems to restart some
idle counter and it does turn it off. It's as if the gdm X server
thinks the monitor is off when it really isn't (i.e. the idle counter
is already beyond the DPMS setting). This is a problem when idleness
forces the switch and I'm not there to move the mouse.
I have two ideas for solutions: 1) Fake an event somehow after
switching; or 2) call "xset force dpms off" in my script. I don't
know if 1) is possible, especially since I don't necessarily know the
gdm screen's DISPLAY value (maybe there's a way to get it). I thought
2) would be easy, but it doesn't work, even if I do it as root. I
admit I don't understand the relationship between xset and DISPLAY.
Any suggestions...?
Thanks,
reid
16 years
Kernel numbers
by Jeff Stevens
What does it mean to see an rpm with a kernel of 2.6.10-1.741_FC3, when
we go to a site like http://www.kernel.org and see the latest kernel is
at 2.6.10? If one wanted to compile their own kernel from this site,
would they be losing fixes/etc. from the "-1.741_FC3" portion?
Thanks, still learning here...
--
Jeffrey Stevens
gpg --keyserver pgp.mit.edu --recv-keys D2E5A4E8
Key fingerprint: 1C86 8717 E485 FA4D B9EF 96E2 A1AC 4B00 D2E5 A4E8
16 years
Re: kde-redhat
by Petrus de Calguarium
I have enabled kde-unstable and kde-unstable-all. This allows me to use
kde4.0.83, a terrific improvement over kde4.0.5.
There are bugs, so be forewarned: kde-redhat is presently providing beta
releases (kde4.0.5 can at best be considered an alpha). And, yes, there are
some conflicts. I found that I had to uninstall kipi-plugins, digikam, libkipi
and libkdcraw. I prefer digikam to gwenview and the kipi-plugins are nicer to
use than ImageMagick, but I will likely only have to put up with this minor
inconvenience until the end of July, when kde4.1 is officially released.
This will get your system upgraded:
sudo yum --enablerepo=kde-unstable --enablerepo=kde-unstable-all update
Once kde has arrived at a more robust and stout level of maturity, I will
likely discontinue use of kde-redhat. I cannot predict how rocky the road back
to the official fedora repositories will be, but I expect that it will be a very
smooth one, as the version numbering and kde-sig should take care of that very
competently.
16 years
