[SOLVED] Do NOT use kernel-3.5.0-4.fc17 until fixed

[dcharlespyle]

kernel-3.5.0-4.fc17 totally bjorked my system on install. This kernel reports itself as kernel-3.5.1-4.fc17 on uname -a and leaves in the wake of its installation two initramfs files, one named as initramfs-3.5.0-4.fc17 and the other as initramfs-3.5.1-4.fc17.

It is listed in grub2 menu.cfg as 3.5.0-4 but tries to load non-existent modules from 3.5.1-4, which leaves network useless as well as videocard, filesystems, and other drivers. It is a miracle that I was even able to boot into that kernel at all and see anything. I ended up with a stretched screen as well.

Just a warning to those who would try the koji build like I did. I am about to remove this kernel until it is fixed.

You have been warned. :-)

[DBelton]

After I read your message, I had to try that kernel (I know, I'm crazy )

I had the same results you had.

No mouse, video stretched, and same results.. It reports as kernel-3.5.1-4.fc17.

I hope they don't try to push that one to the repos.

Edit:

I only got one initramfs created on my system.

/boot/initramfs-3.5.0-4.fc17.x86_64.img

[stoat]

Originally Posted by DBelton

After I read your message, I had to try that kernel (I know, I'm crazy )

Ray: "Don't look directly into the trap!"
Egon: "I looked at the trap, Ray!"

Works for me after giving it a proper version and rebuilding.

$ uname -r
3.5.1-0.rc1.4.fc17.x86_64

$ rpm -qa kernel\* |sort
kernel-3.5.0-2.fc17.x86_64
kernel-3.5.1-0.rc1.4.fc17.x86_64
kernel-devel-3.5.0-2.fc17.x86_64
kernel-devel-3.5.1-0.rc1.4.fc17.x86_64
kernel-headers-3.5.1-0.rc1.4.fc17.x86_64

[dcharlespyle]

DBelton,

I ended up reinstalling it and renamed the files and directories to match the kernel. It works really well after doing that. The system seems a little zippier after installing that kernel, too.

Yellowman,

Did you rebuild the kernel or the packages? I would rather go that route than renaming files and directories when the package still has the incorrect version and could cause problems later on.

Originally Posted by dcharlespyle

DBelton,

I ended up reinstalling it and renamed the files and directories to match the kernel. It works really well after doing that. The system seems a little zippier after installing that kernel, too.

Yellowman,

Did you rebuild the kernel or the packages? I would rather go that route than renaming files and directories when the package still has the incorrect version and could cause problems later on.

I edited the spec file

$ diff -up kernel.spec kernel.spec.leigh123linux 
--- kernel.spec	2012-08-09 12:00:41.029986107 +0100
+++ kernel.spec.leigh123linux	2012-08-09 06:20:43.000000000 +0100
@@ -66,9 +66,9 @@ Summary: The Linux kernel
 %if 0%{?released_kernel}
 
 # Do we have a -stable update to apply?
-%define stable_update 0
+%define stable_update 1
 # Is it a -stable RC?
-%define stable_rc 0
+%define stable_rc 1
 # Set rpm version accordingly
 %if 0%{?stable_update}
 %define stablerev %{stable_update}
@@ -601,7 +601,7 @@ Source2001: cpupower.config
 Patch00: %{stable_patch_00}
 %endif
 %if 0%{?stable_rc}
-%define    stable_patch_01  patch-3.%{base_sublevel}.%{stable_update}-rc%{stable_rc}.bz2
+%define    stable_patch_01  patch-3.%{base_sublevel}.%{stable_update}-rc%{stable_rc}.gz
 Patch01: %{stable_patch_01}
 %endif
 
@@ -769,8 +769,7 @@ Patch22070: net-Allow-driver-to-limit-nu
 Patch22071: sfc-Fix-maximum-number-of-TSO-segments-and-minimum-TX-queue-size.patch
 Patch22072: tcp-Apply-device-TSO-segment-limit-earlier.patch
 
-# 3.5 stable patches
-Patch23000: patch-3.5.1-rc1.gz
+
 
 # END OF PATCH DEFINITIONS
 
@@ -1476,7 +1475,7 @@ ApplyPatch CPU-hotplug-cpusets-suspend-D
 #rhbz 820039 843554
 ApplyPatch rds-set-correct-msg_namelen.patch
 
-ApplyPatch patch-3.5.1-rc1.gz
+#ApplyPatch patch-3.5.1-rc1.gz
 
 #rhbz 845558 844714
 ApplyPatch net-Allow-driver-to-limit-number-of-GSO-segments-per-skb.patch

Then rebuilt it

[dcharlespyle]

As misfortune would have it, I seem to have forgotten (brain injury from CO poisoning a few years ago, I'm afraid) how to rebuild a kernel properly. Instructions I have seen around the internet are outdated. Can you point me somewhere on how to do this the current, right way? Much appreciated.

Originally Posted by dcharlespyle

As misfortune would have it, I seem to have forgotten (brain injury from CO poisoning a few years ago, I'm afraid) how to rebuild a kernel properly. Instructions I have seen around the internet are outdated. Can you point me somewhere on how to do this the current, right way? Much appreciated.

Try this.

su
yum groupinstall "Development Tools"
yum install rpmdevtools wget
exit
rpmdev-setuptree
cd ~/rpmbuild/SRPMS
wget http://kojipkgs.fedoraproject.org//packages/kernel/3.5.0/4.fc17/src/kernel-3.5.0-4.fc17.src.rpm
su -c "yum-builddep -y kernel-3.5.0-4.fc17.src.rpm"
rpm -i ~/rpmbuild/SRPMS/kernel-3.5.0-4.fc17.src.rpm
cd ~/rpmbuild/SPECS
wget https://dl.dropbox.com/u/6907158/spec.patch
patch -p0 < spec.patch
rpmbuild -ba --without=debug --without=debuginfo kernel.spec

wait 1/2 - 1 hour to compile, then install.

[dcharlespyle]

Many thanks, Yellowman. Just what I needed. At first, I kept getting errors about "Development Tools" not having any packages. So, I just skipped that part and did the rest.

I saw lots of warnings about this or that variable or otherwise as the code was processed while it was compiling, but everything seems to be working.

As an aside, I have been informed that kernel-3.5.1-final will be built and made available soon.

[marko]

kernel 3.5.1-1 is out, it just installed on my machine here

[dcharlespyle]

Did a fresh install of Fedora 17 again. Tried to install rawhide thinking I was getting Fedora 18 and got 19 instead. I ended up not being able to get past a loop involving dracut, so here I am at 17 again. But kernel 3.5.1-1 is working fine so far.