SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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 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.
Last edited by r.vaillancourt; 01-16-2014 at 01:33 PM.
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?
Last edited by Didier Spaier; 01-16-2014 at 02:02 PM.
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
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.
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.
Quote:
I'm just trying to build a kernel with the drivers and options relevant only to my system, without clutter
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.
Last edited by Didier Spaier; 01-16-2014 at 05:17 PM.
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:
Quote:
Originally Posted by Didier Spaier
[*]Of course you will need an initrd.
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.
for kit that I own/know I prefer not to use modules at all - personal preference.
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?
Quote:
Originally Posted by syg00
... 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.
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.
Could you share your rationale for that personal preference?
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.
@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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.