☰

如何安全地将 /lib 移动到已安装的分区

tag-icon • tag-icon debian
如何安全地将 /lib 移动到已安装的分区

我很久以前就创建了根分区，由于 var、home 和 usr 位于不同的逻辑卷中，因此我将其做得很小。不幸的是，/lib 已经增长了不少，我的根分区现在已经满了。我想将 /lib 移动到我创建的新 lvm，并且我已经完成了全部复制，但现在我想挂载 /dev/mapper/MySystem-lib /lib 并删除根分区中的原始 /lib。我已经设法将 /lib 移动到 /lib.old，但还是陷入了困境。

我有两个问题。如果我将挂载放入 /etc/fstab 中，并实际删除根分区上的 /lib，一切都会正常吗？由于我在移动过程中犯了一个不幸的错误，我发现如果没有 lib，像挂载这样的功能就无法工作。

其次，我如何才能删除 /lib 并在其位置安装 /dev/mapper/MySystem-lib？

编辑：我通过移动 opt 而不是 lib 解决了最紧迫的问题（需要使用 root 完整权限进行升级）。为了回答评论中的问题，我添加了以下输出：

sudo lsblk -o +fstype

    NAME           MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT FSTYPE
sdb              8:16   0   1.8T  0 disk
`-sdb1           8:17   0 916.6G  0 part            ext2
sda              8:0    0   1.8T  0 disk            ddf_raid_member
|-sda1           8:1    0   243M  0 part /boot      ext2
|-sda2           8:2    0     1K  0 part
`-sda5           8:5    0   1.8T  0 part            LVM2_member
  |-Oak-root   254:0    0   332M  0 lvm  /          ext4
  |-Oak-swap_1 254:1    0    16G  0 lvm  [SWAP]     swap
  |-Oak-usr    254:2    0   8.4G  0 lvm  /usr       ext4
  |-Oak-var    254:3    0   2.8G  0 lvm  /var       ext4
  |-Oak-tmp    254:4    0   380M  0 lvm  /tmp       ext4
  |-Oak-home   254:5    0   1.2T  0 lvm  /home      ext4
  |-Oak-lib    254:6    0   400G  0 lvm             ext4
  `-Oak-opt    254:7    0   100G  0 lvm  /opt       ext4
sr0             11:0    1  1024M  0 rom

命令

 VG   #PV #LV #SN Attr   VSize VFree
  Oak    1   8   0 wz--n- 1.82t 134.97g

sudo lvs

 LV     VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  home   Oak  -wi-ao----   1.17t
  lib    Oak  -wi-a----- 400.00g
  opt    Oak  -wi-ao---- 100.00g
  root   Oak  -wi-ao---- 332.00m
  swap_1 Oak  -wi-ao----  15.93g
  tmp    Oak  -wi-ao---- 380.00m
  usr    Oak  -wi-ao----   8.38g
  var    Oak  -wi-ao----   2.79g

另外，虽然我理解（并且有点假设在通过移动它从我自己下面切断我的分支几次之后，你无法将 /lib 移动到不同的分区），但如果有人真正了解动态链接库如何运行以及启动过程如何工作，可以写出答案说明为什么尝试这样做并不明智，那就太好了。

答案1

从评论来看，您已经通过扩展根文件系统解决了磁盘空间问题。但无论如何，这里有一个更详细的解释...

让我们看一下最简单的二进制文件的库依赖关系：/bin/true。

$ ldd /bin/true
    linux-vdso.so.1 (0x00007ffef25f3000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4635f40000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f4636159000)

其中第一个linux-vdso.so.1是虚拟动态共享对象它根本不存在于磁盘上，而是由内核导出到它加载的每个程序。其目的是使系统调用更高效。

第二行指的是libc.so.6。这是 C 库，通常是glibc。在 Debian 和相关发行版中， 下有一个x86_64-linux-gnu子目录，/lib允许任意数量的系统架构轻松共享系统磁盘。

第三行指的是动态链接器/加载器ld-linux-x86-64.so.2（在不同的系统架构上名称显然会有所不同）。

如果预期路径上没有动态链接器/加载器，系统将无法完成任何未完全静态链接的二进制文件（=可执行程序）的加载过程。现代 Linux 系统上的大多数二进制文件都不是静态链接的，因为静态链接的程序往往比动态链接的程序占用更多的磁盘空间。

C 库是所有库文件中最重要的：即使是最简单的二进制文件也往往依赖于它。

当系统启动时，标准的 initramfs 通常被设计来处理最少数量的任务：

  • 如果需要的话启用交换
  • 挂载根文件系统
  • 如果启用了休眠（挂起到磁盘）模式，则可以选择性地启动从休眠映像恢复的过程

由于 initramfs 通常只关心根文件系统，因此根文件系统必须足够独立，以便在从 initramfs 切换到实际根文件系统后，启动过程可以立即继续。这意味着根文件系统必须至少包含必要的系统库、可执行文件和配置文件。传统上，这意味着根文件系统必须包含/etc、/lib和（如果系统架构使用，也必须/bin包含）。/sbin/lib64

从技术上来说，构建一个自定义的 initramfs 文件也许可行，例如/lib在转换到真实根文件系统时，该文件也会挂载一个单独的文件系统，但这会给启动过程的关键早期阶段带来很多麻烦。我不建议这样做。

因此，标题中问题的答案是“不，您不能（轻易地）将 /lib 移动到不同的文件系统并让系统保持可启动状态。”

由于您的根文件系统位于ext4LVM 上，并且根据命令，包含根文件系统的 LVM 卷组具有大量可用（未分配）容量vgs，因此您可以轻松在线扩展您的根文件系统。

当系统正常运行时，您需要做的就是：

  1. 戴上你那酷酷的太阳镜B-)
  2. sudo lvextend -L <new-size>G --resizefs /dev/mapper/Oak-root
  3. 完毕。

但是，正如您已经发现的那样，当将 ext2/3/4 文件系统扩展到最初创建大小的 100 倍以上时，您需要注意，您可能会遇到一个限制，阻止您在线完成扩展。如果达到此限制，最简单的解决方法是使用外部实时 Linux 媒体启动系统，激活卷组（如果使用 LVM），并resize2fs在未挂载的根文件系统上运行：这将自动执行“离线”文件系统扩展，它可以超过该限制，并自动保留足够的新 gdb 块，以允许文件系统在线扩展到至少 100 倍新的尺寸。

常用resize2fs命令是 e2fsprogs 包的一部分，但存在替代的 ext2/3 调整大小工具包：GNU ext2resize。不幸的是，自从 ext4 文件系统类型开发以来，它的开发就停滞了，但它包含一个额外的ext2prepare工具，可以离线使用，预先增加 gdb 块的数量，以便随后在线文件系统扩展到初始大小的非常高的倍数。添加类似的功能是resize2fs其开发人员的待办事项清单。

相关内容