Compiling 2.6 kernel questions

Compiling 2.6 kernel questions

[Alex]

Hi,

I'm trying to compile 2.6.32-pre8 and have some questions that I hoped
someone could help me to answer. They aren't really specific to the
kernel version, other than I'm using 2.6.

- Is it possible to compile a kernel with glibc-2.10.1 and run it on a
system with a much older glibc version? Specifically, I'd like to
upgrade a v2.4 kernel system to v2.6 with only the minimal amount of
changes in order for it to run.

- Is it necessary to compile the IDE driver and ext2/3 filesystem
driver into the kernel, or can that also be a module? 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?

If this can be done, where can I find info on the steps?

- Is there a general list of minimum requirements for compiling a
recent 2.6 kernel? IOW,  module-init-tools, gcc, etc.

- Does anyone use lilo anymore, or do all distros use grub?

Thanks so much.
Best regards,
Alex

Re: Compiling 2.6 kernel questions

[Glynn Clements]

Alex wrote:

> I'm trying to compile 2.6.32-pre8 and have some questions that I hoped
> someone could help me to answer. They aren't really specific to the
> kernel version, other than I'm using 2.6.
> 
> - Is it possible to compile a kernel with glibc-2.10.1 and run it on a
> system with a much older glibc version? Specifically, I'd like to
> upgrade a v2.4 kernel system to v2.6 with only the minimal amount of
> changes in order for it to run.

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.

> - 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. 

> 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. 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.

> - Is there a general list of minimum requirements for compiling a
> recent 2.6 kernel? IOW,  module-init-tools, gcc, etc.

The file Documentation/Changes in the kernel source tree lists minimum
versions.

> - Does anyone use lilo anymore, or do all distros use grub?

Gentoo offers a choice of boot loaders; I use lilo.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: Compiling 2.6 kernel questions

[Alex]

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

Re: Compiling 2.6 kernel questions

[Glynn Clements]

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>

Re: Compiling 2.6 kernel questions

[Alex]

Hi,

>> 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.

So if I get a VFS error along the lines of "VFS: Can't mount root
unknown-block(9,1)" and it panics, what could the cause be?

I realize this is /dev/md1, and I've built the initrd with md-mod and
sata_nv, and ext3 is built in, but it's almost like it's ignoring the
linuxrc in the initrd. If I chroot to it and run /bin/nash /linuxrc,
it does print my echo statements.

How can I debug this or capture the full output to analyze?

Thanks again,
Alex

Re: Compiling 2.6 kernel questions

[Glynn Clements]

Alex wrote:

> >> 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.
> 
> So if I get a VFS error along the lines of "VFS: Can't mount root
> unknown-block(9,1)" and it panics, what could the cause be?
> 
> I realize this is /dev/md1, and I've built the initrd with md-mod and
> sata_nv, and ext3 is built in, but it's almost like it's ignoring the
> linuxrc in the initrd. If I chroot to it and run /bin/nash /linuxrc,
> it does print my echo statements.

"VFS: Can't mount root" suggests that it's failing to mount the initrd
filesystem. For initrd, the root filesystem passed to the kernel from
the bootloader (via root=) should be /dev/ram0. You also have to tell
the bootloader where to find the filesystem image (e.g. via initrd=
for lilo).

> How can I debug this or capture the full output to analyze?

I don't think that there's much to capture; it appears to be failing
at the first hurdle (mounting initrd).

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: Compiling 2.6 kernel questions

[Alex]

Hi,

> "VFS: Can't mount root" suggests that it's failing to mount the initrd
> filesystem. For initrd, the root filesystem passed to the kernel from
> the bootloader (via root=) should be /dev/ram0. You also have to tell
> the bootloader where to find the filesystem image (e.g. via initrd=
> for lilo).

Yes, and I'm pointing lilo to the initrd, and can mount and read the
initrd on its own.

You don't mean root=/dev/ram0 instead of root=/dev/md1, right?

This is why I was asking about lilo some time ago. I'm using the
latest, but that's from 2007. Is it possible that it has a problem
with this kernel?

This box does work with an older 2.6.12 kernel that I built more than
a year ago with the otherwise same system, including lilo.

Thanks,
Alex

Re: Compiling 2.6 kernel questions

[Glynn Clements]

Alex wrote:

> > "VFS: Can't mount root" suggests that it's failing to mount the initrd
> > filesystem. For initrd, the root filesystem passed to the kernel from
> > the bootloader (via root=) should be /dev/ram0. You also have to tell
> > the bootloader where to find the filesystem image (e.g. via initrd=
> > for lilo).
> 
> Yes, and I'm pointing lilo to the initrd, and can mount and read the
> initrd on its own.
> 
> You don't mean root=/dev/ram0 instead of root=/dev/md1, right?

Yes. This seems to be the standard initrd mechanism for newer kernels.

The error message:

	VFS: Can't mount root unknown-block(9,1)

indicates that the kernel is trying to mount /dev/md1 directly (device
9:1 is /dev/md1), which won't work if the md driver is a module (even
if the md driver is built in, this won't work if the array needs
user-space configuration before it can be mounted).

> This is why I was asking about lilo some time ago. I'm using the
> latest, but that's from 2007. Is it possible that it has a problem
> with this kernel?

I haven't had any problems using lilo with recent kernels, although I
don't normally use initrd.

You should look at Documentation/initrd.txt for details on the current
state of initrd. Or Documentation/filesystems/ramfs-rootfs-initramfs.txt
for the newer initramfs mechanism.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: Compiling 2.6 kernel questions

[Alex]

Hi,

> The error message:
>
>        VFS: Can't mount root unknown-block(9,1)
>
> indicates that the kernel is trying to mount /dev/md1 directly (device
> 9:1 is /dev/md1), which won't work if the md driver is a module (even
> if the md driver is built in, this won't work if the array needs
> user-space configuration before it can be mounted).

I remember using lilo in the past to boot from RAID partitions, no?
Isn't that why lilo writes the bootsector of both disks in a mirror?

> You should look at Documentation/initrd.txt for details on the current
> state of initrd. Or Documentation/filesystems/ramfs-rootfs-initramfs.txt
> for the newer initramfs mechanism.

It feels like it's very old. There's still references to LOADLIN in there.

After doing some research, it appears people are moving to
syslinux/extlinux/isolinux as replacement for lilo and grub, so I'm
investigating that approach now.

Thanks again,
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Compiling 2.6 kernel questions

[Glynn Clements]

Alex wrote:

> > The error message:
> >
> >        VFS: Can't mount root unknown-block(9,1)
> >
> > indicates that the kernel is trying to mount /dev/md1 directly (device
> > 9:1 is /dev/md1), which won't work if the md driver is a module (even
> > if the md driver is built in, this won't work if the array needs
> > user-space configuration before it can be mounted).
> 
> I remember using lilo in the past to boot from RAID partitions, no?
> Isn't that why lilo writes the bootsector of both disks in a mirror?

You can do it, but without initrd, it requires that the kernel can
auto-configure the RAID array, and that the md driver is built-in.

-- 
Glynn Clements <glynn@gclements.plus.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html