[Gllug] Debugging kernel loading initrd

[Nix]

On 27 Apr 2008, John Edwards outgrape:

> On Sun, Apr 27, 2008 at 03:15:16PM +0100, Nix wrote:
>> Ah, you're keepig one initramfs and rebuilding it as needed? I found
>> myself getting into tangles with out-of-date modules when I did that, so
>> now I'm assembling it at build time via the kernel's build machinery
>> (that strange usr/ subdirectory of the kernel's source tree is not empty
>> for me).
>
> Not really. I'm just modifying the userspace of an initramfs that
> works on i686. Kernel modules are not being touched.

Almost certainly a CPU

>>> ------------------------------------------------------------
>>> $ sudo chroot ipcop-initrd/ /init
>>> Illegal instruction
>>> ------------------------------------------------------------
>>>
>>> This matches some other tests I ran where rdinit=/bin/hello-world
>>> would work, but rdinit=/bin/sh would fail.
>>>
>>> So the problem is almost certainly in busybox rather than anything
>>> to do with the kernel or the structure of the initramfs.
>> 
>> Suspect your uClibc as well and/or your toolchain. Built for i686,
>> maybe?
>
> It appears to be something to do with the C libraries. A whole bunch
> of binaries that were built from the same C libraries also fail in the
> chroot. Even simple binaries from Debian fail.

See my other mail. Also, er, if you're statically linking against
*glibc*, that doesn't work properly (with a different failure from
this). (Recent versions of busybox diagnose this and halt the
compilation in that circumstance.)

-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug