I guess the question i have here is... is /mnt being *USED* within the install at all, OTHER than by being an empty sub within the tarchive payload in the .deb ? Does dpkg, etc use /mnt for temporary extraction or as part of the postinstall infrastructure? Because if it doesn't -- making sure it's not in base-files .deb would solve my problem.
I don't recall other packages having this blocking issue, but i could not swear to that. Anyway, i appreciate you looking at the issue, but if indeed, /mnt is a core component of debian's installation infrastructure (which i could argue is a security flaw in the design, as that directory hierarchy gets littered with automount garbage), then i will concede on the bug report, and you can close it, and i will re-iterate to my fellow sysadmins to not use it for temporary mounts anymore. (if you could please respond definitively that /mnt is indeed a core component/requirement of Debian's package management, i'd appreciate it) thanks, again, --stephen On Thu, Oct 9, 2014 at 9:00 PM, Guillem Jover <guil...@debian.org> wrote: > 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 -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu - http://www.ral.ucar.edu/~sdowdy/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
