[Gllug] Debugging kernel loading initrd

Nix nix at esperi.org.uk
Sat Apr 26 21:07:29 UTC 2008


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

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.

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

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

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




More information about the GLLUG mailing list