I am about to try recompiling a kernel so as not to have framebuffer support,
which is the default in the stock 7.2 kernel (CONFIG_FB=y).
Because I've taken out the top-level framebuffer support my .config file now
has all those sundry framebuffer types that were previously built as modules
removed also.
The issue is that when I do a modules_install, won't those modules still be
lying around in /lib/modules?
Is this anything to be concerned about? I know it's a bad thing to compile in
something that was once a module to the kernel and leave the module lying
around underneath /lib/modules/XXX.
--
Tim Harrell
On Monday 10 December 2001 23.10, Tim Harrell wrote:
The issue is that when I do a modules_install, won't those modules still be lying around in /lib/modules?
The flag EXTRAVERSION in the top level Makefile was set to -4GB in suses compilation. In my makefile it's clean, but you can set it to, say, -tim. That way, the modules will land in /lib/modules/2.4.x-tim, and they won't collide with the original modules. That way you can also keep the old kernel + modules, so you have a known working kernel to fall back on, in case the compile is a failure. regards Anders
On Monday 10 December 2001 23.16, Anders Johansson wrote:
On Monday 10 December 2001 23.10, Tim Harrell wrote:
The issue is that when I do a modules_install, won't those modules still be lying around in /lib/modules?
The flag EXTRAVERSION in the top level Makefile was set to -4GB in suses compilation.
Slight modification after I actually checked things: the makefile adds -4GB if support for 4 gig of memory is compiled in. So if you set EXTRAVERSION to -tim, the name of the kernel will be <version>-tim-4GB. But still, this would be the way to do it. //Anders
On Monday 10 Dec 2001 10:16 pm, Anders Johansson wrote:
On Monday 10 December 2001 23.10, Tim Harrell wrote:
The issue is that when I do a modules_install, won't those modules still be lying around in /lib/modules?
The flag EXTRAVERSION in the top level Makefile was set to -4GB in suses compilation. In my makefile it's clean, but you can set it to, say, -tim. That way, the modules will land in /lib/modules/2.4.x-tim, and they won't collide with the original modules. That way you can also keep the old kernel + modules, so you have a known working kernel to fall back on, in case the compile is a failure.
regards Anders
Thanks Anders, that's exactly what I was looking for.
I knew all about keeping the old kernel accessible in lilo to fall back on
but I was wondering how one could possibly unpick it if the modules had been
seriously screwed up.
The makefile I have has -4GB as HIGHMEMVERSION in the building of the kernel
release string so I'd get something like
2.4.7-tim-4GB
Regards,
--
Tim Harrell
On Monday 10 December 2001 23.10, Tim Harrell wrote:
I am about to try recompiling a kernel so as not to have framebuffer support, which is the default in the stock 7.2 kernel (CONFIG_FB=y).
Incidentally, Lenz pointed out that if you have problems with the framebuffer, and the framebuffer is compiled as a module, you don't have to recompile the kernel. Just boot with vga=normal in lilo.conf. //Anders
On Monday 10 Dec 2001 10:25 pm, Anders Johansson wrote:
On Monday 10 December 2001 23.10, Tim Harrell wrote:
I am about to try recompiling a kernel so as not to have framebuffer support, which is the default in the stock 7.2 kernel (CONFIG_FB=y).
Incidentally, Lenz pointed out that if you have problems with the framebuffer, and the framebuffer is compiled as a module, you don't have to recompile the kernel. Just boot with vga=normal in lilo.conf.
//Anders
I have 'vga=normal' in lilo.conf as an append parameter to the kernelbut I'm
not sure about the status of the frame buffer. Do I need the 'vga=normal'
directive on a line by itself in lilo.conf as well as an append parameter to
the kernel?
If I do a make xconfig and go into Frame buffer support, the first item is
whether to have frame buffer support itself (and is marked as experimental)
and this is set to 'y' (ie compiled in).
Most of the particular types of framebuffers beneath this are marked as
modules though, and if I select no to the top-level one then all the others
disappear and nothing is either compiled in or loaded as a module.
This is what I was thinking of doing, since I'm using the nvidia drivers and
not any vesa stuff, I'm assuming there won't be any problem removing the
frame buffer support entirely.
--
Tim Harrell
On Tuesday 11 December 2001 00.43, Tim Harrell wrote:
I have 'vga=normal' in lilo.conf as an append parameter to the kernelbut I'm not sure about the status of the frame buffer. Do I need the 'vga=normal' directive on a line by itself in lilo.conf as well as an append parameter to the kernel?
I think it's the same whether you have it on a line by itself or as a kernel append. Do you get the default penguin boot image in the upper left corner, or the suse splash boot? If neither, then you don't have frame buffer support active, and the problems you're experiencing are most likely not framebuffer related.
If I do a make xconfig and go into Frame buffer support, the first item is whether to have frame buffer support itself (and is marked as experimental) and this is set to 'y' (ie compiled in). Most of the particular types of framebuffers beneath this are marked as modules though, and if I select no to the top-level one then all the others disappear and nothing is either compiled in or loaded as a module.
This is what I was thinking of doing, since I'm using the nvidia drivers and not any vesa stuff, I'm assuming there won't be any problem removing the frame buffer support entirely.
No, you just won't have the fancy graphics on tty1. Nothing else should be affected. //Anders
On Monday 10 Dec 2001 11:49 pm, Anders Johansson wrote:
On Tuesday 11 December 2001 00.43, Tim Harrell wrote:
I have 'vga=normal' in lilo.conf as an append parameter to the kernelbut I'm not sure about the status of the frame buffer. Do I need the 'vga=normal' directive on a line by itself in lilo.conf as well as an append parameter to the kernel?
I think it's the same whether you have it on a line by itself or as a kernel append. Do you get the default penguin boot image in the upper left corner, or the suse splash boot? If neither, then you don't have frame buffer support active, and the problems you're experiencing are most likely not framebuffer related.
//Anders
I get a penguin image and a graphical green and white background when the
choice of which kernel to boot is presented.
As soon as I select a kernel to boot however it goes into 80x25 character
mode for the bootup.
So does that mean the framebuffer is active?
--
Tim Harrell
On Tuesday 11 December 2001 01.01, Tim Harrell wrote:
I get a penguin image and a graphical green and white background when the choice of which kernel to boot is presented. As soon as I select a kernel to boot however it goes into 80x25 character mode for the bootup.
So does that mean the framebuffer is active?
No, it means it's inactive. The kernel selection screen is lilo. I think it uses vesa framebuffers, but I'm not sure. But this is before linux and its modules load. If you had been using framebuffers in linux you'd have either the penguin in the upper left corner, or the suse splash while the boot messages scrolled by. //Anders
Tim Harrell writes:
I am about to try recompiling a kernel so as not to have framebuffer support, which is the default in the stock 7.2 kernel (CONFIG_FB=y). Because I've taken out the top-level framebuffer support my .config file now has all those sundry framebuffer types that were previously built as modules removed also.
The issue is that when I do a modules_install, won't those modules still be lying around in /lib/modules?
Is this anything to be concerned about? I know it's a bad thing to compile in something that was once a module to the kernel and leave the module lying around underneath /lib/modules/XXX.
I think modules_install will remove the older entries before installing, but just in case you could remove them yourself. This is the line from the Makefile. It looks like it is removing everything in $(MODLIB)/kernel which is where the modules will be stored. _modinst_: @rm -rf $(MODLIB)/kernel @rm -f $(MODLIB)/build @mkdir -p $(MODLIB)/kernel
On Monday 10 Dec 2001 10:30 pm, Jesse Marlin wrote:
Tim Harrell writes:
I am about to try recompiling a kernel so as not to have framebuffer support, which is the default in the stock 7.2 kernel (CONFIG_FB=y). Because I've taken out the top-level framebuffer support my .config file now has all those sundry framebuffer types that were previously built as modules removed also.
The issue is that when I do a modules_install, won't those modules still be lying around in /lib/modules?
Is this anything to be concerned about? I know it's a bad thing to compile in something that was once a module to the kernel and leave the module lying around underneath /lib/modules/XXX.
I think modules_install will remove the older entries before installing, but just in case you could remove them yourself.
This is the line from the Makefile. It looks like it is removing everything in $(MODLIB)/kernel which is where the modules will be stored.
_modinst_: @rm -rf $(MODLIB)/kernel @rm -f $(MODLIB)/build @mkdir -p $(MODLIB)/kernel
Thanks,
I like the idea of being able to keep a separate version of the modules as
Anders described, for any significant changes. However, I wouldn't do it to
excess, if I was just changing the odd module here and there it would be a
bit overkill to have separate modules trees each time.
--
Tim Harrell
participants (3)
-
Anders Johansson -
Jesse Marlin -
Tim Harrell