Re: compiling (or rather, failing to compile) a kernel
On Sat, 10 Nov 2012 17:45:20 -0500 (EST)
Stephen Powell <zlinuxman@wowway.com> wrote:
> On Sat, 10 Nov 2012 13:46:09 -0500 (EST), Martin Steigerwald wrote:
> > On Sat, 10 Nov 2012 Lisi Reisz wrote:
> >> I have been trying to get to grips with compiling a custom
> >> kernel. I have been shying away for too long.
> >>
> >> I am following Stephen's marvellous work, and had got this far:
> >>
> >> http://users.wowway.com/~zlinuxman/Kernel.htm#Unpack
> >
> > This appears to be really old.
>
> The above document was last revised on August 4, 2012. I wouldn't
> classify that as "really old". Perhaps you assumed that it is old
> because I recommend using kernel-package, rather than "make deb-pkg"
> or some other newer method. kernel-package has been around a while,
> yes. But I recommend it for what I consider to be good reasons,
> which are explained over time in the document. You are, of course,
> entitled to disagree with my opinion. But it's not old. I make an
> effort to keep it up to date, and suggestions are welcome.
I don't have time to read the current howto now, but I'll read it ASAP.
It describes the way I build Debian and Ubuntu kernels since years, but
while my scripts are a little bit outdated, Stephen updated his howto.
However, even my outdated scripts still do work. I used a script
version from Wheezy to build a kernel for my current Ubuntu ...
$ uname -v #1 SMP PREEMPT RT Fri Nov 2 21:36:37 CET 2012 ... so 9 days
ago this old style to build a kernel still worked.
It works for Debian and Ubuntu since years. I added "--rootcmd
fakeroot", but run the script as root ;) and for sure my script does
install packages that aren't needed to build a kernel. But all in all
nothing important changed in the last years.
However, from time to time there were some issues that could be fixed
by reading the error messages and since custom build kernels usually
aren't build to fit all needs, we even could abandon some things, if
compiling those would cause trouble.
I remember one issue that occurred very often,
in /lib/modules/KERNEL_VERSION the /build and /source links were
missing or bad.
At least for Ubuntu this still is an issue, right now I noticed
"build -> /usr/src/linux-3.6.5-rt14" but correct would be linked
against "linux-headers-3.6.5-rt14".
IIRC this was an issue for my latest Debian installs too.
+1 for old school. I'm pro progress, but IMO it isn't alway progress to
use new methods, to do old things. Most of the times new methods tend to
fail, e.g. systemd [1] makes many *nix users to switch from Linux to
another *nix. Basic workflow only should change, if it's really
useful. We aren't building kernels very often, so we should be able to
relay on a method that always can be used, without reading tons of fine
manuals. I'm cleaning my tableware, but I don't change the old dishes
with new once, new tableware might look nicer, but it don't add any
new features, it only needs resources to get new tableware and it's
risky, since it might no be as dishwasher-proof as the tableware I
already own.
I hope we won't lose manifoldness for Linux :(.
Regards,
Ralf
PS:
Another example:
http://www.debian.org/doc/manuals/apt-howto/ch-helpers.en.html
I can't see anything that's obsolete.
[1] Arch Linux did ban peole from the users mailing list that argued
against systemd and meanwhile upstream makes systemd a dependency for
even DEs. I'm writing to this list and get replies off-list, because
some people aren't allowed to write to this list anymore.
Reply to: