[Gllug] Debugging kernel loading initrd

John Edwards john at cornerstonelinux.co.uk
Sun Apr 27 13:03:42 UTC 2008


On Sat, Apr 26, 2008 at 10:07:29PM +0100, Nix wrote:
> On 26 Apr 2008, John Edwards told this:
>> Which is why I wondered if there was any way to get the kernel to
>> debug what it's doing with the initrd/initramfs.
> 
> There isn't really enough going on to debug. All the kernel does
> after mounting (an elaborate and annoying process with initrd,
> trivial with initramfs) is the in-kernel equivalent of
> execl ("/init", "/init", NULL);
> 
> (see linux/init/main.c:init_post().
> 
>                 run_init_process(ramdisk_execute_command);
> 
> is the line that arranges to run /init.)

Thanks, very useful.


> I test this sort of thing by loopback-mounting it and making sure that
> 
> chroot /mnt/initrd /init
> 
> works. If it doesn't, there's not a chance it'll work when the kernel
> boots, either.

Thanks again. Running in a chroot looks to be an easier way of
debugging the initramfs than booting a kernel. The initramfs is
actually a gzip'ed cpio archive, so instead of mounting it can be
unpacked using:
  gzcat <file> | cpio -idmu

This had been tested to work on newer machines, but now fails
with Pentium CPUs:
------------------------------------------------------------
$ 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.

Thanks again to those that replied, and I think I now have some work
to do on how busybox has been configured and compiled.



>> just suggest running a simple "hello world" program to see if it
>> works in an emulator (eg QEMU or UML). Are there any emulators that
>> can be a bug-perfect copy of a Pentium I CPU?
> 
> I doubt it. QEMU might be your best bet, but nothing aims for
> bug-for-bug CPU emulation outside of ICEs internal to Intel, and perhaps
> not even there.

Thought so. Means I'm stuck with testing on a stack of ancient Pentiums.


>> If there isn't a standard way of debuging this sort of thing then
>> there are two options I can think of:
>>
>> 1) Write a bunch of C programs that rely on different sets of
>> libraries and then see which is them work.
>>
>> 2) Add debugging messages to the kernel code that loads the initrd.
> 
> The latter is the best bet. It's easy to get the kernel to spit out
> debugging messages. ;}

That's a joke right?


-- 
#---------------------------------------------------------#
|    John Edwards   Email: john at cornerstonelinux.co.uk    |
#---------------------------------------------------------#
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: Digital signature
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20080427/b6876bdf/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug


More information about the GLLUG mailing list