为什么 overlayroot 无法与 RPi4 上的网络启动 NFS 根正常配合使用?

为什么 overlayroot 无法与 RPi4 上的网络启动 NFS 根正常配合使用?

这个问题没有引起太多兴趣(也没有解决方案):这可能是因为它不仅仅是一个关于 Ubuntu 的问题,而且也没有足够的文档。因此,我对其进行了广泛的重新表述,并将其重新发布在超级用户

我可以使用网络启动和 NFS 从我的 Synology NAS 在 Raspberry Pi 4 上启动 20.04。但是,我想在多个 Pi 上共享操作系统,因此我尝试启用一个覆盖文件系统,以只读方式挂载 NFS 共享。据说这不是什么火箭科学,对我来说几乎是可行的。但还不完全是。

启动后许多服务不可用。systemctl --failed显示以下内容:

  UNIT                      LOAD   ACTIVE SUB    DESCRIPTION                   
● atd.service               loaded failed failed Deferred execution scheduler  
● avahi-daemon.service      loaded failed failed Avahi mDNS/DNS-SD Stack       
● systemd-networkd.service  loaded failed failed Network Service               
● systemd-resolved.service  loaded failed failed Network Name Resolution       
● systemd-timesyncd.service loaded failed failed Network Time Synchronization  
● systemd-networkd.socket   loaded failed failed Network Service Netlink Socket

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

6 loaded units listed.

我怀疑其中有一个错误systemd-networkd.service,它会对其他服务产生连锁反应。

我尝试手动启动这些服务,但都失败了,最终出现消息不支持该操作互联网搜索揭露其他类似案件,尽管尚未解决。

我使用overlayroot并已设置overlayroot="tmpfs:recurse=0"。系统显示 的内容如下df -k

Filesystem                                    1K-blocks     Used  Available Use% Mounted on
udev                                             896804        0     896804   0% /dev
tmpfs                                            189252     3024     186228   2% /run
192.168.8.20:/volume3/pxe/nfs/RPi4-Ubuntu/OS 3840789888 15323392 3825347712   1% /media/root-ro
tmpfs-root                                       946248    20972     925276   3% /media/root-rw
overlayroot                                      946248    20972     925276   3% /
tmpfs                                            946248        0     946248   0% /dev/shm
tmpfs                                              5120        0       5120   0% /run/lock
tmpfs                                            946248        0     946248   0% /sys/fs/cgroup
/dev/sda1                                      30057428   156608   28350948   1% /data
tmpfs                                            946248        0     946248   0% /tmp
tmpfs                                            946248        0     946248   0% /var/tmp
tmpfs                                            189248        0     189248   0% /run/user/0

overlayroot做自己的事情也是如此。

我注意到 NFS 根目录挂载的是 NFS 版本 3。我尝试强制使用版本 4,认为这可能会解决问题,但我的 Pi 和 Synology 在网络启动期间只会使用 NFSv3 进行通信。添加vers=4nfsvers=4只会v4引起cmdline.txtPi 对无效版本或未知选项的抱怨。

圆周率机器启动后,使用 NFSv4 安装 NFS 共享。不过,我怀疑 NFSv4 可能只是个幌子。

显然,根文件系统的某些部分无法访问。有人知道原因吗?

答案1

虽然花了很长时间才找到答案,但答案相对简单。

如果您在 RPi4 上使用 NFS 网络启动 Ubuntu,则nfsmount随附的klibc(由 Ubuntu 提供)仅支持 NFS v2 和 v3。如果您代替使用nfsmount支持 NFSv4 的系统并且您的根文件系统已成功由 NFSv4 挂载,则overlayroot可以正常工作。

剧透:它是一个上游(即 Debian)漏洞自 2007 年起就存在了。重复:2007 年。

答案2

根本问题似乎是在某些 NFS 服务器配置中行为不正确。也就是说,在未实现 NFSv3 导出的服务器上使用overlayfs时,会出现问题overlayfsv3 的可选 NFSACL 协议扩展. 看起来像这样并不是唯一一个overlayfs在 ACL 方面非常脆弱的情况显然,v3 和 v4 NFS 都存在(仍然存在?)问题。

我能够将问题简化为不涉及启动的问题,而只需 overlayfs 和 NFS 导出。使用从 Ubuntu 机器(确实实现了 NFSACLv3)提供的 Ubuntu 映像的 NFS 导出以及其中带有/tmp/overlaygames/空的upperworkoverlay目录的目录,以下脚本将运行而不会出错:

#!/bin/bash
sudo mount -t nfs -o ro,vers=3 10.99.0.1:/srv/nfs/ubuntu-20.04.3 /media/nfs/
sudo mount -t overlay -o lowerdir=/media/nfs,upperdir=/tmp/overlaygames/upper,workdir=/tmp/overlaygames/workdir/ overlay /tmp/overlaygames/overlay
ls /tmp/overlaygames/overlay/home

运行该脚本后,运行此脚本来卸载并清理:

#!/bin/bash
pushd /tmp/overlaygames
sudo umount overlay
rm -rf workdir
mkdir workdir
sudo umount /media/nfs
popd

现在运行完全相同的脚本,但使用 noacl 选项禁用 NFSACLv3 客户端:

#!/bin/bash
sudo mount -t nfs -o ro,noacl,vers=3 10.99.0.1:/srv/nfs/ubuntu-20.04.3 /media/nfs/
sudo mount -t overlay -o lowerdir=/media/nfs,upperdir=/tmp/overlaygames/upper,workdir=/tmp/overlaygames/workdir/ overlay /tmp/overlaygames/overlay
ls /tmp/overlaygames/overlay/home

将回归熟悉的

ls: cannot open directory '/tmp/overlaygames/overlay/home': Operation not supported

同样,从第一个脚本开始但将 NFS 导出放在 FreeNAS/TrueNAS(FreeBSD)机器上,也会返回,Operation not supported因为 FreeBSD 没有实现 NFSACLv3(通过捕获数据包验证)。

有趣的是,在 FreeBSD 上使用 NFS 共享时指定vers=2似乎工作得很好。当然,与 NFSv3 相比,NFSv2 有一些限制。

相关内容