我仍然不清楚 Kickstart 执行安装后脚本的限制。
我最初的理解是，kickstart 文件的 %post 区域是在安装完成后在系统上执行命令的。我可能会误解的是此执行的上下文，尽管我指示 Kickstart 文件使用 Bash 作为解释器。我有一个 Bash 脚本，可将 CentOS 系统配置为我们网络的信息亭。该脚本单独运行时效果很好，但通常在安装完成并且登录到 GNOME 会话后可以很好地执行。我想采用该脚本，并进行一些修改，让 Kickstart 运行它，以尽可能接近无人值守。仅仅复制和粘贴脚本会产生一些严重的不良效果。首先，后脚本需要小时去完成。如果在 GNOME 中手动运行，在最坏的情况下执行时间不会超过一分钟。其次，当它完成时，有几个方面似乎根本不起作用。例如，配置firewalld的部分似乎尚未运行，因为我的自定义区域和服务完全不存在。此脚本的另一个版本尝试 chmod 触发器文件以有条件地执行另一个脚本，并且在创建触发器文件时，对该文件的 chmod 似乎不起作用。此外，据我所知，anaconda 的日志文件：/tmp/program.log 和 /tmp/install.log，没有显示任何异常，因为任何失败。
我有一个稍微修改过的 Bash 脚本副本，其中删除了一些敏感元素（在执行此操作时会注明）：https://pastebin.com/uSkcdynf。 Kickstart 文件非常标准，仅将此脚本粘贴在该部分的 %post 和 %end 之间。
答案1
@Haxiel 你说得一中要害。我对 chroot 的理解比我开始这次冒险时更好，但仍然没有达到我认为需要的程度。脱离 chroot 使我能够使更改更加持久，更不用说速度的提高是显而易见的。
我想向其他人提出的另一个警告是，如果您的脚本依赖于使用通过 Anaconda 安装的程序，那么您需要进行一些测试，看看这些程序在 chroot 后是否仍然可以工作。破碎的。例如，我无法使用 git，因为程序找不到默认模板目录。即使在我通过全局配置指定了这一点之后，仍然存在所有其他类型的不稳定问题没有明显的修复。将我的脚本工作流程简化为基础确实对完成这项工作大有帮助。