这个问题没有引起太多兴趣(也没有解决方案):这可能是因为它不仅仅是一个关于 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=4
或nfsvers=4
只会v4
引起cmdline.txt
Pi 对无效版本或未知选项的抱怨。
圆周率能机器启动后,使用 NFSv4 安装 NFS 共享。不过,我怀疑 NFSv4 可能只是个幌子。
显然,根文件系统的某些部分无法访问。有人知道原因吗?
答案1
答案2
根本问题似乎是在某些 NFS 服务器配置中行为不正确。也就是说,在未实现 NFSv3 导出的服务器上使用overlayfs
时,会出现问题overlayfs
v3 的可选 NFSACL 协议扩展. 看起来像这样并不是唯一一个overlayfs
在 ACL 方面非常脆弱的情况。显然,v3 和 v4 NFS 都存在(仍然存在?)问题。
我能够将问题简化为不涉及启动的问题,而只需 overlayfs 和 NFS 导出。使用从 Ubuntu 机器(确实实现了 NFSACLv3)提供的 Ubuntu 映像的 NFS 导出以及其中带有/tmp/overlaygames/
空的upper
、work
和overlay
目录的目录,以下脚本将运行而不会出错:
#!/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 有一些限制。