【arm扩容】新硬盘挂载操作说明

背景：

未经过扩容的arm设备不满足移植大镜像的条件。

需求：

我们要对arm设备扩容，现在要将一个500G的硬盘挂进去。而且要按照老arm设备的挂法，保持相同的目录结构。配置这台机器。

下面老arm设备的硬盘挂载相关信息。

lsblk

nvme0n1 259:11 0 465.8G 0 disk
└─nvme0n1p1 259:12 0 465.8G 0 part /home/nvidia/work

sudo fdisk -l

Disk /dev/nvme0n1: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe073784d

Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 2048 976773167 976771120 465.8G 83 Linux

设置开机自动挂载：为了使分区在系统启动时自动挂载，需要编辑 /etc/fstab 文件

# /etc/fstab: static file system information.
#
# These are the filesystems that are always mounted on boot, you can
# override any of these by copying the appropriate line from this file into
# /etc/fstab and tweaking it as you see fit.  See fstab(5).
#
# <file system> <mount point>             <type>          <options>                               <dump> <pass>
/dev/root            /                     ext4           defaults                                     0 1
/dev/nvme0n1p1       /home/nvidia/work     ext4           defaults                                     0 0

步骤 1: 连接新硬盘

确保新的 500GB 硬盘已经正确连接到 ARM 设备，并被系统识别。可以通过 lsblk 或 fdisk -l 命令查看。df -h。

步骤 2: 创建分区和格式化

使用 parted 或 fdisk 创建 GPT 分区表，并创建一个主分区覆盖整个硬盘。然后，格式化新分区为 ext4 文件系统。例如：

shell

sudo parted /dev/nvme0n1 mklabel gpt

sudo parted /dev/nvme0n1 mkpart primary ext4 2048s 100%

sudo mkfs.ext4 /dev/nvme0n1p1

注意：这里假设新硬盘被识别为 /dev/nvme0n1，请根据实际情况调整。

步骤 3: 创建挂载点

确保挂载点目录存在，如果尚未创建，则创建之：

shell

sudo mkdir -p /home/nvidia/work

sudo chmod -R 777 work/

步骤 4: 挂载新分区

手动挂载新分区到指定挂载点，以验证一切正常：

shell

sudo mount /dev/nvme0n1p1 /home/nvidia/work

【这步不做】复制根文件系统:使用rsync命令递归地将当前系统（排除特定目录如/dev/, /proc/, 等）复制到挂载点，以准备系统部署。

sudo rsync -aAXv / --exclude={"/dev/","/proc/","/sys/","/tmp/","/run/user/","/mnt/","/media/*","/lost+found"} /mnt

是否需要执行此步骤？

如果目的是单纯增加额外的存储空间，并计划使用新分区挂载到一个特定目录（如 /home/nvidia/work_expanded），用于存放工作文件或扩展某个特定目录，那么不需要执行这个复制步骤。只需按照之前的步骤配置挂载即可。
如果目的是克隆现有的系统分区到新硬盘，以实现系统迁移、备份或准备一个可启动的系统副本，那么执行这个步骤是有必要的。这能获得一个包含操作系统、配置和用户数据的完整副本。详细见附录2

步骤 5: 更新 `/etc/fstab`

# 如有需要，先解挂之前手动挂载的设备

sudo umount /dev/nvme0n1p1

编辑 /etc/fstab 文件，添加新分区的挂载信息，以便系统启动时自动挂载。同时，考虑到您可能想继续使用原有分区，可以考虑修改原挂载点或使用新挂载点。这里以新挂载点为例：

shell

# 添加如下行至 /etc/fstab

/dev/nvme0n1p1 /home/nvidia/work ext4 defaults 0 0

步骤 6: 测试挂载配置

运行 mount -a 命令测试 /etc/fstab 中的挂载配置是否正确，无误则会在不重启的情况下挂载所有分区。

# 测试 /etc/fstab 配置是否生效

sudo mount -a

问题：别的帖子最后使用umount命令卸载之前挂载的设备sudo umount /dev/nvme1n1p1，为什么有这个操作？那之前的操作不是都白干了？

