我正在尝试设置用于 kubernetes 的 containerd通过Ubuntu 的自动安装机制(适用于 Ubuntu 20.04)。
某些命令在使用时late-commands
似乎会失败而没有明显的原因。(退出 > 0,没有描述性输出。)失败的代码片段如下late-commands
:
late-commands:
- printf 'overlay\nbr_netfilter\n' > /target/etc/modules-load.d/containerd.conf
- curtin in-target --target=/target -- /usr/sbin/modprobe overlay
- curtin in-target --target=/target -- /usr/sbin/modprobe br_netfilter
安装程序出错,显示调用modprobe
退出 1。
我重新启动虚拟机,以 身份登录ubuntu
,然后变成root
。那时我可以modprobe overlay
成功运行(退出 0)。我还看不到/var/crash/16238...
(见上文),因为它似乎不存在于目标上。(我猜它存在于安装程序环境中。)/var/log/installer
也没有包含任何有用的东西。
鉴于上述情况,什么可能导致modprobe
失败late-command
?看似无关的是,我也尝试过一个chage -d 0
失败的调用,并且没有任何错误消息。是否可以解释为什么某些命令在那个阶段可能不存在或在目标环境中无法正常工作?
编辑 1:关于 usermod 失败,我猜测这个回复暗示在安装过程中没有创建 ubuntu 用户。
编辑2:我添加了一个error-commands
似乎对调试有用的:
error-commands:
- /usr/bin/tail -n 250 /var/log/syslog
现在显示Module overlay not found in /lib/modules/...
:
答案1
该问题的根本原因是由于重启之前内核已更新,导致 modprobe 查找了错误的位置。
在安装过程中,您可以使用CTRL+Z
以 root 用户身份进入 Bash shell安装程序。在此环境中,/cdrom
是已安装的 ISO(iso9660),/target
是目标文件系统的根目录。这是一种调试curtin in-target
命令的好方法,这些命令在内部基本上是一个chroot /target
调用。
对于 modprobe 来说,输出显示:
modprobe: FATAL: overlay module not found in directory /lib/modules/5.4.0-65-generic
虽然此目录确实存在于安装程序,在目标上实际存在的是:
/target/lib/modules/5.4.0-80-generic
注意 modprobe 没有检测到内核版本的细微变化。我相信这是由于安装过程中的内核更新造成的。
作为此特定命令的修复,modprobe
您可以设置版本:
curtin -v in-target --target=/target \
-- /usr/sbin/modprobe --set-version 5.4.0-80-generic overlay
该--set-version
命令将成功运行并退出0。