Hi all,
I have slackware13 on my pc and I downloaded kernel 2.6.37 and was trying to install it.
Untarred the kernel. Took the .config file from the slackware code. Executed 'make' - all good. Then I ran 'make modules_install and install'.
I then copied the bzImage from the arch folder and put it in the /boot. Copied the System.map file and put that too in the boot. Then I executed 'mkinitrd' (just to be safe). Made changes to lilo.conf and ran 'lilo'. All good this far.
However when I reboot the orignal as well as the 2.6.37 are not able to find the root partition!
I have done this earlier with debian lenny and it worked fine. Am I missing something here?
Any suggestions or pointers would be welcome.
Thanks for reading.

Yes -- The details how you did all these.

maybe the section "Libata switchover" of 13.1's CHANGES_AND_HINTS.TXT it's pertinent for the switch to the new kernel.

and you should do also a "make oldconfig" after copying the old .config file in the new sources.

@guanz - what details do you need. Is the post that difficult to understand? Tell me what part you found difficult and I would explain. Please understand that with your posts like this you are taking the post out of the zero replies which get more preference.
@ponce - wow, I kind of am worried now . The thing that bothers me is .config from slackware 13 (kernel 2.6.29) /usr/src/linux works good on my hardware but would have a hard time working with kernel 2.6.37?
Am I understanding it wrong? Do you know of any tricks/work arounds that would help me take care of this. I am so persistant about the 2.6.37 because it contains (supposedly) some code to make the desktop faster and it is also supposed to be supported for long term.
One more thing bothering me is that not only the new kernel not able to find the rootfs even the one that is installed by default is not able to find the rootfs. Very confused as to how this can happen. Very odd.
Thanks for the response.

the problem is with 2.6.29 sees hard drives as hda
2.6.37 sees hard drives as sda

so, if your lilo or grub says "root=/dev/hda2", 2.6.37 is not gonna find it cause it's looking for /dev/sda5

try changing fstab and lilo.conf to sda, not hda

1 members found this post helpful.

Greetz
It seems to me that in forums one of the traps people can fall into is assuming the expertise (even in only one area let alone generally) of someone seeking help. Also it is common that when we relate the steps we think are essential we will make the same set of assumptions in reporting as we did that caused us to overlook some detail which merely clones that mistake in any respondents.

In this case one example might be "I executed mkinitrd just to be safe" where it is impossible to determine from only that if a proper initrd was created. What did you do as preparation and what indication do you have that the required early modules were all included?

At this point if the drive naming convention, hda vs/ sda, does not solve the problem, frankly I would rebuild the kernel (since "make oldconfig" was overlooked anyway, possibly missing important changes) and check the early modules off for direct kernel support instead of as loadable modules. It's just simpler and more direct and eliminates complexity at a very low level. Then at least you would have a comparison if not a working kernel.

It is difficult to find a balance between too short and too long in seeking "necessary and sufficient" especially online but long does have the option for people to dismiss what they will. Filling in holes is fraught with error.

2 members found this post helpful.

Hi, what do you mean by "supposedly" and "supposed to be"? Do you have some references or did you just suppose yourself that 2.6.37 would make the desktop faster or that it would be a longterm support kernel?

Perhaps he's thinking of the SCHED_AUTOGROUP patch. It didn't actually make it into .37 though.

To the best of my knowledge 2.6.35 is the latest of the long-term support kernels, which is why I'm glad Pat decided to stick with it for current (13.2 or whatever it'll be called)

Exactly.

I didn't want to offend the OP but I really couldn't figure out where the error should be in the numerous possibilities.

BTW, I think the OP *is* an expert to some degree (from his/her manner). So I just asked for details and thought he/she knew what details were necessary. (In this case posting a mkinitrd command line should not be more time consuming than writing "I executed mkinitrd just to be safe". It's also nice to see the last kernel output on boot failure, untranslated to everyday language but kept original.) I apologize if I am wrong.
.

I don't know if I understood well your question, but when you want to use an old .config file for a previous kernel version with a new one, you should do a "make oldconfig" to have it try to fix the .config file asking you some questions.
but consider that using an old .config gets more unsafe for every kernel version jumped (from 2.6.29 to 2.6.37 many things are changed): on 64-current this is the generic kernel config (for version 2.6.35.10).

as others told you, 2.6.35.10 is the latest long term release.
if you're speaking of the autogroup patch is in 2.6.38-rcX, but let me say that, personally, I prefeer out-of-tree patches, like Con kolivas stuff or zen kernels for the best desktop experience.

try running /usr/share/mkinitrd/mkinitrd_command_generator.sh after having built the kernel and copied it on boot, it should help you finding the correct parameters to create the initrd with support for your root filesystem.

Well, I am no expert... but then this kernel works perfectly well with debian and I am stumped why it does not work on slackware.
Anyway, I think I learned a lot here. The easiest thing seems to be to change /etc/mtab (I am more comfortable doing that). The question now is how do I figure out how the kernel is naming the hard drive? When it tries to boot up it does see the partitions 'as they were named' so I am a bit confused about this. Will 'make oldconfig' resolve this issue?
Another thing that bothers me is the kernel writes over the existing grub entries (so that I can boot up to the default kernel). Is this normal?
Well, as far as long term support is concerned I looked it up on google. I do not have the url right now. As far as the desktop speed is concerned I have seen a lot of new entries for mulimedia and other stuff (I think including X) and I bet if Linus wrote this it has to be good IMHO.
Well as far as the kernel installation is concerned I am doing it straight out of the README. Not a lot of info is available on the net about this.
Anything else you think I got to watch out for or simple suggestions would be welcome.
Thank you all for doing some research for me and helping me out here.

I am running from 2.6.37 as I write this. As others have said after copying the .config file you MUST run "make oldconfig" and answer the questions to get a reasonably functional kernel. You should also check that your file system is included in the build as this can cause a similar error. "make install" will overwrite your default slackware kernel, not really the best plan. After "make modules_install" it is better to copy the new kernel image to /boot then add the new image to lilo. This will always leave you with the previous functional kernel to fall back on. The autogroup patch, as several others have already mentioned, will be in 2.6.38 and it will not be enabled by default. You will have to go in and turn it on, either as it comes up in the "make oldconfig" prompt or in your preferred kernel editing tool.

2.6.37 works fine here in current, picked it from out-of-tree zen kernels, which should have performance patch applied. I used slackwares 2.6.35.10 kernel-config as starting point.

Well, gotten somewhere now. I am able to boot using the default kernel. However with 2.6.37 I still am stuck at not able to find the root file system. For the default kernel the root is at '/dev/hdc2'.
The strange thing here is when the kernel 2.6.37 boots up it tells me that it is not able to mount the root and the partition it shows me is hdc1 (swap) and hdc2 (/). As someone mentioned that the naming in the kernel 2.6.37 is different can someone give me hints to understand what is the partition that the kernel sees as the root if not hdc2?
Thanks a lot for helping me out here.

Above in the thread there's a link to a document that talks about the libata change. It bit me, too.

Basically, hd? changes to sd?. So, you have to change lilo to boot into the new kernel. Read the document. ;v)