Kernel compile the old way
Ed
directions at the Debian site. They seem to me to be needlessly
complicated. Is there something in Debian which would prevent me from
compiling a kernel the good old fashioned way --
make menuconfig
make && make modules_install
cp bzImage and System.map to /boot
edit the grub menu
-- and skip the initrd whatever? And, if so, where does Debian load the
modules from, so I can edit that too? It's not /etc/modules - only a
few there.
Any advice appreciated. Thanks.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Hugo Vanwoerkom
> I went to compile a vanilla kernel from kernel.org, and so read the
> directions at the Debian site. They seem to me to be needlessly
> complicated. Is there something in Debian which would prevent me from
> compiling a kernel the good old fashioned way --
>
> make menuconfig
> make && make modules_install
> cp bzImage and System.map to /boot
> edit the grub menu
>
> -- and skip the initrd whatever? And, if so, where does Debian load the
> modules from, so I can edit that too? It's not /etc/modules - only a
> few there.
>
> Any advice appreciated. Thanks.
>
>
make menuconfig
make-kpkg --revision 1 kernel_image
Does all of that and you need not do more but:
dpkg -i <the deb file created>
boot with the newly installed kernel
Amit Joshi
> I went to compile a vanilla kernel from kernel.org, and so read the
> directions at the Debian site. They seem to me to be needlessly
> complicated. Is there something in Debian which would prevent me from
> compiling a kernel the good old fashioned way --
>
> make menuconfig
> make && make modules_install
> cp bzImage and System.map to /boot
> edit the grub menu
>
> -- and skip the initrd whatever? And, if so, where does Debian load the
> modules from, so I can edit that too? It's not /etc/modules - only a
> few there.
>
> Any advice appreciated. Thanks.
AFAIK modprobe can load modules only if they are compiled that way in the
kernel. [M] indicates that the particular driver is compiled in as a module.
The debian patched kernels are pretty good. I won't use a Vanilla source
unless there's any specific need to do that.
Also, I am not sure..but SID might be having the latest stable kernel in its
repositories.
The simplest way to install a debian-patched kernel is:
root@computer#apt-get install kernel-image-<version>
This procedure simply installs the kernel, without having to run the make
menuconfig thing et al. Moreover it also updates the /boot/grub/menu.lst file
automatically. Truly advantageous you see.. :)
--
Remember fellas, what we do in life echoes in eternity!
Mike Kuhar
I went to compile a vanilla kernel from kernel.org, and so read the
directions at the Debian site. They seem to me to be needlessly
complicated. Is there something in Debian which would prevent me from
compiling a kernel the good old fashioned way --
make menuconfig
make && make modules_install
cp bzImage and System.map to /boot
edit the grub menu
-- and skip the initrd whatever? And, if so, where does Debian load the
modules from, so I can edit that too? It's not /etc/modules - only a
few there.
Any advice appreciated. Thanks.
I'm currently in the unstable tree and I build my own kernels all the time.
I have not found any compelling reason to get the plain vanilla kernel
source, nor going the "make-kpkg --revision 1 kernel_image" route. Once I
had a working .conf file I reuse that for every kernel rebuild. I use the
linux-source-{version} from debian for my rebuilds. And I don't have to
name my kernels, of mess with grub, once it's set up.
The steps are:
make menuconfig
make bzImage
make modules
make modules_install
and the one step that everyone leaves out, which handles grub:
make install
In point of fact, that last step does nothing specifically with grub. What
it does do is change the symbolic links. That is, it changes /boot/vmlinuz
to link to the latest built kernel, and /boot/vmlinuz.old to the previously
built kernel. Grub always points to /boot/vmlinuz and /boot/vmlinuz.old.
The downside of this is that your previous build always becomes vnlinuz.old,
even if it's the same version. The upside is that all previously built
kernels remain in /boot untill you remove them.
My problem, is that I can never remember which version I'm using. What I
mean is, I can't remenber if linux-sourse-2.6.18-4 or 2.6.18-5 is my working
kernel. The .config file has a variable under '# General setup' called
CONFIG_LOCALVERSION which I set to the version I'm currently building. In
my current case, it's set as:
CONFIG_LOCALVERSION="-5"
So when I do a uname -a, I see the the Linux version as 2.6.18-5, instead of
2.6.18. It comes in handy.
When you build a particular kernel source for the first time, you don't have
to run 'make clean'. This is only needed if you have to rebuild the
specific kernel a second or third time.
You can always see the versions available by simply doing:
apt-get install linux-source
If you're currently using linux-source-2.6.16, don't do an "apt-get remove
linux-source-2.6.16" until you have had a successful build on
linux-source-2.6.18.
Good luck. -mike
Marc Wilson
> make menuconfig
> make-kpkg --revision 1 kernel_image
Don't you end up with an initrd that way? I admit to never wasting my time
with kernel-package, but I thought you couldn't avoid one if you insisted
on using it.
--
Marc Wilson | IF I HAD A MINE SHAFT, I don't think I would just
m...@cox.net | abandon it. There's got to be a better way. --
| Jack Handley, The New Mexican, 1988.
Wackojacko
> On Fri, Nov 10, 2006 at 02:10:53PM -0600, Hugo Vanwoerkom wrote:
>> make menuconfig
>> make-kpkg --revision 1 kernel_image
>
> Don't you end up with an initrd that way? I admit to never wasting my time
> with kernel-package, but I thought you couldn't avoid one if you insisted
> on using it.
>
HTH
Wackojacko
Amit Joshi
> Marc Wilson wrote:
> > On Fri, Nov 10, 2006 at 02:10:53PM -0600, Hugo Vanwoerkom wrote:
> >> make menuconfig
> >> make-kpkg --revision 1 kernel_image
> >
> > Don't you end up with an initrd that way? I admit to never wasting my
> > time with kernel-package, but I thought you couldn't avoid one if you
> > insisted on using it.
>
> No if you want an initrd you have to specify it to make-kpkg.
>
> HTH
>
> Wackojacko
What exactly are the advantages of using an initrd?
Oh I know it is Initial RAM Disk..but does it speed up the boot process or
something?? Just curious...
--
Remember fellas, what we do in life echoes in eternity!
John Hasler
> What exactly are the advantages of using an initrd?
For a distribution kernel it provides support for all possible permutations
and combinations of hardware. I don't know of any advantages for a custom
kernel.
--
John Hasler
Amit Joshi
> Amit Joshi writes:
> > What exactly are the advantages of using an initrd?
>
> For a distribution kernel it provides support for all possible permutations
> and combinations of hardware. I don't know of any advantages for a custom
> kernel.
> --
> John Hasler
Oh..thanks for the information. Now I know why custom built kernels don't have
initrd images. :)
Regards,
Amit.
--
Remember fellas, what we do in life echoes in eternity!
Hugo Vanwoerkom
> On Saturday 11 November 2006 22:00, John Hasler wrote:
>> Amit Joshi writes:
>>> What exactly are the advantages of using an initrd?
>> For a distribution kernel it provides support for all possible permutations
>> and combinations of hardware. I don't know of any advantages for a custom
>> kernel.
>> --
>> John Hasler
>
> Oh..thanks for the information. Now I know why custom built kernels don't have
> initrd images. :)
>
Not exactly. I use a custom kernel and the suspend2 patch. That enables
you to suspend/resume and show the progress of that process with a userui.
But if you want to see the progress on *resume* you have to use an
initrd that loads the userui *before* the kernel gets control.
Sad to say it doesn't work. Tried it with yaird.
Problem: yaird uses Perl to put the initrd together but not too much in
the way of info as to what actually happens.
Hugo
Bernard Adrian
> For a distribution kernel it provides support for all possible permutations
> and combinations of hardware. I don't know of any advantages for a custom
> kernel.
Huh,
I'm compiling a custom kernel (2.6.1) with initrd for my system (AMD K6-II 64
Mo RAM). I get an initrd.img of 2.4 Mo. Ext3 and so are not in modules.
Should i understand my system would work better if i install the same
kernel without initrd ?
Thanks
--
Bernard Adrian
http://www.bernadrian.net
John Hasler
> Should i understand my system would work better if i install the same
> kernel without initrd ?
Initrd is an extra bit of complexity at bootup but it makes no difference
once the system is up. Don't worry about it.
--
John Hasler
Bernard Adrian
[...]
> I'm compiling a custom kernel (2.6.1) with initrd for my system (AMD K6-II 64
Oups : i wanted to say kernel 2.6.17 and no 2.6.1....
Bernard Adrian
> Initrd is an extra bit of complexity at bootup but it makes no difference
> once the system is up. Don't worry about it.
Ok. Thanks !
--
Bernard Adrian
http://www.bernadrian.net
Manoj Srivastava
> Amit Joshi writes:
>> What exactly are the advantages of using an initrd?
> For a distribution kernel it provides support for all possible
> permutations and combinations of hardware. I don't know of any
> advantages for a custom kernel.
Well, I have a fully encrypted laptop hard drive, apart from a
42MB /boot (including encrypted swap). Now way to do that without
using an initrd image.
manoj
--
A fool and his honey are soon parted.
Manoj Srivastava <sriv...@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
John Hasler
> For a distribution kernel it provides support for all possible
> permutations and combinations of hardware. I don't know of any
> advantages for a custom kernel.
Manoj Srivastava writes:
> Well, I have a fully encrypted laptop hard drive, apart from a 42MB /boot
> (including encrypted swap). Now way to do that without using an initrd
> image.
Obviously, there are special situations. I've seen it claimed that
everyone should always use initrd, but without explanation.
--
John Hasler
Ismael Valladolid Torres
> Should i understand my system would work better if i install the same
> kernel without initrd ?
The more customized your kernel to your system, the better. But often
improvements don't compensate the amount of work it requires to end up
with a kernel fully optimized to your system.
I usually use Debian kernel's config as my .config when compiling a
new kernel. And Debian's config more or less expect you to be using
initrd. That's why I usually use initrd when compiling a custom kernel
although probably it would be better not to use it. For me, it's a
balance between amount of work needed and real improvement.
My two euro cents. :)
Cordially, Ismael
--
Ismael Valladolid Torres "Il est vain de pleurer sur l'esprit, il suffit
de travailler pour lui." Albert Camus
http://digitrazos.info/
http://lamediahostia.blogspot.com/ OpenPGP key ID: 0xDE721AF4
http://www.hispasonic.com/foro73.html Jabber ID: ival...@jabberes.org
Bernard Adrian
[...]
> The more customized your kernel to your system, the better. But often
> improvements don't compensate the amount of work it requires to end up
> with a kernel fully optimized to your system.
>
> I usually use Debian kernel's config as my .config when compiling a
> new kernel. And Debian's config more or less expect you to be using
> initrd. That's why I usually use initrd when compiling a custom kernel
> although probably it would be better not to use it. For me, it's a
> balance between amount of work needed and real improvement.
>
> My two euro cents. :)
Thanks - merci for your advice !
--
Bernard Adrian