From: Glynn Clements <glynn@gclements.plus.com>
To: Alex <mysqlstudent@gmail.com>
Cc: linux-admin@vger.kernel.org
Subject: Re: Compiling 2.6 kernel questions
Date: Wed, 25 Nov 2009 09:02:48 +0000 [thread overview]
Message-ID: <19212.62136.877446.609535@cerise.gclements.plus.com> (raw)
In-Reply-To: <55e03a0a0911242100t71a7dd3fxa8ccb3c7be2a3749@mail.gmail.com>
Alex wrote:
> > The version of glibc installed on the build system has no effect upon
> > the resulting kernel.
> >
> > glibc tends to be quite independent of the kernel version. For the
> > most part, you can still run binaries linked against libc.so.5 on a
> > 2.6 kernel.
>
> That's also what I thought, however, I got a kernel panic booting the
> kernel I built, and my inclination was that it was caused by glibc-2.3
> being installed on the system. It said something along the lines of
> this:
>
> init[1] segfault at ffffe32c ip b7800319 sp bf931cb0 error 4 in
> ld-2.3.2.so[b77fe000+15000]
>
> Should I look elsewhere for the cause of this, or is it possible that
> it's related to an old glibc?
It could be glibc; there are a few features which can require a newer
libc (from memory, address randomisation is one). Or it could be that
some critical feature was missing from the kernel. If this is booting
via initrd, try without it first.
FWIW, glibc-2.3.2 isn't inherently incompatible with 2.6, although
it's possible that a specific build might be incompatible with some
aspect of it.
> >> - Is it necessary to compile the IDE driver and ext2/3 filesystem
> >> driver into the kernel, or can that also be a module?
> >
> > If you build either as a module, you need to use initrd or initramfs.
>
> So it can be made available as a module within an initrd?
The IDE driver can be loaded from initrd, as can ext2 so long as
initrd itself isn't an ext2 filesystem.
> >> If so, and I put
> >> it in initrd,. how is it accessed? Isn't it a catch-22 without having
> >> support to access the very ramdisk that has the support that's
> >> necessary to access it?
> >
> > To use initrd, the device driver and file system have to be built into
> > the kernel.
>
> Hmm... Are you saying here that it can't be loaded as a module, but
> instead must be compiled into the kernel?
Whichever filesystem initrd itself uses has to be built-in (otherwise
you get the chicken-and-egg problem), but this can be e.g. cramfs; it
doesn't need to be writable, or support ownership, permissions, links,
etc.
--
Glynn Clements <glynn@gclements.plus.com>
next prev parent reply other threads:[~2009-11-25 9:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-24 23:18 Compiling 2.6 kernel questions Alex
2009-11-25 4:07 ` Glynn Clements
2009-11-25 5:00 ` Alex
2009-11-25 9:02 ` Glynn Clements [this message]
2009-11-25 18:24 ` Alex
2009-11-25 22:51 ` Glynn Clements
2009-11-25 23:32 ` Alex
2009-11-26 4:35 ` Glynn Clements
2009-11-27 1:18 ` Alex
2009-11-28 0:27 ` Glynn Clements
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19212.62136.877446.609535@cerise.gclements.plus.com \
--to=glynn@gclements.plus.com \
--cc=linux-admin@vger.kernel.org \
--cc=mysqlstudent@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).