I'm running Fedora 10 on a duo-core with 2GB RAM and an nVidia GF GTX260. Yesterday, I ran the update program.

Big mistake. In earlier versions of Fedora, it gave you a chance to avoid loading new kernel versions. Not anymore. The update program installed kernel 2.6.27.21-170.2.56.fc10.i686 (according to grub.conf) whether I liked it or not. OK, fine... I didn't REALLY want to do nVidia drivers today, but....

I downloaded the latest nVidia driver, 180.44 . I signed on as root, started a terminal session, switched the runlevel to 3 (telinit 3). At the text mode, I signed on as root and ran the nVidia driver script successfully. At least it said it was successful. I entered telinit 5, and got back a GUI.

I thought everything was OK, but when I started up today, I got a flickering cursor, a mostly blank screen, and a moving white block instead of a mouse pointer. The last text says something about the eth1 connection is up but the eth0 connection could not be established. (Well, that's because the only ethernet cable is plugged into eth1 and not eth0.) I can move that white block mouse around, but nothing has any effect except CTRL-ALT-DEL, which reboots.

I strongly suspect the nVidia driver didn't link to the new kernel properly, there's some kind of mismatch between the new kernel and the new nVidia driver, or a config file is out of whack somewhere.

So I decided to load the nVidia driver again. Fortunately, the previous kernel (2.6.27.19-whatever) was still loaded in grub.conf, so I booted to that. I signed on as root. I edited /etc/inittab to boot to runlevel 3 (which is supposed to not start the X server GUI, right?). I tried to boot to the problem kernel; same thing--flickering cursor, white block for mouse--definitely not the text mode sign on I was expecting.

OK, I'm thinking, maybe I need to boot to runlevel 2...? I'll boot to the previous kernel, edit /etc/inittab again....

When I booted to the previous kernel, X started. Now wait a minute. Isn't there just ONE /etc/inittab file? Regardless of which kernel I booted to, if inittab says runlevel 3, it should have come up in text mode--right? I'm very confused.

Here are the last two lines in /etc/inittab :
#id:5:initdefault:
id:3:initdefault:

Yet:
stuff]$ su
Password:
stuff]# /sbin/runlevel
N 5
stuff]#

