Fc3t2 not saving some settings

[ghaefb]

Ok. I noticed some weird behaveiour in fc3t2.

1) Anyone installed NVIDIA 6111 graphic driver?
I use installation script and kernel module is created, installation is completed without errors. Change xorg.conf, reboot my system and Xsession does not start. I get an error message. So I run the script again and all is working if I startx.
It looks like I have to install NVIDIA driver everytime I boot my machine...

2) I'm connected to router on ADSL. I correct my DNS info in system-config-network.
The next time I boot, the DNS info is wrong again. I have to correct my DNS IP everytime i boot...

3) I custom compile vanilla kernel like I did 100 times in Fc2, I get 'Warning: Unable to open an initial console' What's up with that.

:confused:

[superbnerd]

was this an upgrade from fc2 or a fresh install. if its a fresh install, i would deffinately file it a a bug. you may want to also file a bug report a nvidia's site.
habe you check the permeisions of the files system-config-network saves to?

[jrittvo]

On your first item, the new udev stuff causes the nvidia driver module not to load automatically. You can add a line in your /etc/rc.local for

/sbin/modprobe nvidia

and that should do the trick. If not, there is a more complicated solution, to add something into /etc/rc.sysinit, but I find that it keeps getting undone each time they release a new udev or some othe packages, so the rc.local is the better way for now, I think, since that file doesn't get changed all the time. Post back if you want the rc.sysinit method, though.

On your second item, see if you have a new service loading called NetworkManager or something similar. It is something they added to automatically switch between say a wireless and wired connection, depending on what is available at the time, but it is very buggy still and I think messed up DNS is one of the bugs. If that service is running, disable it from autostarting in runlevel 5 and runlevel 3, and see if that corrects the problem when you reboot.

On your 3rd item, I was getting that "initial console" error on boot before I had the nvidia straightened out, but that is all I know about that.

[superbnerd]

would puting the nvidia in the modprobe.conf have the same affect as putting it in the rc script?
and is the networkmanager something introduced by gnome or the fedora developers?

[jrittvo]

I have a line

alias char-major-195* nvidia

in my modprobe.conf, but it seems to be ignored. It used to be enough to get the nvidia module loaded, but the rc.sysinit script seems to handle things differently in FC3. The "official" fix is to find the section in rc.sysinit for "Initializing hardware . . ." and change the line

other=""

to

other="nvidia"

I believe the NetworkManager system is a Fedora thing. The idea is that it will try to use the "best" connection it finds available. If it can use a 100M wired Etherent, it will, before it uses a 11M 802.11b. It will be nice when they have it working. I think it is at version 0.2 now though. If you do any sort of upgrade install over FC2, you don't get it installed because it is a new package, but a full new FC3 test 2 install will include it and turn it on by default.

[superbnerd]

that "official" fix doesn't sound very user friendly. and its not really a fix at all if the modprobe.conf is still broken :( it's more like a temporary work around. it could easilt become a pain to have to keep managing the rc scripts and the modprobe.conf each time they release a new kernel.
wow, they included software thats in a beta stage of 0.2! now thats bleeding edge.

[jrittvo]

I agree that the fix isn't a fix, but that is sort of what the testing is all about. They can't fix what is broken until they know it is broken. At least they are able to suggest a work-around in the meantime. I do hope they fix it for real though, but they don't like the binary only (proprietary) stuff at all like the nvidia drivers and they don't need to go out of their way to make them work easily as a matter of policy, so I wonder if they will fix this issue any better.

[ghaefb]

I fixed my 1 and 2 problems.

1) Solution(by jrittvo): add line in /etc/rc.local -> '/sbin/modprobe nvidia'
2) Solution: I disabled service mDNSResponder. Which is enabled right now.. don't know why.

I still have no solution on my 'Warning: Unable to open an initial console'
This is my grub.conf:
default=1
timeout=3
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu

title Fedora Core3 test2 (2.6.8.1)
root (hd0,0)
kernel /boot/vmlinuz-2.6.8.1 ro root=301
initrd /boot/initrd-2.6.8.1.img

title Fedora Core3 test2 (2.6.8-1.541)
root (hd0,0)
kernel /boot/vmlinuz-2.6.8-1.541 ro root=LABEL=/
initrd /boot/initrd-2.6.8-1.541.img
Partitions are like this:
hda1 is a root / partition
hda2 is /home
hda3 is swap
I don't have separate /boot partition.

I use root=301 because if I use root=LABEL=/ I get error something like 'append correct root= option'
I used this on my Fc2, it worked.

[jrittvo]

I have an idea on the initial console problem . . . The udev stuff that Fedora has added is not compatible with plain kernel.org kernels at this point in time, according to some of the people on the Fedora Test and Fedora Development mailing lists. Maybe this is true, maybe not. If it is true, what may be happening is that udev is not making the console entry in /dev in a way, or in time, for what a plain kernel needs.

I'm having this kind of issue with arts not finding a /dev/dsp when it needs it at startup. I'm fixing that by adding (another line) into my /etc/rc.local file:

/sbin/MAKEDEV sound

This apparently forces certain entries in the /dev area related to sound devices that keeps my setup (using a kernel.org 2.6.7 kernel still) happy. You can run MAKEDEV with any argument that you find in the folder /etc/makedev.d

There is a "console" entry there, so you could try adding to your /etc/rc.local

/sbin/MAKEDEV console

It might work. There are also "tty" items in the "generic" entry and maybe some other of these MAKEDEV arguments. Look around in the contents of the files in /etc/makedev.d for anything else that might relate. I suspect that if you were to run all of them, you would essentially be recreating a full /dev setup the way it used to be, and that may be what is partly necessary to keep compatibility with non-Fedora specific kernels right now. At least it is something to try.

[ghaefb]

