Hullo All,
I have just updated my kernel and immediately struck trouble. The kernel update is marked as security update.
When booting I get a multiple warnings " deprecated config file /etc/modprobe...", then "no root device found" followed by "boot has failed, sleeping forever"!
Clearly something is amiss with this update, so figured the best thing might be to remove it and wait on a fix, but attempting to remove the kernel via the package manager would cause a whole lot of other packages to be removed as well.
Instead, I edited grub.conf, commenting out all the kernel-2.6.34.7-63 lines, so that the default is now the previous kernel (2.6.34.7-61).

Is there a better way of handling this?

Cheers,
Terry

It seems that the initramfs is screwed up, I would reinstall

If that does not work, you could try to regenerate it with
# dracut -f <image name> <kernel name>

Hullo Andrew,

Thanks for trying to help.
I have tried both your suggestions, and neither make any difference at all.

Cheers,
Terry

Fedora 14 x86_64
After kernel updates last night my system also could not boot up to the graphical screen. I reinstalled the nvidia driver manually and that took care of the problem.

north49er the OP's issue is not with the nvidia driver
and if you are NOT going to use the rpm from fedora then you are also going the NEED to reinstall mesa ( the nvidia.run overwrites some fedora system files -- and is NOT recommended)



terry-duell

boot into the old kernel
Fedora auto saves the last 3
they are listen on the boot menu , use the "down arrow" to select the last one .

or edit the grub.conf like you did .

this is why there are 2 back up kernels installed

John VV I got it finally. Fedora way or no way.

Hullo John,

OK, Thanks.
I guess I just leave things as they are, and continue to boot off the previous kernel. Hopefully there will be a fix for this soon which incorporates the security fix that kernel-2.6.34.7-63 was to provide, although I haven't seen anything in the bug lists, so maybe it is a problem local to my system.

Cheers,
Terry

terry-duell, was this a 100% clean new install or was it a "upgrade" from 12

if upgrade then did you use "preupgrade " or just "yum upgrade"

an upgrade might give these types of errors .

Hullo John,

This was a clean install to a new disc, many moons ago, which was the F13 release...I guess that was about 7 months ago.
It has been running well since 'new', and undergone all upgrades since without issue, until the 2.6.34.7-63 kernel two days ago.

Cheers,
Terry

Correction...the above should read "...and undergone all updates since...".

sorry if I caused any confusion.

Cheers,
Terry

Hullo again,
The problem persist with the latest kernel, 2.6.34.7-66.
Installing this latest kernel removed one of the previous working kernels, so I now have only one kernel that will boot OK (2.6.34.7-61) which doesn't have the latest security updates.
I have reported it as a bug, but it doesn't appear to get any attention.
I would really appreciate some advice from anyone who knows about this.
The system is an AMD 965, running Fedora 13 x86_64, a SATA system disc (/dev/sda, partitioned automagically by F13 during installation to a new disc), a SATA data disc (/dev/sdb), and an IDE data disc (/dev/sdc).
The system has been faultless since initial install (at the time of F13 release) and ever since, until the update kernel 2.6.34.7-63. It has always been kept up to date.
It does seem to me that something has changed in the kernel as of 2.6.34.7-63 and has been perpetuated into 2.6.34.7-66, but must be something a tad obscure else there would be problems for all and sundry who run x86_64 systems...and that doesn't appear to be the case.
There have been reports of this problem related to live discs, but none that I have found (other than my own problem) for hard disc installed systems.

Unless there is a fix, I may well be in dire straits with no bootable system after another kernel update.

Gurus, help please!

Cheers,
Terry

Had similar problem last night after kernel update to Fedora 14 x86_x64. System booted as far as loading the nvidia drivers then froze. Wound up re-installing. Only this time after I installed the nvidia drivers, rhythmbox decided it wasn't going to work. No error messages. I think perhaps the latest kernel may have a bug in it somewhere.

brpy1

brpy1
your problem seams to be a bit different than the OP's
you might want to start a new thread and include in it a few things

what nvidia driver are you using ?
the kmod-nvidia.rpm ?
the Akmod-nvidia ? ( the akmod IS DIFFERENT from the kmod )
the nvidia.run ?
OR
the open nouveau driver ?
and did you fallow the install guide ?
http://forums.fedoraforum.org/showthread.php?t=204752

and if you DID use the nvidia.run from the nvidia web site DID you reinstall ALL of mesa including it's source ( -devel.rpm's )
That is A MUST if you use the .run installer.

John VV

Hi & thanks for the response - I appear to be using the kmod-nvidia rpm, installed with this command "yum install kmod-nvidia xorg-x11-drv-nvidia-libs.i686" - the free and non free repositories having been installed earlier (following Randell's Blog), and using this page "http://www.unixmen.com/linux-tutorials/linux-distributions/fedora/1376-how-to-install-nvidia-drivers-in-fedora-13-and-14" as a reference. I now believe I should have been using the Akmod-nvidia set, as apparently this compiles the nvidia driver for the computer upon boot up. I'm not using the nvidia-run setup, and the nouveau drivers are blacklisted.

All of which leads me to a few more questions -

(1) how do I get rid of the kmod drivers and install the Akmod drivers?

and

(2) will installing these drivers fix rhythmbox (I do not expect it will) or will I have to un-install and re-install?

As far as 'mesa' goes, I'm sorry, but I don't know what that is, and given the above, I probably didn't have to use it anyway.

I would have followed your suggestion and started another thread, but I'll have to find out about that process later.

Regards

brpy1
*********************
Ignorance is not bliss.

Solved.
My /etc/fstab looked suspicious, with two swap entries, thus...

/dev/mapper/vg_phenom-lv_swap swap swap defaults 0 0
/dev/mapper/vg_phenom00-lv_swap swap swap defaults 0 0

which led me to snoop elsewhere as well. I found that vg_phenom-lv_swap doesn't exist, and that led me to check my /boot/grub/grub.conf, which (lo and behold) referred to the non existent swap. Modifying the grub.conf to refer to correctly refer to the swap has fixed the problem.
Of course this then raises the questions as to how, with a clean install, did the grub.conf and fstab entries end up the way they were?
Hope this helps some other poor soul.

Cheers,
Terry