Linux FU：移动/用户

Linux已经改变了。最初受到Unix的启发，有一些很好理解但没有很好执行的规则，每个人都理解。程序做一些小事，并使用管道进行通信。X Windows服务器并不总是在您的本地计算机上运行。/usr中的任何内容都无法引导系统。

这些天，我们有系统地控制一切。如果你在一台显示器上运行Chrome，它就会被锁定在那台显示器上，它真的希望那是本地显卡。除非您采取预防措施，否则将/usr移到另一个分区很容易阻止您启动。我搬家了，我活着讲述了这件事。如果你需要这样做，你会想听听我的故事。

很多人都在批评systemd--包括我在内--但实际上这不是systemd的错。当我们有更多的程序员时，这些原则就会丧失，而且他们中的许多人都受到其他系统的影响，在这些系统中，事情的工作方式不同。不过，我不是在大喊大叫。我最近的一次经历让我想起了这一切，在此过程中，我学到了一些关于引导过程的现代状态的东西。故事开始于一位朋友给了我一个英特尔计算棒。但我遇到的问题并不是特定于该硬件，而是现代Linux发行版如何管理它们的启动过程。

就像我说的，我的一个朋友给了我一个英特尔计算棒。这是早期相当贫血的疾病之一。特别是，它只有1 GB的内存和8 GB的闪存。它启动了一个旧版本的Ubuntu，正如你所预期的那样，速度相当慢。但我喜欢它的外形，而且我有一个可以使用永久性PC的新工作室，所以我决定升级它。

出现了一些常见的问题。BIOS升级中断了网络。升级到KDE Neon修复了网络，但较新的内核有可怕的C-State bug，导致挂起。幸运的是，这很容易解决。所以经过一些努力，我有了一个合理的工作系统。说大也大吧。

问题出在8 GB的闪存。我放了一张64 GB的SD卡，但我不想从它启动。安装了霓虹灯和一些其他必需品后，闪光灯几乎100%满了。我的计划是/opt/home，/usr转到SD卡。我以为这会很容易。

传统上，这是一个简单的过程。首先，使用无需更改即可获得隐藏文件和链接的内容复制文件。许多人使用rsync，但通常使用tar。然后删除旧目录(为了安全起见，我先将其重命名，并在一切正常后将其删除)。最后，创建一个新的空目录，并更改/etc/fstab以在引导时挂载磁盘。

对于/home和/opt，这很好。系统会毫不费力地启动，我很快就把它做好了。我知道/usr会有点难，但我想我可以在没有GUI的根shell中，或者只需从USB驱动器引导并执行所有相同的工作。

实际上我预计会有四匹坐骑。我将整个SD卡挂载到/sdcard。然后，我确实将挂载从/sdcard/opt绑定到/opt，将/sdcard/home绑定到/home。/usr挂载也是绑定挂载，但不会那么容易。

我尝试移动/usr导致系统停止引导。为什么？原来systemd负责挂载/etc/fstab中的内容，而systemd需要/usr中的内容。我认为如果systemd不必读取/etc/fstab，那么它可能足够智能来引导系统，所以我决定使用systemd的本机设施挂载SD卡。

Systemd可以像处理服务一样处理挂载。这意味着它将管理安装，并将其编织到依赖项中。因此，在挂载某些磁盘之前，可能要求服务或其他挂载准备就绪，当然，其他服务和挂载也可能依赖于该磁盘。理论上，这是完美的，因为例如，在挂载/sdcard之前尝试挂载/sdcard/home是没有意义的。

显然，UUID会根据磁盘的不同而改变。不是很明显，这个文件必须命名为sdcard.mount。如果挂载点是/usr/lib，那么文件必须是usr-lib.mount。

请注意，挂载需要/sdcard。一旦您将这些文件放到正确的位置并重新加载系统，您就可以启动这些单元，文件将会挂载。您可以使它们在引导时启动。除了文件名之外，/opt单元看起来完全相同。

这仍然给/usr留下了问题。当然，编写单元很容易，但问题是systemd需要/usr之外的一些库，所以系统将拒绝引导。我考虑将库复制到/lib或初始RAM磁盘中的某个位置，但在发现有相当多的库之后，我决定不这么做。

我最终决定，在引导过程的早期挂载所有内容将是正确的答案。这样，systemd就可以想象它有一个完整的磁盘。我实际上曾考虑过使用LVM将磁盘连接在一起，但由于很多原因，我认为这是不好的，而且可能会遇到同样的问题。我想要控制SD卡和内部存储上的内容，所以是时候看看initramfs脚本了。

大多数现代Linux发行版不会直接引导您的根文件系统。取而代之的是，它们有一个压缩的文件系统，加载到RAM中，然后引导。该系统负责使系统为真正的引导做好准备。除了其他功能外，它还挂载根文件系统，然后旋转以使其成为真正的根。

对于Debian风格的发行版，这是initramfs，您可以在/etc/initramfs-tools中找到一些用户可定义的脚本。大部分预定义文件位于/usr/share/initramfs-tools中。在脚本目录中，您将看到许多后缀为-top、-Bottom和-premount的子目录。

正如您可能想象的那样，init-*发生在系统初始化时，而local-*发生在挂载本地磁盘时。不要将这些与钩子脚本混淆。钩子脚本在构建初始文件系统时执行。如果您需要静态修改引导环境，这会很有帮助。我们需要的脚本是在引导时执行的脚本。

首先运行顶部脚本，然后运行预装载，然后运行底部脚本。所以init-top首先运行，而init-Bottom是最后运行的。在此期间，其他脚本运行，并在本地底层运行，根文件系统应该可以运行了。

如果您阅读文档，您将看到脚本具有特定的格式。然而，也有一些例子具有误导性。例如，模板脚本显示获取/usr/share/initramfs-tools/钩子函数以加载通用函数。如果/usr已经存在，那就太好了，但是对于我们来说，它不存在。其他一些脚本使用位于/usr/share/initramfs-tools/script/function的引导环境中的副本。这就是我在剧本中使用的：

唯一棘手的部分是我们最终的根文件系统不在/，而是在/root，所以挂载反映了这一点。

当然，我必须禁用/opt和/home的systemd挂载，尽管我本可以离开它们而不将它们放在此脚本中。现在，在systemd获得控制之前，它可以在/usr中找到它想要的所有内容，并且系统会引导。移动这三个目录给我留下了大约70%的内部存储空间，只占用了SD卡的一小部分。

可能还有许多其他方法可以做到这一点。我提到了LVM，或者您可以恢复到旧的初始化脚本。但是，一旦你把一切都弄清楚了，这确实可以可靠地工作，而且非常灵活。

英特尔棒很小，但我们见过更小的。如果您确实在家里尝试这样做，不要忘记登录到eMMC设备并不总是一个好主意。