Thanks.
It's not working. I tried adding console and stuf in /etc/makedev.d to rc.local.
Kernel still won't boot.

It looks like I can't use vanilla kernel in test2.
I tried to use Fc3t2 kernel source, but It's not on the CDs.
And there is no option 'Kernel development' in package selection...
Why didn't they include kernel source?

it's a test release... :)

[jrittvo]

They are messing around with kernel-source too. If you go here:

http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/

you can get the kernel-2.6.8-1.541.src.rpm

I have not tried this yet myself, but this is supposedly how you work with it:

rpm -i kernel-2.6.8-1.541.src.rpm

rpmbuild -bp --target noarch /usr/src/redhat/SPECS/kernel-2.6.spec

and the sourcecode (as rpm file???) will end up in:

/usr/src/redhat/BUILD

Please let me know how you make out if you try this, because I plan to get into it myself later this weekend.

One last thing..... I think they only let you start picking and choosing packages if you do a "custom" install. If you select "workstation" or "development" or whatever, you don't get to see the individual areas. Honestly, I have just been updating and updating since FC1-T2 and I have not done a "fresh" install from the CDs since that first install, so I don't know if they have changed it any, but I bet not.

[ghaefb]

Thanks again. I will try the kernel source.
I always do a fresh install and chose "custom".

[jrittvo]

I just grabbed the kernel-2.6.8-1.541.src.rpm file and ran the two commands

rpm -i kernel-2.6.8-1.541.src.rpm
rpmbuild -bp --target noarch /usr/src/redhat/SPECS/kernel-2.6.spec

and it does work. It created a full source tree in

/usr/src/redhat/BUILD/kernel-2.6.8/linux-2.6.8

Later tonight I'll try building a kernel. I am hoping that my wireless card under ndiswrapper will still work with the Fedora 4k stacks. If it does, then I will stick with the Fedora kernels for a while. If not, then I don't know what I'll do -- trapped between needing more than 4k stacks and the possible conflicts between a vanilla kernel and Fedora's udev. I'm sure there will be some way, probably kernels from Linuxant. I'm not the only one who will be facing the problem.

[ghaefb]

I did that too. I does create a full source tree.
I used my old .config file and I couldn't compile.
Error message:
net/built-in.o(.text+0x5f97a): In function `install_req_dentry':
: undefined reference to `open_private_file'
net/built-in.o(.text+0x6cade): In function `tux_chroot':
: undefined reference to `chroot'
net/built-in.o(.text+0x6cb18): In function `tux_chroot':
: undefined reference to `chdir'
net/built-in.o(.text+0x6ce12): In function `user_req_startup':
: undefined reference to `tux_module'
net/built-in.o(.text+0x6cfda): In function `user_req_shutdown':
: undefined reference to `tux_module'
net/built-in.o(.text+0x6d3dc): In function `user_req_start_thread':
: undefined reference to `tux_module'
net/built-in.o(.text+0x6d743): In function `user_req_stop_thread':
: undefined reference to `tux_module'
net/built-in.o(.text+0x712c9): In function `handle_cgi_reply':
: undefined reference to `read'
net/built-in.o(.text+0x71c26): In function `exec_external_cgi':
: undefined reference to `write'
make: *** [.tmp_vmlinux1] Error 1

[jrittvo]

I just finished compiling. I got through it on the third try. I had basically the same error messages as you show above, so I disabled TUX which is some sort of new network device related option, and then it finally built ok. They have TUX defaulting to "on", so unless you specifically turn it off in a make menuconfig kind of thing, it will be there if you are working off an old .config, from before they added this TUX thing. They should really default any new things to "off" unless the kernel will not run at all without them.

I need to get some sleep before I try this kernel out now. I'll still need to rebuild my nvidia driver for it, assuming it will boot, and then try to get the ndiswrapper wireless card driver running with the 4k stacks. Either way, I also want to try a new vanilla kernel to see if it will run with this udev stuff.

[jrittvo]

Everything seems to be working well, at least during the first hour of testing it out. The wireless card is even working fine, despite the 4k stacks. The only glitch I saw so far was on shutting down to restart, which I have only done once -- the system crashed hard exiting X. I don't know yet if it will do that again.

[jrittvo]

The crash was everytime. When I switched from the nvidia driver to the plain stock nv driver, no more crash. Last night I started fooling with the 1.590 kernel just released into test2, and with that, the nvidia package will not even install. Everything else is fine though. So I am going to sit out nvidia for a while until it all settles down. It is not just Fedora, but Mandrake people too that are starting to have issues with it and kernels based on 2.6.8.1 and later, and I read that there will be an nvidia release to address the kernel changes at some point.

[ghaefb]

I didn't managed to make this kernel work.
I just hope this kernel issues will be fixed in final version of FC3

[giuliano]

Regarding the initial console problem...
I've got it to work doing the following
* I've booted from a live distro (knoppix 3.6 in my case)
* mounted all the partitions I have on the machine (hda2 in /mnt/hda2 and hda1 in /mnt/hda2/boot)
* chrooted to /mnt/hda2 using /bin/bash as shell
* /sbin/MAKEDEV console
* reboot

at this point I had problems accessing the hda2 partition so

* I've booted from a live distro (knoppix 3.6 in my case)
* mounted all the partitions I have on the machine (hda2 in /mnt/hda2 and hda1 in /mnt/hda2/boot)
* chrooted to /mnt/hda2 using /bin/bash as shell
* /sbin/MAKEDEV hda
* /sbin/MAKEDEV hdb
* /sbin/MAKEDEV hdc
* /sbin/MAKEDEV hdd
* reboot

now it seems to work fine

HTH

giuliano

[vinci]

Very good solution. I would add that one might need to create:

input
apm_bios
mem
cpu

with MAKEDEV