> Someone broke the handling of machines without PCI
between test2 and test3.
My machine is only 3 months old and contains -
verified with AIDA - 5 PCI slots.
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
If both yp and ldap automounter maps are changed, the
FC2T3 automounter will not recognize the change unless
he receives a HUP signal.
With FC1 at least yp map changes are accepted immediately
without any intervention on the client hosts!
I am afraid it is a feature?
(And the feature --ghost will not work: only mounted maps
are shown in the yp-map directory)
--
mfg
Herbert Gasiorowski
http://www.mathematik.uni-marburg.de/~gasi/
Hello-
> Yep -- I'm in the same boat. I didn't move to FC1 because of this, but
> now RHL9 is EOL I have to move to something and working FireWire is
> going to have to be a deciding factor.
>>Firewire was/is working in FC1...
maybe officially it was supported but the implementation was quite buggy and
IMHO unusable (at least for removable disks). The FC2 distribution with the 2.6
kernels are definitely a tremendous improvement over FC1.
btw, i read somewhere that FC2 will be shipping with a 2.6.6-* kernel. i've
been following the changelog on kernel.org and i've noticed a lot of ieee1394
fixes so i'm optimistic FC2 and firewire will be working as intended upon
shipping.
also, i recommend the following setup for optimal firewire performance for the
time being:
[root@markf78 home]# rpm -q fedora-release initscripts SysVinit kernel
fedora-release-1.92-1
initscripts-7.50-1
SysVinit-2.85-25
kernel-2.6.3-2.1.253.2.1 (last known working firewire kernel)
NB. be sure to "/sbin/chkconfig kudzu off" otherwise the setup will kernel
panic at boot. i've experienced no problems, bugs, or any other errors with the
above setup.
hope this helps...
mark. :-)
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
Okay. Now it's *really* not working. I'm not sure exactly what I did,
but now when I try to connect to an SFTP resource, nothing happens. The
"Do you want to cancel opening this thing?" window pops up and then "The
action associated with sftp:foo.bar.com is invalid" pops up asking me to
associate a new action.
Please help. I really loved being able to play songs in Rhythmbox over
sftp.
-jag
--
Joshua Adam Ginsberg <joshg(a)brainstorminternet.net>
Network Operations -- Brainstorm Internet
I have an older PIII Dell Latitude that works fine with FC1. With FC2 Test 3,
it will not start the PCMCIA NIC (PCNET_CS). If I remember correctly, it
needs to start yenta, and its not.
Byte
I have FC2T3 installed with 2.6.5-1.327 and I have never had any problem
running firestarter from the icon. I just installed 2.6.5-1.349 and rebooted
and I get this message from both kernels when I click on the icon
"Insufficient privileges
You must have root user privileges to use Firestarted"
I don't want to give the user root privileges and normally it ask for root
password when the icon is clicked.
I can start Firestarter from the shell as su and I noticed it complains about
"FATAL: Module bsd_comp not found"
any solution?
Olu
It was in FC2T2 but it cannot be found in FC2T3. I need to load some modules
and it is a pita to manually load them.
One is usb-storage for the flash drive and the other is ndiswrapper for wlan
connection
Thanks
Olu
I just rebooted after updating to today's development changes. I could
not bootup in either runlevel 3 or 5 with either kernel-2.6.5-1.327
or kernel-2.6.5-1.349. I could boot to runlevel 1 with either kernel
version.
Anyway, I ran "chkconfig --level 3 kudzu off" and then booted into
runlevel 3. I am running kernel 2.6.5-1.349 and it seems to work
alright. Getting past "checking hardware" is a little hard to figure out
for me anyway.
I'll try to run kudzu -p in a terminal and see what is up later.
Jim
I have kudzu-1.1.58-1 installed.
Hello-
On Tue, May 04, 2004 at 02:54:27PM -0700, Mark Fonnemann wrote:
>
> p.s. does it bother anyone else that rsync does not follow the typical unix
> syntax of "application dest src" and instead uses the described "application
> src dest"?
>>Hm, let us see:
>>cp ....
>>mv ....
>>I wonder how this claimed "typical unix syntax" is really typical?
>>If you have an option which allows to specify a target other than
>>a default then this is not what you may think it is.
(snip)
sorry, i don't know what i was thinking.... forgive me. i meant to remark how
annoying it is that most C macro functions (strcpy, etc.) and Unix functions
like rsync have different syntax. i spend most of my time programming in C so i
always get this simple thing confused...
e.g. strcpy(dst, src)
cp src, dst
anyways, sorry for wasting everyone's time with this stupid remark...
mark.
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
gdm doesnt seem to want to respond to XDMCP queries, when the host
is chosen from my main chooser/X server...
ie. Xnest :5 -indirect somemachine_that_works_fine
and then choose the F2 machine, i get a blank screen
Xnest :5 -query the_f2_machine
works fine
Turning on gdb debugging, I get this in the logs:
(is this a IPv6 thing? -- note I'm only using v4)
May 4 20:04:18 spiderman64 gdm[7147]: gdm_xdmcp_decode: Received
opcode QUERY from client ::ffff:172.16.35.142
May 4 20:04:18 spiderman64 gdm[7147]: gdm_xdmcp_handle_query:
Opcode 2 from ::ffff:172.16.35.142
May 4 20:04:18 spiderman64 gdm[7147]: gdm_xdmcp_send_willing:
Sending WILLING to ::ffff:172.16.35.142
May 4 20:04:25 spiderman64 gdm[7147]: gdm_xdmcp_decode: Received
opcode FORWARD_QUERY from client ::ffff:172.16.35.142
May 4 20:04:25 spiderman64 gdm[7147]:
gdm_xdmcp_handle_forward_query: Bad address
May 4 20:04:27 spiderman64 gdm[7147]: gdm_xdmcp_decode: Received
opcode FORWARD_QUERY from client ::ffff:172.16.35.142
May 4 20:04:27 spiderman64 gdm[7147]:
gdm_xdmcp_handle_forward_query: Bad address
May 4 20:04:31 spiderman64 gdm[7147]: gdm_xdmcp_decode: Received
opcode FORWARD_QUERY from client ::ffff:172.16.35.142
May 4 20:04:31 spiderman64 gdm[7147]:
gdm_xdmcp_handle_forward_query: Bad address
--
// scopira.org | ninjacoder.com //