[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