答：在完成一系列操作，比如挂载新分区、复制文件系统等之后，使用 umount 命令卸载之前挂载的设备（如 sudo umount /dev/nvme0n1p1）是一个标准且重要的步骤，其原因包括：

安全地断开连接：在对硬盘或分区进行进一步操作（如物理移除硬盘、修改分区表、重新格式化等）之前，卸载挂载点可以确保没有进程正在访问该分区上的文件，避免数据损坏或丢失。
测试挂载配置：如您之前提到的，执行 mount -a 用来测试 /etc/fstab 配置是否正确。在这之后卸载分区，可以模拟重启后的情况，确认分区能够在没有其他手动干预的情况下正确挂载。
避免意外重启的问题：如果不卸载就进行系统重启，有时可能导致挂载点的状态不一致或挂载失败，尤其是在对 /etc/fstab 进行修改后。提前卸载并重新挂载可以减少此类风险。
并非白干：之前的操作并没有白干。即使卸载了分区，您对分区的格式化、复制文件系统等操作已经完成，这些更改都保留在硬盘上。当需要时，通过 /etc/fstab 设置或手动挂载命令，该分区仍能按照预期挂载并使用。

所以，使用 umount 命令实际上是操作流程中的一个重要环节，确保系统状态的清晰和后续操作的安全性，而不是取消之前工作的效果。

另外，

umount 是用于卸载（解除挂载）文件系统。
mount -a 是用于根据 /etc/fstab 文件的配置挂载所有未挂载的文件系统。

# （可选）测试完毕后，再次解挂，准备进行其他操作或模拟重启挂载

sudo umount /dev/nvme0n1p1

如何模拟重启挂载

即验证经过修改的 /etc/fstab 文件能否使系统正确挂载所有分区，而不实际进行物理重启，可以采用以下方法：

确保无相关分区挂载：首先，使用 umount /dev/nvme1n1p1 或类似的命令确保您想要测试的分区已经被卸载。如果有多块硬盘或多个分区，需要对它们逐一执行卸载操作。
清空挂载点：如果挂载点上有残留的进程或打开的文件，可能会影响挂载测试。确保挂载点目录为空或其内容与预期的挂载行为无关。必要时，可以使用 fuser -km /挂载点路径 命令杀死占用挂载点的进程。
执行 mount -a：再次执行 sudo mount -a 命令。这一步会尝试根据 /etc/fstab 文件中的配置挂载所有未挂载的文件系统，模拟了系统启动时的挂载过程。
检查挂载状态：使用 mount 或 df -h 命令检查所有分区是否按照 /etc/fstab 中的设定正确挂载。同时，检查系统日志（如 dmesg 或 /var/log/messages）以获取有关挂载操作的详细信息，看是否有任何警告或错误。

通过以上步骤，您可以在不实际重启系统的情况下，较为准确地模拟和验证系统重启时的挂载行为。如果所有分区都按预期挂载，那么在下一次实际重启时，挂载过程应该也会顺利进行。

步骤 7: 移动数据（可选）

如果您打算用新分区完全替代旧挂载点，需要将 /home/nvidia/work 下的数据移动到 /home/nvidia/work，然后更新相关服务或配置文件中的路径指向新挂载点。

步骤 8: 重启验证

最后，重启系统并验证新分区是否能正确自动挂载。

sudo reboot

附录1：更改挂载点

注意：中间可能会出问题，比如/mnt节点现在正在被占用，有进程在里面，需要停掉这些进程之后再继续。

现在盘的挂载状态

lsblk 或 df -h 查看

我现在要把nvme0n1p1从/mnt解挂，然后挂到 /home/nvidia/work上

强制解挂（若没改etc那个文件，重启也行）

sudo umount -l /mnt 或 sudo umount -l /dev/nvme0n1p1

检查当前挂载点状态，可以发现已成功解挂

我没有/home/nvidia/work目录所以建一个

mkdir -p /home/nvidia/work

然后去改fstab文件，也就是步骤五。

