Bug#1017720: nfs-common: No such file or directory

[Kenneth C. Schalk]

I've been looking for an explanation for a similar kind of failure.  I
wonder if the core problem is the same as reported here:

https://bugzilla.opensuse.org/show_bug.cgi?id=1209457

Supposedly fixed by the patch posted to linux-nfs here (also attached
after extraction from the SuSE kernel build source RPM):

https://www.spinics.net/lists/linux-nfs/msg86343.html

And merged into the main-line kernel in 5.15.3, see the Changelog here
(specifically under commit "69e0be0efe53fb012f5db32bc328590745cf8f71"):

https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.3

I would be interested to hear whether it makes any difference for the
issue reported in this Debian bug.

--KenFrom 255fc6efacf25d954a986ff058fd9899f322e7d1 Mon Sep 17 00:00:00 2001
From: Trond Myklebust 
Date: Tue, 28 Sep 2021 11:15:53 -0400
Subject: [PATCH] NFS: Don't set NFS_INO_DATA_INVAL_DEFER and NFS_INO_INVALID_DATA
Git-commit: 488796ec1e39fb9194cc8175f770823d40fbf0ed
Patch-mainline: v5.16-rc1
References: stable-5.14.19

[ Upstream commit 488796ec1e39fb9194cc8175f770823d40fbf0ed ]

NFS_INO_DATA_INVAL_DEFER and NFS_INO_INVALID_DATA should be considered
mutually exclusive.

Fixes: 1c341b777501 ("NFS: Add deferred cache invalidation for close-to-open consistency violations")
Signed-off-by: Trond Myklebust 
Tested-by: Benjamin Coddington 
Reviewed-by: Benjamin Coddington 
Signed-off-by: Sasha Levin 
Acked-by: Takashi Iwai 

---
 fs/nfs/inode.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 6ea1bde33cb6..f9d3ad3acf11 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -210,10 +210,15 @@ void nfs_set_cache_invalid(struct inode *inode, unsigned long flags)
 		flags &= ~NFS_INO_INVALID_XATTR;
 	if (flags & NFS_INO_INVALID_DATA)
 		nfs_fscache_invalidate(inode);
-	if (inode->i_mapping->nrpages == 0)
-		flags &= ~(NFS_INO_INVALID_DATA|NFS_INO_DATA_INVAL_DEFER);
 	flags &= ~(NFS_INO_REVAL_PAGECACHE | NFS_INO_REVAL_FORCED);
+
 	nfsi->cache_validity |= flags;
+
+	if (inode->i_mapping->nrpages == 0)
+		nfsi->cache_validity &= ~(NFS_INO_INVALID_DATA |
+	  NFS_INO_DATA_INVAL_DEFER);
+	else if (nfsi->cache_validity & NFS_INO_INVALID_DATA)
+		nfsi->cache_validity &= ~NFS_INO_DATA_INVAL_DEFER;
 }
 EXPORT_SYMBOL_GPL(nfs_set_cache_invalid);
 
-- 
2.26.2

Bug#317285: acknowledged by developer (Re: Bug#317285: initrd-tools: mkinitrd infinite recursion f RAID component device file missing)

[Kenneth C. Schalk]

 indeed that's a possible workaround. well i assume that you are
 using a static /dev tree. in that case makedev handles which devices
 show up in /dev.

 as one can't populate every debian system with all possible devices,
 the maintainer maid a trade-off to cut after 8 discs, which should
 not be noticable for the vast majority.

*I* didn't make any choice about what kind of /dev tree to use.  The
installer did.  I couldn't find any place to select devfs, and I
didn't find any difference between choosing a 2.4 or 2.6 kernel when
starting the installer.

While I agree that it would be impractical to populate a static /dev
tree with all possible devices, it *would* be practical to populate a
static /dev tree with all physical partitions used in RAID devices
configured from the installer's partitioner.

 sure, read the man of MAKEDEV(8) it tells you how to create those
 needed nodes.

I did try that.  However, there's not really an opportunity to create
additional device nodes during a from-scratch install.  I tried
several different ways to do that before the installation of the
kernel-image package, but didn't come up with one that worked.  (Hence
my falling back on the approach of moving the drive for hdi to hda.)

Of course none of this is to do with initrd-tools, however:

 initrd can't possibly work for non existing device nodes.

I'm not suggesting that it should.  However, sitting in infinite
recursion during an install for over an hour with no indication to the
user of either progress or problems is profoundly unhelpful.  (I had
to spend several days figuring out what was going wrong, and many
people would not be capable of debugging this kind of issue.)  To me,
such behavior does not seem acceptable, and I would argue that it is,
in fact, a bug.

This particular problem could be detected and handled at several
different points in the mkinitrd script.  I'm attaching a patch which
shows at least two different ways to avoid this long-running infinite
recursion.

--Ken


mkinitrd.patch
Description: Binary data