关于部分服务器存在/缺失/etc/sysconfig/kernel文件的疑问

嘿，我太懂你这种困惑了——明明是同架构同系统的服务器，居然出现配置文件有的有、有的没的情况，确实挺挠头的，我来给你梳理下这个问题：

首先你对/etc/sysconfig/kernel的作用理解完全没错，它核心就是用来控制内核启动选择的，UPDATEDEFAULT（决定装新内核后是否设为默认启动项）和DEFAULTKERNEL（指定默认内核的版本模板）这两个参数是它的关键内容。

至于为什么同环境的服务器会出现文件存在与否的差异，常见原因有这几个：

• 初始化部署方式不同：比如部分服务器是通过Anaconda安装时自动生成了这个文件，而手动部署或者用自定义镜像搭建的机器可能没触发生成逻辑；
• 后期人为/工具变更：有人手动删除过这个文件，或者自动化运维工具（比如Ansible、SaltStack）批量配置时漏掉了部分机器；
• 关联包状态差异：虽然OS和内核版本看起来一致，但grub2-tools这类和启动配置相关的包，若安装状态不同（比如部分机器没装，或者被修改过），也可能导致这个文件不存在——毕竟它是由特定包的触发脚本生成的。

然后你最关心的问题：没有这个文件的话，启动序列会不会受影响？
答案是：大概率不会有问题。因为这个文件本质是给grub2-mkconfig这类生成启动配置的工具提供自定义规则的，当它不存在时，系统会自动启用默认 fallback 逻辑：

• UPDATEDEFAULT的默认值通常是yes，也就是安装新内核后自动设为默认启动项；
• DEFAULTKERNEL的默认模板一般是kernel-%{version}，对应系统里最新安装的内核版本。

简单说，缺了这个配置文件，系统就会走预设的默认规则，不会导致启动失败。如果你想验证的话，也可以在缺失文件的服务器上手动生成一个默认配置：

echo "UPDATEDEFAULT=yes" > /etc/sysconfig/kernel
echo "DEFAULTKERNEL=kernel-%{version}" >> /etc/sysconfig/kernel

然后运行grub2-mkconfig -o /boot/grub2/grub.cfg（UEFI系统路径可能是/boot/efi/EFI/[你的发行版]/grub.cfg），对比生成后的启动配置和之前的状态，你会发现基本和默认情况一致。

备注：内容来源于stack exchange，提问作者hfranco