接下来继续步骤六，去测试。

此时在电脑上已经可以看到

然后我们用 df -h 看一下

最后reboot重启。

附录2：引导加载器

关于/boot/extlinux下的extlinux.config文件是否需要更改

更改根文件系统路径是为了让系统从新设备启动，而不是继续依赖旧设备。引导加载器是服务于系统启动过程

因此，按照需求分情况讨论：

一：如果目标是制作一个可以在任何支持UEFI的机器上即插即用的系统硬盘，那么创建ESP并正确配置引导加载器是必要的。

EFI系统分区的作用：创建EFI系统分区（ESP）是实现UEFI启动的关键步骤之一，它使得系统可以从硬盘直接启动，增强了硬盘的可移植性。ESP包含引导加载器的启动文件和其他UEFI应用程序，使得不同的系统和设备可以在UEFI环境下识别并启动操作系统。

UEFI启动模式：UEFI启动模式并不是特指U盘启动，而是一种现代的替代传统BIOS的系统启动方式。

UEFI（Unified Extensible Firmware Interface，统一可扩展固件接口）是一种详细描述类型接口的标准，用于操作系统与系统固件之间的交互，以便加载操作系统和其他预启动应用程序。

在UEFI启动模式下，不仅可以从硬盘、SSD等内部存储设备启动操作系统，也可以从外部设备如U盘、外置硬盘或网络启动。当使用U盘进行系统安装或启动修复时，如果电脑和U盘都支持UEFI模式，就可以采用UEFI U盘启动。这意味着U盘上的启动装载程序（如EFI文件）需要与系统的UEFI固件兼容，从而实现更快速、更安全的启动过程。

去做EFI系统分区是为了能让系统从硬盘启动，让硬盘具有可移植性，就像烧录盘一样，放到别的机器上也可以直接启动硬盘里的系统。如果不做EFI系统分区，我只是以扩容为目的，那么我其实没必要设置引导加载器

二.只做扩容的情况：如果目的纯粹是扩容，即只是想增加存储空间，而不打算将新硬盘作为主启动盘，那么不需要在新硬盘上创建EFI系统分区或安装引导加载器。

在这种情况下，新硬盘仅作为数据存储使用，系统仍然从原来的启动设备（如 /dev/mmcblk0p1）启动。不过，即使不涉及启动，为了管理文件系统和数据，也需要对新硬盘进行分区和格式化。

引导加载器的必要性：引导加载器对于系统启动至关重要，无论您是否关心可移植性。即使在不涉及EFI系统分区（比如在传统的BIOS启动模式下），也需要有某种形式的引导加载器来启动操作系统。但是，如果新硬盘不用于启动系统，那么在新硬盘上设置引导加载器确实不是必须的。

对于我的情况来说，如果在引导加载器中，将根文件系统设备路径从 /dev/mmcblk0p1 变更为 /dev/nvme0n1p1 ，意味着系统将会从新的设备 /dev/nvme0n1p1 启动。

那么，作为这个过程的一部分，需要将原来位于 /dev/mmcblk0p1 上的根文件系统完整地复制到新的设备 /dev/nvme0n1p1 上。这个操作通常涉及到以下几个步骤：分区，格式化，复制根文件系统，更新引导加载器。

但下面老机器的 /boot/extlinux下的extlinux.config文件，可以看到老机器并没有将新盘作为启动盘。所以结论是“老机器纯扩容”

TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 pcie_aspm=off console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4

# When testing a custom kernel, it is recommended that you create a backup of
# the original kernel and add a new entry to this file so that the device can
# fallback to the original kernel. To do this:
#
# 1, Make a backup of the original kernel
#      sudo cp /boot/Image /boot/Image.backup
#
# 2, Copy your custom kernel into /boot/Image
#
# 3, Uncomment below menu setting lines for the original kernel
#
# 4, Reboot

# LABEL backup
#    MENU LABEL backup kernel
#    LINUX /boot/Image.backup
#    INITRD /boot/initrd
#    APPEND ${cbootargs}