WSL启用systemd后初始化卡顿（Arch发行版）的优雅解决方法及systemd首次启动判定逻辑咨询

最近我在Arch WSL里启用systemd后碰到了个棘手的问题——系统卡在初始化环节动不了。我的环境是WSL 2.0.9.0版本，内核5.15.133.1-1，主机是Windows 11。

折腾了半天，查了systemd试图启动的服务列表，发现是systemd-firstboot.service一直卡在激活状态。当时急着解决，就直接杀掉了它启动的firstboot进程，结果用sudo systemctl status一看系统处于降级状态，而且没法重启这个服务，提示不满足Firstboot条件——这就很奇怪了，我之前明明已经用过这个WSL实例了，根本不该触发首次启动流程啊。最后只能执行wsl --shutdown关掉WSL再重启，没想到这一下systemd居然正常初始化了。

虽然问题解决了，但总觉得杀进程这种方法太粗暴了，想请教下有没有更优雅的处理方式？另外也很好奇，systemd到底是通过什么参数来判断系统是不是首次启动的呢？

先说说systemd判断首次启动的核心逻辑 #

systemd触发systemd-firstboot.service主要看几个关键系统文件的状态：

• /etc/machine-id：这个文件存储着系统的唯一标识，首次启动时会自动生成。如果这个文件存在且内容非空，systemd默认就会认为系统已经完成过首次配置，不会触发firstboot流程。
• /var/lib/systemd/random-seed：用于保存系统随机种子，首次启动后会自动创建，也是判断启动状态的一个依据。
• 对于WSL环境，可能还会结合WSL自身的一些运行状态，但核心判定还是依赖上述两个文件。如果这些文件因为某种原因损坏、丢失或者未正确生成，就可能导致systemd误判，触发本不该运行的firstboot服务。

更优雅的解决方法 #

方法一：手动修正首次启动标识文件，避免误触发

1. 先关闭WSL：wsl --shutdown
2. 直接启动Arch WSL的shell而不加载systemd：wsl -d <你的Arch发行版名称> -e bash（比如我的发行版叫Arch，就用wsl -d Arch -e bash）
3. 检查/etc/machine-id：如果文件为空或者不存在，执行sudo systemd-machine-id-setup生成有效的机器ID
4. 检查/var/lib/systemd/random-seed：如果不存在，执行sudo systemd-random-seed save生成随机种子文件，或者直接创建空文件sudo touch /var/lib/systemd/random-seed
5. 如果你确定以后都不需要firstboot服务，可以直接禁用它：sudo systemctl mask systemd-firstboot.service（mask比disable更彻底，会让服务完全无法启动）
6. 最后执行wsl --shutdown再重启WSL，systemd就能正常初始化了

方法二：重置卡住的firstboot服务（不用杀进程）

如果只是临时卡住，还没到要杀进程的地步，可以试试：

1. 在WSL里执行sudo systemctl stop systemd-firstboot.service，尝试正常停止服务
2. 重置服务的失败状态：sudo systemctl reset-failed systemd-firstboot.service
3. 检查/etc/machine-id是否正常，确认没问题后重启WSL即可

补充说明：为什么杀进程后会出现降级状态？ #

强制杀掉firstboot进程会导致它的依赖服务启动失败，systemd为了保证系统基本可用，会进入降级模式。而重启WSL后，systemd重新检查系统状态，发现/etc/machine-id等标识文件存在，就跳过了firstboot流程，所以能正常启动了。

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