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@xxxxxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-admin" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
