Ok, I've tried searching for this but could not find any relavant info on my problem.

The weird thing is, after I compile the kernel I dowloaded on kernel.org, with frame buffer support and do all the described steps including editing lilo.conf and running lilo and then trying to boot the newly compiled kernel the screen does not just go black, but it freezes with boot output in pale grey colour and then, parts of the sceen turn white slowly.

The huge kernel that comes with 14.1 booted fine without any issues.

I've compiled the kernel with everything bult in and I'm not using inird.

I have no idea what could be causing the problem - I've tried re-compling the kernel time and time again with various graphics drivers built in and always included Radeon support as the laptop has mobility radeon HD 3450/3470.

I'm stuck - please help!

Hmmm...

Have a look here.
http://alien.slackbook.org/dokuwiki/...kernelbuilding

I usually use one of the two configs (huge and (generic using alien bob's build)) from /boot, build, and then trim it down. Still working on localmodconfig. Has been a pain, if you don't load huge kernel first (lesson learned).

Good luck.

I don't see any good reason to have a specific frame buffer driver built in, VESA VGA is enough IMHO and anyway the frame buffer module for your graphic card will be loaded soon enough.

Can you at least boot with the huge kernel?

If yes, do this and please tell us what you are customizing and why.

Anyhow, not knowing what you changed exactly in kernel's configuration and what is your hardware (output of lspci -vn could help), we are too much in the dark to actually help you efficiently.

PS Compiling your kernel with everything built in is not a good idea IMHO as some of your devices can then be claimed by a driver which is not the best for your hardware and if that happens you won't be able to blacklist it. Why do that anyway?

Thanks r.vaillancourt and Didier Spaier

Yes, the huge kernel boots

Will try VESA VGA only, without the Radeon frame buffer driver.

Will get the pspci -vn output on here. With regards to compiling everything into the kernel - I do not have device drivers built in for the hardware which I do not have, at least for things like graphics, sound, network and stuff.

I'm just trying to build a kernel with the drivers and options relevant only to my system, without clutter

Unless recommended by the help text associated to that option, there is no gain in making a driver for a specific device built-in, even if you have it. Just have them as modules.

OK, just be aware that doing so you won't get any increase in performance and very few in terms of space on hard disk.

If you persist doing that, I suggest you take the generic config file as a basis then run "make oldconfig" followed" by "make localmodconfig". Be aware that then:

• Only the already loaded kernel modules will be included in the configuration. So, before running that command, plug-in any kind of removable devices you want to be able to use in the future. If you miss USB slots to do that (which is probable), just unplug a device to plug in another one, all relevant kernel modules will stay loaded.
• Of course you will need an initrd.

1 members found this post helpful.

I agree with most of the above, however for kit that I own/know I prefer not to use modules at all - personal preference.
This, on the other hand, deserves comment: just because you choose to have module loading, doesn't necessarily imply an initrd. If there is sufficient support present in the kernel for the root to be mounted, there is no overt reason to use an initrd.

Of course you can choose to have everything built-in, but then you have to make sure not to include "alien" drivers that could cause conflicts, possibly running "make localyesconfig". Could you share your rationale for that personal preference?

In case of Slackware and making a kernel based on -generic configuration, drivers for most file systems are not built in, so mounting / will fail during boot sequence if the module is not included in an initrd.

Habit from gentoo days - before the advent of options such as localyesconfig, sorting out which options to use was very much a manual process. I tended to go with only what I needed.

Never seen a reason to change - and that applies to custom kernels for Slack, although I haven't done that for a while.

The only actual drivers you want built-in are the file system loading ones and maybe an SCSI/SATA/IDE controller driver. The rest can be modules controlled by udev's module autoloader.

I can find only tutorials for compilation of 2.6.x kernels.
Is it fine to use those same tutorials for the 3.x series?

Ummmm top line.... well 2nd line

If you didn't see that page, HERE is the link

1 members found this post helpful.

@ReaperX7 - I dislike everything about an initrd and consider it useless and unnecessary complexity for my purposes. I don't encrypt root and I don't use RAID (on SOHO boxes)so on those I will hold out as long as possible and build the 2 or 3 drivers needed to avoid it into the kernel.

I rarely use hugesmp.s for longer than a day and always "roll my own" very soon after install and again if I see that some of my hardware has improved support in a newer kernel. Knowing enough about my hardware to not create conflicts is both the price I pay and a worthy investment, with tangential returns.