On Wed, Oct 20, 2021 at 9:49 AM Carl Karsten <carl@xxxxxxxxxxxxxxxx> wrote: > > On Wed, Oct 20, 2021 at 12:42 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > On Tue, Oct 19, 2021 at 10:49 PM Carl Karsten <carl@xxxxxxxxxxxxxxxx> wrote: > > > > > > I am sure this worked once, then I rebooted and now something .... > > > > Are you saying it is a regression? From which kernel? > > Not a regression - just something that I am sure was OK on my box, > then 20 min later the 'same thing' is causing problems. We all know > it isn't the same, but this is what has me scratching my head. > > > > > > > > > root@negk:/srv/nfs/rpi/root# mount -v -t overlay -o nfs_export=on > > > overlay -olowerdir=img,upperdir=upper,workdir=work merged > > > mount: /srv/nfs/rpi/root/merged: mount(2) system call failed: Stale file handle. > > > > > > > What are lower and upper? > > img was > /dev/mapper/loop2p2 on /srv/nfs/rpi/buster/root/img type ext4 (rw,relatime) > > > cat /proc/self/mountinfo please > > sorry, I've reinstalled the os and I'm not having this problem any more. > > > If you happen to be using squashfs for lower fs, there were a bunch > > of changes and fixes in recent kernels. > > no squashfs > > > > > > # this works: > > > root@negk:/srv/nfs/rpi/root# mount -v -t overlay -o nfs_export=off > > > overlay -olowerdir=img,upperdir=upper,workdir=work merged > > > mount: overlay mounted on /srv/nfs/rpi/root/merged. > > > root@negk:/srv/nfs/rpi/root# umount merged > > > > > > # syslog: > > > > > > [ 80.317697] overlayfs: failed to verify origin (root/img, > > > ino=2374476, err=-116) > > > [ 80.317703] overlayfs: failed to verify upper root origin > > > > > > # no help: > > > systemctl disable nfs-server.service > > > reboot > > > root@negk:/srv/nfs/rpi/root# systemctl status nfs-server.service > > > ● nfs-server.service - NFS server and services > > > Loaded: loaded (/lib/systemd/system/nfs-server.service; disabled; > > > vendor preset: enabled) > > > Active: inactive (dead) > > > > > > > The error has nothing to do with NFS. > > The staleness is that of the root/img directory. > > Overlayfs believes that someone has replaced the original > > root/img directory with another directory on the same name > > but a different file handle. > > > > the only difference between error and no error was > > nfs_export=off / on > > Which is mostly why I posted - this little detail seemed odd. This is intentional as the documentation commit clarifies. You are allowed to re-create lower dir when not enabling index or nfs_export which implies index=on. You are not allowed to re-create lower dir when using new features. Specifically, index and nfs_export features simply cannot work with re-created lower. Read about this in overlay documentation. > > > Did you re-create the lower image filesystem/subtree? > > maybe. I'm futzing around with this pi image file trying to figure > out how to manage various flavors of modifications. . > I was hoping the lowest level would be the fs in the .img file, but > there isn't a nice way to deal with the loop devices, so I'll copy the > files onto the base ext5 fs and get on with things. > When you copy lower layer, you need to re-create an empty upper dir you cannot mount an old upper dir with new lowerdir when nfs_export is enabled. > At the moment my little sysadmin project has lots of moving parts that > are not at all reliable, it's hard to tell what is and isn't working. > robust is the goal, I'm getting there. > Good luck. Thanks, Amir.
