问题背景#

最近在 Fedora Silverblue 上用 systemd-homed 遇到了个很烦人的问题。

Silverblue 里 /home 实际上是 /var/home 的软链接，这本来没啥问题，但不同软件获取路径的方式不一样，就会导致路径混用的情况。

比如我用 GNOME 桌面设置的快捷键打开 ghostty，进去之后路径显示的是 /var/home/username。但如果点击 desktop 文件启动，路径就变成 /home。更离谱的是在 VSCode 里打开一个工程 /home/project，然后在 VSCode 中右键用文件管理器打开，跳出来的路径又变成了 /var/home/project。

这种混用给我造成了极大的困扰，经常搞不清楚自己在哪个路径下工作，有时候还会导致一些奇怪的问题。所以我决定把 systemd-homed 的配置统一改成 /var/home，彻底避免这个软链接带来的麻烦。

尝试用 homectl 更新#

按照文档，我执行了：

1
sudo homectl update username --home-dir=/var/home/username --image-path=/var/home/username.home

命令跑完了，没报错，看起来挺正常。但重新登录后发现 $HOME 还是老路径，根本没变。

排查过程#

开始排查的时候，我先看了 ~/.identity 文件，发现这个文件倒是更新了，新的路径都在里面。但问题是系统压根不认这个配置。我猜测可能是 LUKS 加密容器的头部信息和系统里实际记录的配置没同步更新。

homectl 这个命令有时候就是这样，表面上执行成功了，实际上某些底层的东西没跟着动。

解决方案#

后来我直接去翻 /var/lib/systemd/home/ 目录，找到了 username.identity 这个文件。打开一看，果然里面的 homeDirectory 和 imagePath 还是旧的。于是我手动改了：

1
"homeDirectory" : "/var/home/username",
2
"imagePath" : "/var/home/username.home",

保存之后重启系统，这次 $HOME 终于变成 /var/home/username 了。现在所有软件获取到的路径都统一了，不会再出现 /home 和 /var/home 混用的情况。

重要提醒#

不过这个方法有个局限性，需要特别注意。

实际上这种方式并没有更改 LUKS 头部的信息。因为 LUKS 头部信息是加密的，要修改相当麻烦，homectl 也没能正确更新它。我这个手动改 identity 文件的方法，只是让当前系统认了新路径，但 LUKS 容器本身记录的还是旧的 /home 路径。

这意味着如果你把这个 home 目录迁移到新系统上，新系统读取 LUKS 头部信息时，识别到的还是 /home，而不是 /var/home。到时候又得在新系统上重新手动改一遍 identity 文件。

所以这个方案只能算是个权宜之计，治标不治本。如果真要彻底解决，可能得重新创建 home 目录，或者找到正确修改 LUKS 头部信息的方法。但对于我这种只在单个系统上使用的情况，暂时够用了。

总结#

说实话，homectl 这套工具还是有点不够成熟，有些操作不能完全信任它的返回状态。遇到类似问题的话，直接去改 /var/lib/systemd/home/ 下面的 identity 文件可以临时解决问题，但要清楚这只是让当前系统认了新配置，底层的 LUKS 信息并没有真正更新。