Since the new kernel behaved exactly the same way regardless of inittab settings, I assume it booted to runlevel 5 both times, too--thus the same flickering cursor and white block mouse. Why did either kernel start in runlevel 5 after I changed inittab? (Hey, I'll worry with the nVidia drivers after this brain check is over.)

Thanks in advance for any responses.

I'd work on the run-level problem first. Then try going back to the previous video driver and see if that works with the new kernel. Dropping back to the old kernel and trying to use the video driver that's been built against the new kernel is bound to cause problems. (I'd actually be a bit surprised if the combination even worked at all.)

I would remove that commented-out line for level "5". I'm guessing that the system startup is (for some reason) missing the fact that the old run level line is commented out, using that setting, and ignoring the later level "3" setting. Seems screwy since most (if not all) inittabs I've ever seen have comments in them but the init process may not be treating those commented-out lines consistently. That should be an easy fix to try.

As for the nVidia problem:

What you've done seems reasonable but you probably didn't really need to update the nVidia driver just because the kernel has been updated.

My guess is that the new nVidia driver isn't quite right. I haven't run into the white block problem since I tried running an nVidia card/driver on an Opteron system a couple of years ago. Word was that the driver was not ready for prime time.

It's possible the the driver build didn't work but I think you'd have seen an error if that had happened.

If you still have the download for the previous nVidia driver sitting on disk, I'd suggest trying to rebuild that one for the new kernel instead of changing both the kernel and the video driver at the same time. At this point, you can't be sure just what's causing the problem.

Hope this helps.

Cheers...

Rick

initdefault is what it's says 'default'

Kernel able get desired runlevel as parameter.
You can check your grub (or lilo) config for the parameters passed to the kernel

Thanks for the responses!
Agreed. That's why I'm here instead of the nVidia forums.
It doesn't work that way. The nVidia driver is compiled into the kernel. When I boot the back level kernel, I'm using the slightly older nVidia driver that's built into it, not the new one.
OK, but this has always worked on previous versions of Fedora. The reason I did it this way is VI is the only text editor available in text mode. It is very easy to delete the pound sign (comment) and insert one on the next line. Plus, since I don't do this very often, it reminds me of what to do.
... Wait a minute while I give this a try....
THIS FIXED IT! Boy, is that weird. It ignored the comment # and processed the line anyway, then ignored the uncommented line. Nice....
Unfortunately, I did, precisely because it is compiled into the kernel.
No need. Once I got to runlevel 3 (using inittab instead of telinit), the nVidia driver installation succeeded.
Thanks for the suggestion. I'm using the default kernel parameters. I'm certainly no expert, but grub doesn't appear to change the runlevel by default.

IMPORTANT SAFETY TIP: Here's what I did WRONG on the first try:
I booted to a normal Linux GUI (X server started normally).
I downloaded the nVidia driver.
I started a terminal session.
$su
password:
#telinit 3
A lot of stuff happens...
Computer login:root
password:
#sh NVIDIA-[stuff].run
Follow the bouncing ball....
...installation successful OK
#telinit 6
But SOMETHING BAD HAPPENS. I get a blank screen when I try to boot.

Here's what WORKS:
Boot to a normal Linux GUI (start the X server normally).
Download the nVidia driver. Remember where you put it.
Start a terminal session.
$su
password:
#gedit /etc/inittab
Change:
id:5:initdefault:
To read:
id:3:initdefault:
Save the file and quit.
Reboot and choose the NEW kernel
Computer login:root
password:
#sh /whereIputit/NVIDIA-[stuff].run
Follow the bouncing ball....
...installation successful OK
#vi /etc/inittab
Change:
id:3:initdefault:
To read:
id:5:initdefault:
Shift-ZZ to save the file and quit.
#telinit 6
Now it works just fine. It makes no sense to me that the first (much shorter) method does not work and the second (brute force) method does. If anyone can explain this, I'd love to hear it!

I've personally never found much help over there.

Doesn't it generate a new module under /lib/modules/...? (Whatever. It's been a while since I've gone spelunking looking for drivers.) I knew this by heart back when doing your own kernel compiles was commonplace.

There's always "ed". (ducks) It's primitive but it doesn't force to you set set a terminal type before you can use it.

Yeah... I know there are places where commented out lines in /etc/inittab are recognized and properly ignored. Consistency would sure be nice.


Great!

I've never seen a grub entry that did that but I don't think there's a reason why it couldn't. I'm thinking of adding a new entry to have an easily accessible means of booting to single user to run a disk repair without too much else running on the system.

I guess I've always done something akin to your second example. I only have one system that I normally boot into level 5 anyway and that second process is similar to the method of I've use when doing maintenance activities like new drivers, patches, etc..

Glad your system's back to normal.

Cheers,

Rick

I did that and also looked up the GRUB-manual but I couldn't find an entry how to pass the runlevel to the kernel. Could you please point me in the right direction and give a link or two? Thanks...

It's not in the grub manual, but it's a kernel parameter description.
If you need pass run-level you just specify the number you want, that's it.

Thanks I'll try that. Is it described in the kernel documentation then?

I think so

Here's what I wrote in response to post #6, some of it is answered by the 3 posts since:

From section 4.2.2 GNU/Linux of the GRUB manual:
http://www.gnu.org/software/grub/man...#GNU_002fLinux

(Underlining added & note reference to the Linux source tree.)

From the init man page:
In other words, add the run level you want to the end of a "kernel ..." line in GRUB's menu.lst.

The above is the part you pretty much knew.

How to "prove" this -- show explicit documentation -- is another matter.

1. Let's start w/ a Google search:
   http://www.google.com/linux?q=grub+calls+init+-initrd
2. Check out the 1st hit:
   The Arch boot process - ArchWiki
   especially "1 Before init" & the links in that section . . .
3. Inside the linux boot process & Figure 1. in the Overview "The 20,000-foot view of the Linux boot process".
4. The Wikipedia article Linux startup process may have answers, but I found it too long & technical for me.
5. Warning: Boot with GRUB repeated crashed Konqueror 3.5.8, so while I was researching this I had to open it in Opera; & besides it didn't say much new.

Anyone want to go digging in the Linux source tree & give us some links???

I'd never have guessed to look there, thanks.

That was my hope, that somebody had already done it. Thanks for your summary, too.

@Valery Reznic I tried it, worked like a charm. Thanks for sharing this information.

Feel free to use that almost brand new thanks button.


Kernel Parameters
It must be my week for kernel parameters -- this box did not fully survive Thursday's storms here in Texas & the Houston area. Apparently, something killed the on-board USB & now it won't boot, even w/ a MEPIS 8 live CD, w/o disabling USB. The kernel parameter for that is "nousb". Now I can boot it from the installed MEPIS 8 or w/ the live CD.

In the process of tracking down the strange boot-time error msgs., I stumbled over "fromiso" on the MEPIS Wikia, as well as "How to use no CD at all" -- Boot from ISO -- 2 things I had heard about, never book marked.