On 10/03/2014 02:05 PM, Kevin Martin wrote:
On 10/03/2014 01:12 PM, jd1008 wrote:
On 10/03/2014 12:45 AM, Ed Greshko wrote:
On 10/03/14 10:18, jd1008 wrote:
On 10/02/2014 07:16 PM, Ed Greshko wrote:
At this point, if I were you, I'd create a bootable LIVE USB or a LIVE CD from the F20 release and boot it and see if it works.
Definitely worth a try.
Yes, and then you can compare the logs....
If you did keep the "rescue" grub entry you could boot into that and try your "experiments" with loading modules. You'll probably
have to extract and replace the /usr/lib/modules/whatever-kernel directory from the initramfs as that was probably removed (or
cleaned out) when the kernel related to the "rescue" boot was removed.
Of course, this would assume that when the system was first installed you hadn't installed the rpmfusion packages until at least
the next kernel update. Otherwise, the initramfs would contain rpmfusion bits.
It turns out that when I had installed the rpmfusion nvidia packages, the initramfs
of 3.14.0-200 was saved as /boot/initramfs-3.14.9-200.fc20.x86_64-nouveau.img
So, I committed a desperate act of
mv initramfs-3.16.3-200.fc20.x86_64.img initramfs-3.16.3-200.fc20.x86_64.img.not
cp -f initramfs-3.14.9-200.fc20.x86_64-nouveau.img initramfs-3.16.3-200.fc20.x86_64.img
and rebooted.
And my resolution is now correct.
Question:
Will this "working" initramfs prevail when a new kernel is installed via updates?
So can we assume that what he has done here is to take a working initramfs with the nouveau module loaded (albeit a 3.14 kernel) and
runs it at bootup time and the system can also find
/usr/lib/modules/3.14.0-200.fc20.x86_64/kernel/drivers/gpu/drm/nouveau/nouveau.ko and that is why nouveau is working again? Are we
sure that the 3.16.3-200 initramfs (original) was, in fact for the 3.16.3 kernel or could it be that that initramfs was also screwed
up (much like the 3.14.0 / 3.14.9 debacle) and *that's why when he was trying to insmod
/usr/lib/modules/3.116.3-200.fc20.x86_64/kernel/drivers/gpu/drm/nouveau/nouveau.ko it couldn't load the module? If one initramfs
got screwed up whose to say they *all aren't screwed up? And if that's the case then there is no way that Fedora would be able to
automagically figure out loading of modules, etc.
Kevin
Hey Kevin,
I think the installation of the non-free driver when I was still running
3.14.9.200,
saved the initramfs of that kernel as
initramfs-3.14.9-200.fc20.x86_64-nouveau.img
So, with several updates afterwards, 3.14.9.200 kernel was removed by yum.
But the initramfs file which was saved by installing the invidia kmod
was not
removed because it was not part of the package of kernel-3.14.9..... (since
it was saved with a different name).
But your question is indeed valid, as I do not know how it is that I
take the initramfs
of an older kernel, copy it to the initramfs of current kernel and that
fixed the
resolution problem.
So, I webt back and booted into 3.16.3.200 and ran dracut -f
and rebooted.
And the problem is fixed, and the initramfs is genuinely that of kernel
3.16.3-200
Did the same for kernel 3.16.2-20[01] .
So, all is well and problem resolved.
Actually, I want to tell nvidia and the packager of the non-free
nvidia drivers, that they screwed up, not only as far as not restoring
the initramfs when the package is removed, but while the non-free
driver was installed, I could no longer boot up from hibernation. The
system would crash with pagefaults and die.
Now that I have fully gotten rid of the nvidia junk, rebooting from
hibernation is presenting no problems at all.
Thanx!!
JD
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
