Hi, > 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? >> - 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? >> 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? > 2.6 kernels support initramfs, which doesn't require a > separate device driver or filesystem module (the code is always built > into the kernel). See Documentation/filesystems/ramfs-rootfs-initramfs.txt > for details. > >> If this can be done, where can I find info on the steps? > > Unless you're particularly short for space, start by building a kernel > with IDE and ext2 built in, and deal with initrd/initramfs later. Not short on space, but would like to build a kernel package that can be installed on multiple systems with different hardware configurations. I'd like to make it as modular and portable as possible. The only thing I can be assured of is that it will always use ext3. Thanks again. You've helped me quite a bit over the years, and I sure appreciate it. Best regards, Alex -- 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
