Damian Menscher <menscher(a)uiuc.edu>@redhat.com on 04/07/2004 04:57:13 PM
> On Wed, 7 Apr 2004, Jeff Elkins wrote:
> > I'm getting failure messages on my nfs mounts i.e. :
> > mount to NFS server 'music.elkins' failed: server is down.
> > nsfd appears to be running and I didn't see anything suspicious in the
> > The servers are up and running and have other clients connected.
> You didn't mention what steps you took to debug it:
> Can you ping the server?
> What is the output of rpcinfo -p servername?
> Does the server have access restrictions (firewall, TCP Wrappers, etc)?
I have the same symptoms...
rpcinfo says that nfs et.al. are running.
Something has changed in test 2, since the same PC running RH9
accesses that host just fine.
I don't know the right way to fix this, but something is definitely broken;
and something needs to be fixed, one way or the other. The question is what
exactly needs to be fixed.
Consider something like this:
AC_TRY_LINK_FUNC(res_query, AC_MSG_RESULT(yes), AC_MSG_RESULT(no))
Here's what happens on x86_64:
gcc -o conftest -g -O2 -Wall -I.. -I./.. conftest.c -lresolv >&5
/tmp/ccW7EeDX.o(.text+0x7): In function `main':
/home/mrsam/src/courier/authlib/configure:5160: undefined reference to
collect2: ld returned 1 exit status
configure:5147: $? = 1
configure: failed program was:
[ blah blah blah ]
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char res_query ();
| main ()
| res_query ();
| return 0;
The same exact test on FC1 x86 will work.
The reason appears to be that you have to #include <resolv.conf> on x86_64
in order to succesfully pull res_query() out of libresolv.so. You don't
need to do this on x86, and the test program generated by AC_TRY_LINK_FUNC
does not include any headers, but uses a manual prototype.
So, what now?
I attempted to install FC3T1 on a USB drive using expert mode. It seems
that all the proper files installed on the disk. The disk is a laptop
disk contained inside a usb - ATA adapter and seems to work with the
proper modeles loaded.
Are there any plans to get the module needed to mount USB disks loaded
soon enough to be able to boot from these disks.
My grub.conf file is in the attached file.
There is a lot of interest in getting this concept to work.
The duck hunter trained his retriever to walk on water.....
"Notice anything?" the owner asked eagerly.
"Yes," said his friend, "I see that fool dog of yours can't swim."
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd2,0)
# kernel /vmlinuz-version ro root=/dev/sda2
# initrd /initrd-version.img
title Fedora Core (2.6.7-1.478)
kernel /vmlinuz-2.6.7-1.478 ro root=LABEL=/12 rhgb quiet
the plan is to do a kernel update friday or monday (depending on the
amount of things that turn up in this testing). There is a 424 kernel in
the testing dir on the ftp repository and on
One of the last minute changes is a series of patches to the input
subsystem that are supposed to fix a lot of the "tapping my laptops
touchpad doesn't work" bugs. So please beat hard on this kernel...
Arjan van de Ven
>Simon Sedgwick wrote:
>> I've just installed FC3-test1 on a spare box I've got laying >about.
>> was a clean install onto a disk that previously had FC1 on it and
>> fine. I chose a straight workstation install and performance >during
>> install process was okay.
>> After it had finished installing I rebooted the machine and
>> was fine until the kernel had decompressed the it came up with >the
>> following error: (dmesg)
>> agpgart: Detected an Intel i815 Chipset, but could not find the
>> secondary device.
>> agpgart: Detected an Intel i815 Chipset.
>> agpgart: Maximum main memory to use for agp memory: 439M
>> agpgart: AGP aperture is 64M @ 0xf8000000
>> Anything obvious spring to mind chaps?
>What is the second card that you have setup? I have a system with >an
>Intel 815 video card that is working fine.
>With another Dell computer with an Intel 828 656 card (810 driver) >I
>2 hours out of X before the following process die. I thought >rd-bomb
>some 2 hr timer before I found out that it was a screensaver.
>This is an agpgart error also.
>[drm:i830_wait_ring] *ERROR* space: 131052 wanted 131064
>Hopefully this problem will be gone for FC3T2.
Well I don't have a secondary graphics adaptor in it. I tried installing
FC2 and that does the same. Install goes fine but on first boot up it
runs like a dog. I've just reinstalled FC1 to make sure it's not a
hardware problem and thats running sweet. Shame because I was just
getting into this whole spacial Nautilus thing :-(
I failed to notice when precisely this happened but most likely
as a side effect of recent updates (and this is not include
'dircolors', i.e. coreutils package which was installed on the
box in question on Sat 17 Jul 2004). The gist of the problem
is that if you are in X and in terminal window you type
'dircolors --sh', or 'dircolors --sh /etc/DIR_COLORS', or similar
then an output is
but if you do that on a console then you will get what you expect.
I tried 'gnome-terminal' and 'xterm' so this does not seem to
be an "improvement" in 'gnome-terminal'.
This is actually quite painful because if you do now
'ssh some.other.machine' then you will get the same deal.
In /etc/profile.d/colorls.sh you will find a code which says:
eval `dircolors --sh "$COLORS"`
[ -z "$LS_COLORS" ] && return
so these aliases:
alias ll='ls -l --color=tty' 2>/dev/null
alias l.='ls -d .* --color=tty' 2>/dev/null
alias ls='ls --color=tty' 2>/dev/null
are never defined so depending on if you logged from an "older"
Linux machine and/or from a console or a terminal window you are
getting an enviroment which looks and behaves differently.
I would hate trying to explain that to my users.
I would file a bug but I am not really sure what is really
responsible for that "great feature". So far I failed to notice
where this may be even documented but something tells me that
TERM=gnome may be responsible. If this is really the case then
alias dircolors='TERM=xterm \dircolors'
all over the place would work around that but this still does
nothing to older Linux hosts where you may want to login unless you
do that there as well. '[ "$TERM" = gnome ] && export TERM=xterm'
seems like a more radical solution. Hm, maybe in an alias for ssh,
with a TERM replacement like above, instead. OTOH 'dircolors'
documentation does not mention anything that its output may be
TERM dependent. Another bug?
Accidentally I noticed that 'fam' disappeared (likely) from all
mirrors. Last time I looked there was something like
but if you would try to retrieve that you would get "404: Page not
found" instead. No recompiled binaries in "development".
At least the current nautilus version depends on fam so, unless
some deep nautilus rewrite is coming, that vanishing act seem
to be a result of some hiccup.