Defective version of fedora boots
 

I responded to a suggestion that I install security updates - did so and ended up with a copy of fedora that goes into a loop.

I suspect the prob is the driver to my video adapter.

To run, I need to interrupt grub with an escape.
It then shows me two choices
the bad one
2.6.32.12-115.fc12.i686
and the old good one
2.6.31.5.- 127.fc12.i686
It defaults to the bad one, I change it to the good one and tell it ot proceed.
this is inconvenient

I see that in /boot/grub/grub.conf the 2 systems are described

I beleive that if I merely edit that file, taking out the refernece to the bad one, I will be ok

That will leave the bad one on the disk but at least I wont have to go thru the ritual of interrupting grub.

Is there any reason I should not do this?

If I want to delete the bad one - after I've taken care of the grub.conf file, what do I do?

Thanks in advance
Dick

Ostrich tactics are no good. Instead boot the "bad one" into runlevel 1 and look at 'dmesg', /var/log/messages and /var/log/Xorg.0.log to see if there's clues. Also please try to be factual and complete when presenting information: "I suspect the prob is the driver to my video adapter" doesn't ring a bell (and my ESP isn't that good) but saying you run proprietary drivers for card X of Brand Y via DKMS might ring a bell for some.

Unspawn

I previously submitted a very complete description of the problem and my configuration.

If it is approariate to do so here agin, I will pull the material together again and do so.

I do not have proprietary anything.

Just add the link here.


Sure? No Nvidia drivers?

Symptom
When the bad copy boots, I get a pattern on the screen similar to a TV test pattern, and the system is in a loop - with one of my l e d s continuously flashing

Configuration
1.25 ghz AMD athlon
NVIDIA RIVA TNT display adapter
ECS K7S5a board / chipset
AMD BIOS 07.00T
512 mb main mem
128 kb primary cache
256 2ndary cache
66 mhz bus clock

History
When this happened I cam here and described the problem and asked how to report the problem. Somone here directed me to another location that takes bug reports.

ADD ONS
I have added nothing to the system - it is exactly as delivered.

Apparently we are talking at the same time.

I have not added an NVIDIA driver - something supplied with the system is talking to my NVIDIA card. The driver in the good version is compatible with it. The driver in the bad version is not. I did not supply either of these drivers.

Maybe from the version numbers I supplied you can tell what driver I got the first time and what driver I got the second time. I suspect you will find they are not the same.

For what it is worth - the good version apparently talks to the card in a simple protocol that does not try to take advantage of its features. I get low resolution, big character, al la video cards of old. Windows talks to the same card in a more spphisticated p[rotocal giving me very high resolution.

You asked for a link to the bug report.

I dont have any idea how to find a link to the bug report that I posted a few months ago. Someome here directed me to a bug reporting site. Maybe you can track my prior messages and see where someone sent me. That is where I went.

I would try to do that but I dont understand the mechanics of this forum well enough to do so.

In any case, I've repeated the information in a post I sent a miute or so ago.

Unspawn
I'm an old hacker but a total novice at UNIX - did one unix job abt 20 years ago and remember almost nothing

you suggest I boot into level something of the bad version

how do I do that?

Imagine I've interrupted grub and am looking at its menu

how do I get to where you suggest

if I merely let grub launch the bad one I end up in a loop

Dick

If I understand your problem, you did an update and got a kernel update and booting the new kernel "doesn't work". If the old kernel works, use it. Was there something imperative for you to get a new kernel? You can simply put hash marks (#) to the left of the entry for the new kernel so it is not on the menu (grub.conf). Maybe I'm not understanding your problem?

1. for the moment, after you have got into the system ok, you can set the 'default' value in /boot/grub/grub.conf to point to the kernel you want booted. Entries are numbered from zero, so the first 'title' entry in grub.conf is 'default=0', next 'title' entry would be 'default=1' and so on.

2. you could use yum remove <kernel> to completely remove the entry in a controlled manner.
Try

yum list installed | grep kernel

to get the correct name https://access.redhat.com/kb/docs/DOC-2531

Yancek - I started by saying that I intended to do what you said - except that I intended to delete the lines from the grub control file - same difference. I merely asked whether there would be any unintended consequence in doing this. Apparently not.

Unspawn suggested that this was putting my head in the sand and that I should help determine the cause. To me the cause is clear - somewhere between the first and second version the authors made a change in the terminal handler which results in this bug.

Chris.. I tried your command and it says that the good copy of the kernnel came from rawhide and the bad came from update.

I have no need for a better copy of the kernel - I work at gedit and at the command line developing software. The kernel announces that it crashes regularly, but the handlers restore it and it makes no neverminds to me.

Thanks to all of you for your attention and help.

Dick