☰

还可以绑定挂载/usr吗？

tag-icon • tag-icon linux systemd mount
还可以绑定挂载/usr吗？

我曾经从另一个卷绑定挂载/usr，因为我的根卷几乎已满。然而，对于 KUbuntu 22.04.1 LTS，即systemd版本 249.11，我发现现在不可能了。

这是我之前的做法/etc/fstab：

LABEL=bigvol    /bigvol         auto defaults,noatime,nodiratime,barrier=1,ro  0 2
/bigvol/d-sys/2023-02/usr  /usr auto bind,ro       0 0

即，使用 时0 2，/bigvol卷在启动时安装，使用 时0 0，/usr卷直到稍后才安装。

它已经这样工作了 10 多年，但在systemdlinux-image-5.15.0-60 下的版本 249.11+ 中，它开始绑定/usr在安装任何其他卷之前安装该卷，即使根卷临时安装为 as/root而不是 as /。

更新：

所以我尝试了建议的

/bigvol/d-sys/2023-02/usr /usr auto bind,ro,x-systemd.requires-mounts-for=/bigvol 0 0

它是不是工作，停在相同的当根卷临时安装为 as/root而不是 as时放置/。

但 Freddy 的答案看起来非常令人信服，以至于我尝试了其他方法 - 使用完全相同的语法来绑定挂载其他内容（注释掉此/usr绑定挂载，但添加了另一个绑定挂载目录/var/cache/apt/archives）。而且，它有效！

所以看来

  1. systemd知道/usr卷很特殊，应该挂载前还要别的吗。
  2. 但它没有看到我的/usr卷只是应该安装的绑定安装后还要别的吗。
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.1 LTS
Release:        22.04
Codename:       jammy

$ apt-cache policy linux-image-5.15.0-60-generic
linux-image-5.15.0-60-generic:
  Installed: 5.15.0-60.66
  Candidate: 5.15.0-60.66
  Version table:
 *** 5.15.0-60.66 500
        500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        100 /var/lib/dpkg/status

$ apt-cache policy systemd
systemd:
  Installed: 249.11-0ubuntu3.6
  Candidate: 249.11-0ubuntu3.6
  Version table:
 *** 249.11-0ubuntu3.6 500
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     249.11-0ubuntu3 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages

答案1

您可以添加x-systemd.requires-mounts-for=/bigvol到绑定挂载的挂载选项以在之后挂载它/bigvol。

从systemd.mount — 安装单元配置:

x-systemd.requires-mounts-for=

配置RequiresMountsFor=创建的挂载单元与其他挂载单元之间的依赖关系。参数必须是绝对路径。该选项可以指定多次。有关详细信息，请参阅RequiresMountsFor= systemd.unit(5)。

从systemd.unit — 单元配置:

RequiresMountsFor=

采用空格分隔的绝对路径列表。自动添加访问指定路径所需的所有安装单元的类型Requires=和依赖项。After=

标有 noauto 的安装点不会通过 来自动安装 local-fs.target，但仍会出于此选项的目的而受到尊重，即它们将被此单元拉入。

LABEL=bigvol               /bigvol  auto defaults,noatime,nodiratime,barrier=1,ro       0 2
/bigvol/d-sys/2023-02/usr  /usr     auto bind,ro,x-systemd.requires-mounts-for=/bigvol  0 0

答案2

这是来自/Ubuntu 20.04 系统：

:/$ ls -la | grep -- '->'
lrwxrwxrwx   1 root root    7 Sep 28  2020 bin -> usr/bin
lrwxrwxrwx   1 root root    7 Sep 28  2020 lib -> usr/lib
lrwxrwxrwx   1 root root    9 Sep 28  2020 lib32 -> usr/lib32
lrwxrwxrwx   1 root root    9 Sep 28  2020 lib64 -> usr/lib64
lrwxrwxrwx   1 root root   10 Sep 28  2020 libx32 -> usr/libx32
lrwxrwxrwx   1 root root    8 Sep 28  2020 sbin -> usr/sbin

假设 Ubuntu 22.04 类似，尝试/usr从根分区中删除意味着内核首次启动时no /bin、 no /lib、 no /lib32、 no /lib64、 no/libx32和 no可用。/sbin

鉴于 pid 1 是/sbin/init，这意味着根分区上没有init进程来启动一切。

毫不奇怪它不起作用。

似乎假设您不需要一个大根分区的日子已经结束了。

相关内容