autofs - automount - yp maps
by Robert Cavey
Trying to get started on Migrating from RedHat 9.0 to FC2 when it
releases. We use NIS for auth and mounting homedirs and shares in a
mixed Solaris, SGI and Linux environment.
VERS and ARCH because of the different platforms.
# ypcat auto.tools
-rw,intr,vers=$VERS <host_server>:/automnt/tools/share
-rw,intr,vers=$VERS <host_server>:/automnt/tools/lib/$ARCH
-rw,intr,vers=$VERS <host_server>:/automnt/tools/bin/$ARCH
# ypcat auto.home
<<<<SNIP>>>>
-rw,intr,vers=$VERS <host_server>:/homedir:<username>
<<<<SNIP>>>>
In RH9 we modified the line for localoptions in /etc/init.d/autofs
#
# NOTE Just for giggles to to pass "nfsvers and vers" to server
localoptions=' -D ARCH=linux8.0 rsize=32768,wsize=32768,nfsvers=3,vers3'
This DOES not work in FC2 .... It fails to mount any of the YP map
related mounts.
I even tried: localoptions=' -D ARCH=linux8.0 rsize=32768,wsize=32768'
and still does not mount.
automount complains about vers option now and not before, even removing
that options still fails to mount homedir.
I've had to create file maps local to the test machine. Has that much
changed in the new automount versions??
RH9.0# automount --version
Linux automount version 3.1.7
RH9.0# mount --version
mount: mount-2.11y
----
FC2t2# automount --version
Linux automount version 4.1.1
FC2t2# mount --version
mount: mount-2.12
Anyone seeing strange behavior in automount with yp ?
TIA
19 years, 12 months
hdd: status error
by Hannes Mayer
Hi all!
I just plugged a spare harddisk in my production machine, installed
test3 and all went very well :-D
ATI Radeon 7000, Flattron 995F detected; DDC worked, so I got the full
range of screen-resolutions from the beginning (despite the failing
DDC on my test machine)
Just one possibly minor issue - from dmesg:
hdd: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
hdd: status error: error=0x20LastFailedSense 0x02
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: ATAPI reset complete
This appears multiple times!
After all the CD-writer is at least reading CD's (didn't try burning so far)
Anyone else seeing this ?
Cheers,
Hannes.
19 years, 12 months
Re: Downloading the 4GB DVD iso
by Fulko.Hew@sita.aero
Till <tillm(a)optushome.com.au>@redhat.com on 04/28/2004 11:23:01 AM said:
>On 29/04/04 00:21 Craig Emery Squawked:
>
>> On 28/04/04 15:12, Henry Hartley wrote:
>>>>>-----Original Message-----
>>>>>From: Robert La Ferla [mailto:robertlaferla@comcast.net]
>>>>>Sent: Wednesday, April 28, 2004 9:59 AM
>>>>>
>>>>>What are the best ways to download the 4GB DVD iso image on
>>>>>Windows? I tried the torrent but it was too slow.
>>
>> Surely if enough people here, used BitTorrent to "serve" the DVD iso,
>> you'd get it in no time?
>
>You'd think so, but I've never had BitTorrent do
>better than 20kb/s on cable, which is painfully
>slow :(
Last night, my BT started downloading at 1.5KB/s, but by the time it was
finishing,
I was getting 315KB/s download (on cable), but I was only uploading at
15KB/s.
After the download was finished, It was then uploading at 70KB/s!
BTW. My best download rate has been 356KB/s!
So its not BT thats slow.
19 years, 12 months
FC2 Test 3: USB Mouse
by Aaron Bennett
Has anyone had problems with their USB pointers under FC 2 T 3?
I just did an "Everything" install, and my USB mouse wouldn't work at
all. I put a PS2 style adapter on it and it works fine in the PS2 port,
but as a USB device it doesn't work at all.
19 years, 12 months
Re: java-1.5.0b1 plugin the only one working with mozilla in fc2t3.
by Fulko.Hew@sita.aero
>Fulko.Hew(a)sita.aero wrote:
>>>Maybe I'm missing something? Someone have it working in Mozilla with
>>
>> <1.5.0?
>>
>> Yes, I can confirm that I have seen working applets in Mozilla from
fc2t3
>> with Java 1.4.2 fetched and installed last night from sun.
>
>Augh. Are you using their .rpm, their .bin, or something else? I've been
>trying to use jpackage's repackaging of .bin, and it's possible that it
>breaks in weird ways.
I used the "RPM in self-extracting file" for
j2re-1.4.2_04-linux-i586-rpm.bin
and (as Robert Cavey said) make sure you use the 'gcc32' version when you
make the symlink, as described in
http://java.sun.com/j2se/1.4.2/manual_install_linux.html
19 years, 12 months
RE: OT - Journaling File Systems?
by Edwards, Scott (MED, Kelly IT Resouces)
A few minutes ago I wrote:
> I have started wondering if it is because of write caching on the hard
> drive.
I found this article http://sr5tech.com/write_back_cache_experiments.htm
which says: "The lesson is if write back cache is turned on, it is not
difficult to create metadata inconsistency or corruption at the file
system upon power failure.".
There are other links from that article, from the netbsd.org
http://mail-index.netbsd.org/tech-kern/2002/12/08/0031.html list:
> just to be specific, i'll post here what i told sean. having writeback
cache
> on allows the drive to delay and reorder writes. softdeps and
journaling
> fses depend on writes occurring in specific order. a drive's writeback
cache
> then obviously defeats the purpose of ordering those writes (which
softdeps
> and reiserfs, etc goto a good deal of trouble being correct).
>
> if you want *real* protection (that is, metadata consistency) you must
(on
> netbsd and linux) disable write cache. using writeback cache on the
drive,
> you're only protected from some things (accidently hit reset, kernel
panic).
> you're not protected from power failure. i have a ups, but i still
disable
> write cache. a ups can fail, and a machine's psu can fail as well.
And this from an article
http://www.linuxjournal.com/article.php?sid=4466 on ReiserFS in Linux
Journal:
> For performance benchmarks, some of the new drives have write-back
caching
> by default. This means the drive reports a write is completed before
it
> is actually on the media. The block is still in the drive's cache,
where
> the writes can be reordered. If this happens, metadata changes might
be
> written before the log commit blocks, leading to corruption if the
machine
> loses power. It is very important to disable write-back caching on
both IDE
> and SCSI drives.
I have run a few tests with an old IDE drive, which had write caching
turned
off by default (I assume that wcache = 0 in /proc/ide/hda/settings means
it's
off), and I haven't been able to corrupt the FS yet.
I am going to switch now to FC2T3 and test all 4 FS's again.
Thanks for everyone's suggestions and advice.
-Scott
19 years, 12 months
Re: java kills test3 dead?
by t l
When I installed j2sdk1.4.2_04, I needed to do the following to get things working:
1. the mozilla plugin is located in /usr/java/j2sdk1.4.2_04/jre/plugin/i386/ns610-gcc32/libjavaplugin_oji.so
2. so this needs to be linked into /usr/lib/mozilla-1.6/plugins/
3. with enforcing==1, the context is wrong, so you need to run
chcon --reference $x/libnullplugin.so libjavaplugin_oji.so
After that, I had no problems, even with enforcing==1.
tom
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
19 years, 12 months
Re: java-1.5.0b1 plugin the only one working with mozilla in fc2t3.
by Fulko.Hew@sita.aero
Konstantin Ryabitsev <icon(a)linux.duke.edu>@redhat.com on 04/29/2004
02:44:13 PM said:
> Lots of vain attemps later, I can certify that sun java 1.5.0 beta 1 is
> the only jre that still works with Mozilla in fc2 test3. This document:
> http://plugindoc.mozdev.org/faqs/java.html#Linux, claims that 1.4.2 from
> SUN is known to be working, but in fact it isn't. I cannot get any
> applet to load: they all display a nice red "x" in the top left corner.
>
> Maybe I'm missing something? Someone have it working in Mozilla with
<1.5.0?
Yes, I can confirm that I have seen working applets in Mozilla from fc2t3
with Java 1.4.2 fetched and installed last night from sun.
19 years, 12 months
Re: NVIDIA Drivers and Test 3
by Brian Stretch
> I downloaded the 5336 driver referred to from the minon.de site. There
> is something there saying this version from NVidia works with kernel
> 2.6. Obviously, it doesn't, or I wouldn't be posting this... :)
Under 32-bit Fedora you have to do a kernel recompile to get rid of
the 4K stacks patch that nVidia's closed-source driver doesn't like.
I did a clean build of kernel 2.6.6rc2 (rc3 is out now) using Fedora's
i686 .config as a starting point and that worked for me. powernow-k8
power management appeared to work, but that's under heavy
revision at the moment so I can see why the Fedora crew would
be hesitant to enable it in the prebuilt kernels. Hopefully it will be
there in FC2 final?
Under 64-bit Fedora no kernel recompile is needed, in fact I haven't
managed to successfully build a vanilla 2.6.6rc3 kernel yet. The minion.de
patched nVidia drivers worked perfectly and I'm able to play 64-bit
UT2004. I did have to manually add a line to /etc/modprobe.conf
(or whatever the replacement for modules.conf is), see the nVidia
README to find that (or do modprobe nvidia before firing up X).
Oh, and if UT2004 is segfaulting for you, see here:
https://bugzilla.icculus.org/show_bug.cgi?id=1413
I think 64-bit Fedora has reached the tipping point favoring the
migration away from 32-bit, if you can spare the funds to upgrade.
Very well done guys!
19 years, 12 months
java kills test3 dead?
by Keith Irwin
Folks--
I've installed sun's 1.4.2_4 SDK on my test3 system, then run a big ole
"maven" build a few times, and have jboss running, all from within my
normal user account (no SELinux).
Seems that running java a lot can take down the system. It "feels" like
a kernel problem, because it happens whether or not I'm in X.
Anyway, I was wondering if ANYONE else around here has had this problem?
I wrote about it here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121902
I have similar problems with test2, but thought it was just some weird
SELinux interaction.
Any confirmation?
Keith
19 years, 12 months