Linux操作系统分析lab3:基于VS Code的Linux内核调试环境搭建及start_kernel跟踪分析

实验步骤

1、下载Linux内核源代码

sudo apt install axel
axel -n 20 https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/linux-5.4.34.tar.xz
xz -d linux-5.4.34.tar.xz
tar -xvf linux-5.4.34.tar
cd linux-5.4.34

2、下载编译工具

sudo apt install build-essential gcc-multilib
sudo apt install qemu 
sudo apt install libncurses5-dev bison flex libssl-dev libelf-dev

3、配置内核选项

make defconfig
make menuconfig
# 打开debug相关选项
Kernel hacking --->
    Compile-time checks and compiler options --->
        [*] Compile the kernel with debug info
        [*] Provide GDB scripts for kernel debugging
[*] Kernel debugging
# 关闭KASLR,否则会导致打断点失败
Processor type and features ---->
    [] Randomize the address of the kernel image (KASLR)

4、编译和运行内核

make -j$(nproc)
# 测试内核能否正常运行,因为没有文件系统最终会kernel panic
qemu-system-x86_64 -kernel arch/x86/boot/bzImage

5、制作根文件系统

mkdir rootfs
cd rootfs
cp ../busybox-1.31.1/_install/* ./ -rf
mkdir dev proc sys home
sudo cp -a /dev/{null,console,tty,tty1,tty2,tty3,tty4} dev/

6、init脚本文件

cd rootfs
vim init
mount -t proc none /proc
mount -t sysfs none /sys
echo "Welcome!"
echo "--------"
cd home
/bin/sh

7、内存根文件系统镜像打包

# 给init文件加权限
chmod +x init
# 打包
find . -print0 | cpio --null -ov --format=newc|gzip -9 > ../rootfs.cpio.gz
#测试挂载根文件系统
qemu-system-x86_64 -kernel linux-5.4.34/arch/x86/boot/bzImage -initrd rootfs.cpio.gz

8.配置vscode

1、在命令行输入python ./scripts/gen_compile_commands.py
2、新建.vscode文件夹,将提供的配置文件放入文件夹内

9.跟踪分析

qemu-system-x86_64 -kernel ./arch/x86/boot/bzImage -initrd rootfs.cpio.gz -S -s

设置断点start_kernel,在vscode中按F5进行调试
在这里插入图片描述
在start_kernel的结尾arch_call_reset_init(),点开函数定义,发现执行了reset_init()函数,再设置一个函数断点"reset_init",继续点击单点跳过进入reset_init函数内部,由0号进程执行。在这里插入图片描述
继续执行,遇到1号进程kernel_init,,它是所有用户进程的祖先,由kernel_thread函数创建,kernel_thread函数创建一个新的内核线程(实际linux不支持线程所以是一个内核进程),该线程的入口地址是kernel_init()函数。
设置kernel_thread,继续执行,进入kernel_thread函数定义。
在这里插入图片描述
得到kernel_thread函数通过_do_fork函数来创建进程,于是设置_do_fork断点,进入_do_fork函数定义。
在这里插入图片描述
_do_fork函数主要完成了调用copy_process()复制父进程、调用wake_up_new_task将子进程加入就绪队列等待调度执行等。

### Jupyter Notebook 或 Jupyter LabKernel 无法启动的原因分析 当遇到 `Jupyter Server crash` 并显示 `unable to start kernel error code 1` 的错误时,通常表明存在某些配置问题、环境冲突或者依赖项缺失等问题。以下是可能原因及其解决方案: #### 1. **Kernel 日志中的 Internal Error** 如果 Kernel 启动失败并抛出了内部错误,则可以通过检查日志来定位具体问题。通过搜索关键词 `Internal error` 可以快速找到相关异常信息[^1]。这些日志可以帮助识别是否存在 Python 解释器崩溃或其他低级错误。 #### 2. **Reboot 原因记录** 在一些嵌入式设备上(如基于 MediaTek 芯片的硬件),重启后的关键信息会被打包至数据库文件中,例如 `SYS_REBOOT_REASON` 文件。此文件包含了详细的重启原因以及调试信息[^2]。对于运行在特定硬件上的 Jupyter 实例,可以查阅该文件以获取更多上下文线索。 #### 3. **客户端存根读取消息** 有时问题是由于客户端与服务器之间的通信中断引起的。在这种情况下,客户端存根会尝试从本地内核读取消息[^3]。这一步骤可能会因为网络连接不稳定或权限不足而失败。 --- ### 排查步骤及修复建议 #### A. 检查虚拟环境设置 确保当前使用的虚拟环境中已安装所有必要的依赖库,并且版本兼容。执行以下命令验证: ```bash pip list | grep ipykernel ``` 如果没有发现 `ipykernel`,则需重新安装它: ```bash pip install --upgrade ipykernel ``` #### B. 验证 IPython 内核注册状态 确认目标内核已被正确注册到 Jupyter 上: ```bash jupyter kernelspec list ``` 若未列出对应内核名称,可手动添加支持: ```bash python -m ipykernel install --user --name=myenv --display-name "Python (myenv)" ``` #### C. 查阅完整的 Traceback 输出 打开终端窗口,在其中直接调用 Jupyter Notebook/Lab 来捕获更详尽的日志数据: ```bash jupyter notebook --debug ``` 上述操作有助于揭示隐藏于后台进程背后的深层次矛盾所在之处。 #### D. 更新 Anaconda/Jupyter 组件 保持工具链最新往往能规避许多潜在隐患。利用 Conda 执行全面升级流程如下所示: ```bash conda update conda conda update jupyterlab jupyter_core nb_conda_kernels ``` #### E. 清理缓存资源 偶尔残留的历史元数据也可能干扰正常运作过程。移除临时目录下的相关内容或许有所帮助: ```bash rm -rf ~/.local/share/jupyter/runtime/* ``` --- ### 示例代码片段 下面提供了一段用于测试目的的小型脚本,旨在模拟简单的计算任务同时观察其行为表现是否稳定无误。 ```python def test_kernel(): try: result = sum(range(10)) print(f"Sum of first ten numbers is {result}.") except Exception as e: raise RuntimeError("An unexpected issue occurred during execution.") from e test_kernel() ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值