检查lfs从内核到到第一个进程init是否成功
当系统从bootloader传递参数到linux的start_kernel
一般内核里面不会出什么BUG。主要是上层构建的rootfs有没有问题。
即使内核里面出了问题，也会在串口提示。也可以通过打log来跟踪 一步步到哪里出问题了。
使用printk 打印内核日志。可以很快定位到哪里出了问题。
一般最后内核会运行到
kernel_init
尝试运行init进程
if (!try_to_run_init_process("/sbin/init") )
if ( !try_to_run_init_process("/etc/init"))
if ( !try_to_run_init_process("/bin/init"))
if ( !try_to_run_init_process("/bin/sh"))
这四个里面有一个运行成功就算运行到init进程了。只要有一个成功就会立马返回。
如果这个进程完成。后续的过程也可以从init进程里面打日志printf来调试了。
关键就是这个init进程能否起来。一般不能起来主要是缺少某些依赖库。特别是lib下面的
我们可以一步步跟踪过去。返回0表示 成功。其他的值一般是错误
这一条路径上可以多打日志
try_to_run_init_process->run_init_process->do_execve->do_execveat_common->(prepare_binprm exec_binprm)
这个exec_binprm最容易返回错误 导致最后执行try_run的值返回-2没有找到模块
exec_binprm->search_binary_handler
search_binary_handler会根据读取的binary的头部判断是不是可执行的bin格式。
然后调用相应的函数执行
static struct linux_binfmt elf_format = {
.module = THIS_MODULE,
.load_binary = load_elf_binary,
.load_shlib = load_elf_library,
.core_dump = elf_core_dump,
.min_coredump = ELF_EXEC_PAGESIZE,
};
list_for_each_entry(fmt, &formats, lh) 枚举当前的处理bin文件的handler然后调用他们的
retval = fmt->load_binary(bprm);的方法。
load_binary方法主要是 load_elf_binary和load_elf_library
主要是load_elf_binary加载的过程容易出错也就是说
try_to_run_init_process("/sbin/init）
最后用load_elf_binary来加载执行这个进程
load_elf_binary中间解析了init头部
确认binary需要加载哪些库然后尝试加载这些库
这中间需要调用 open_exec来打开这些库
open_exec->do_open_execat->do_filp_open->path_openat-> do_last做最后一步打开的工作->lookup_open
do_last里面如何确认是哪个文件miss?
{
printk("CRITICAL BEGIN \n\n")
打印当前准备打开的文件名 在第一个参数
struct nameidata *nd,
struct nameidata {
struct path path;
struct qstr last;
struct path root;
struct inode *inode; /* path.dentry.d_inode */
unsigned int flags;
unsigned seq, m_seq;
int last_type;
unsigned depth;
struct file *base;
char *saved_names[MAX_NESTED_LINKS + 1];
};
struct qstr {
union {
struct {
HASH_LEN_DECLARE;
};
u64 hash_len;
};
const unsigned char *name;
};
nd->last->name这里是文件名字 打印出来（这里是不带路径的。只有文件名，也可以直接去lookup_dcache函数里面打印 这里会打出全路径）
lookup_open
printk("CRITICAL END \n\n")
在return之前打印返回值 如果return 地方不好找，可以直接在do_last之后打印
return xxxxxx
}
如果 do_last返回值不是0表示这个文件由错误。一般是不存在。我们在这里面又打印了文件名字，可以一下就定位到是哪个文件出了问题。
关键是看do_last打开文件的时候是否返回了0，0表示成功。非0表失败。把这个文件打印出来就知道哪里的问题了。
我的init起不来表现为
Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
CPU: 0 PID: 1 Comm: swapper Not tainted 4.1.19 #2
Hardware name: ARM-Versatile PB
[<c001ac70>] (unwind_backtrace) from [<c00177c4>] (show_stack+0x10/0x14)
[<c00177c4>] (show_stack) from [<c0375e34>] (panic+0x7c/0x1d8)
[<c0375e34>] (panic) from [<c0375584>] (kernel_init+0xa8/0x148)
[<c0375584>] (kernel_init) from [<c00145e8>] (ret_from_fork+0x14/0x2c)
---[ end Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
根据这个方法成功定位到
lookup_dcache=lib/ld-linux.so.3
openat ERROR 3350=00000000
CRITICAL BEGIN
lookup_dcache=ld-linux.so.3
dentry flag 0
do_last FLAGS 3083=00000080
CRITICAL END
do_last ERROR NEGATIVE 3141=fffffffe
返回了-2.是ld-linux.so.3丢失了。