Hi! On Thu, 2014-10-09 at 20:55:33 +0200, Santiago Vila wrote: > On Mon, 29 Sep 2014, Stephen Dowdy wrote: > > Package: base-files > > Version: 7.1wheezy6 > > Severity: normal
> > Since sysadmins tend to (and are often told to) use /mnt for > > temporary mounts, and sometimes forget those mounts and they go > > stale (nfs), a package (in this case 'base-files') that includes > > /mnt in the files section will result in a complete failure to > > install. […] > > Preparing to replace base-files 7.1wheezy2 (using > > .../base-files_7.1wheezy6_amd64.deb) ... > > --> Unpacking replacement base-files ... > > dpkg: error processing > > /var/cache/apt/archives/base-files_7.1wheezy6_amd64.deb (--unpack): > > --> unable to stat `./mnt' (which I was about to install): Stale NFS file > > handle > > Errors were encountered while processing: > > /var/cache/apt/archives/base-files_7.1wheezy6_amd64.deb > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > A package failed to install. Trying to recover: > > > > SERVER:~# ls /mnt > > ls: cannot access /mnt: Stale NFS file handle > > (d'oh sysadmin mounted other server months ago, which is now ESTALE, > > but should not result in a fatal install failure in base-files) > > > > SERVER:X# dpkg --fsys-tarfile - > > /var/cache/apt/archives/base-files_7.1wheezy6_amd64.deb | tar tvf - | grep > > /mnt > > --> drwxr-xr-x root/root 0 2014-06-11 21:07 ./mnt/ > > ------------------------------------------------ > > I see the problem, and I see how dropping /mnt from base-files.deb > (and creating it in the postinst) would make the problem to disappear. I'm not sure it would, if this fails for dpkg, I'm expecting this would fail for mkdir or stat or any other programs run from the maintainer script as well. > But I'm not sure that this is a bug in base-files. I don't think it is, neither in dpkg. > Could this be fixed in dpkg, or maybe dpkg has good reasons > to fail in cases like this one? dpkg needs to know what type of object a pathname is, to be able to decide if it needs to replace it or update its metadata, etc. The ESTALE pathname might be just up in the hierarchy, and dpkg might be trying to access somehting lower, say /usr (ESTALE), and dpkg wants to update «/usr/share/doc/pkg/copyright». dpkg cannot know which paths might be mouned on NFS, because any could be. In the end, this is a just a system administration issue. In the same way that a setup might have RO filesystems, that need to be remounted RW before upgrades, this is something that would need to be checked by the sysadmin, or extending the upgrade script elided above. I'm afraid I don't think there's much else to do than close the report. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
