anaconda-ks.cfg 是纯文本 kickstart 文件，非 xml 格式；由命令段、%packages 段、%pre/%post 脚本段组成，语法为明文指令，无标签、属性或嵌套结构，严格遵循 red hat 官方 kickstart 规范。
anaconda-ks.cfg 是 CentOS/RHEL 系统安装完成后自动生成的 Kickstart 应答文件，它以纯文本格式记录安装过程中的全部配置选项。该文件不包含任何 XML 片段，其语法完全基于 Kickstart 规范定义的命令行式结构，所有内容均为 ASCII 文本，由命令段、%packages 段、%pre/%post 脚本段组成，严格遵循 Kickstart 语法规则，与 XML 格式无关。
一、anaconda-ks.cfg 的真实结构组成
anaconda-ks.cfg 文件由三类核心部分构成：命令段（全局安装参数）、%packages 段（软件包选择）和脚本段（%pre/%post）。每一部分均使用明文指令，无标签嵌套、无属性声明、无闭合标签，与 XML 的树状结构、尖括号语法、命名空间等特征完全不兼容。该文件被设计为可被 anaconda 安装程序直接解析执行，而非被 XML 解析器处理。
1、命令段位于文件开头，包含 install、url、lang、keyboard、network、rootpw、firewall、timezone、bootloader、partition 等指令，每行一条，以空格分隔参数。
2、%packages 段以 %packages 开头，以 %end 结尾，内部使用 @group_name 表示软件包组，package_name 表示单个包，-package_name 表示排除包。
3、%pre 和 %post 脚本段分别以 %pre 和 %post 开头，以 %end 结尾，其内容为 Shell 脚本代码，运行于安装前或安装后环境。
二、为何不存在 XML 片段的验证依据
Kickstart 规范由 Red Hat 官方定义并维护，其语法文档明确指出：Kickstart 文件是“plain text files”，所有指令均为自由格式的命令行，不采用任何标记语言。anaconda 安装程序的 ksparser 模块仅识别以字母开头的命令关键字（如 network、part、authconfig），以及以 % 开头的段标识符（%packages、%post），完全忽略 XML 声明、DOCTYPE、开始/结束标签、CDATA 等所有 XML 元素。若在 ks.cfg 中插入 XML 片段，将导致 ksvalidator 报错或 anaconda 解析失败。
1、执行 ksvalidator /root/anaconda-ks.cfg 可验证语法合法性，输出中若出现 “Invalid syntax” 或 “Unknown command” 提示，即表明存在非法字符或结构。
2、查看原始文件头部注释行：# Kickstart file automatically generated by anaconda. —— 此行已明确声明文件性质为 Kickstart 自动生成文本，非 XML。
3、对比标准 XML 示例（如
三、常见误判 XML 的来源分析
部分用户误认为 anaconda-ks.cfg 含有 XML 片段，通常源于将其他自动化部署工具（如 Cobbler 的 profile XML 配置、Ansible 的 vars 文件、或某些 Web UI 导出的配置模板）与 Kickstart 文件混淆。此外，当 ks.cfg 被嵌入 HTTP 响应体或通过 CGI 返回时，响应头可能包含 Content-Type: application/xml，但这仅表示传输封装方式，不改变 ks.cfg 文件本身的纯文本本质。
1、Cobbler 系统中，kickstart 模板存储于 /var/lib/cobbler/kickstarts/，其后缀为 .ks，内容仍为 Kickstart 语法；而 profiles 使用 XML 格式存储于 /var/lib/cobbler/config/profiles.conf。
2、某些第三方图形化编辑器（如早期 system-config-kickstart）导出时若启用“XML export”选项，会生成独立的 .xml 文件，但该文件并非 anaconda-ks.cfg，也不被 anaconda 读取。
3、在调试网络安装时，若 PXE 引导参数中 ks=http://host/ks.xml，实际服务端必须返回纯文本 ks.cfg 内容，HTTP 服务器不可返回 XML 格式响应体，否则安装将中断。
