Hello, On Wed, 25 Mar 2009, David C. Rankin wrote:
David Haller wrote:
On Tue, 24 Mar 2009, David C. Rankin wrote:
18:25 zephyr:~> sudo rpm -Uvh --oldpackage http://nirvana/tmp/kdiff3-0.9.92-172.1.i586.rpm Retrieving http://nirvana/tmp/kdiff3-0.9.92-172.1.i586.rpm error: failed to stat /mnt/ripper: No such device or address [..] The error occurs when a mounted smb device is unavailable. The question is "Why the error since this rpm transaction did not involve the unavailable device at all?"
Does /mnt/ripper appear in /proc/mounts? If so, the reason is simply, that rpm does something like a 'df' before installation of a package (reads /proc/mounts and then stats all mountpoints).
You should get the error even with '--test' as rpm will look for space in that case as well.
Yes, it appears in /proc/mounts.
*yay!* Nailed the bugger first try! :)
So I guess what your are saying is that rpm scans /proc/mounts and if it gets an error on df for available space,
Not 'df', but a stat(2) (and more?) which is what df also does, rpm does something _like_ df does. 'rpm' scans /proc/mounts for mounted filesystems, then it stats them all to find out how much space is left on each filesystem, because it HAS to find out ... [*]
even if the mount has nothing to do with the rpm transaction, it still throws the error?
Yes.
That seems like a weird way for rpm to work, but, like it mentioned at the start, rpm does work it's just squawking a little bit.
No. It is very prudent of rpm to look first, [*] if there is enough space for the files in the to be installed package(s). Otherwise, it'd have to install "blindly", handle a "no space left on device", barf an error and then (should?) delete the just installed files -- but wait -- what about the files just previously deleted (you're running an rpm -U, remember) before installing the new package? Where are they now? *ooops* Imagine it being the kernel-package, which is just that much bigger than the previous to fill the partition (/boot/ or /, the modules take a lot of diskspace nowadays ;), so that, say, the kernel itself, or the module for your disk-controller does not fit completely ... Should rpm leave half-installed packages lying in the system? Packages that don't work anyway, because critical files could not be installed? Do you still dislike rpm doing the stat(2) (etc.) on all the filesystems _first_, before actually installing/removing anything? And the error comes (I think) from the 'stat(2)' on the unavailable but (as of /proc/mounts, which is what the Kernel / the OS thinks) "mounted" filesystem itself, not from rpm.
Not worth a bug report. You can just imagine how high the priority would be with the devs.
It's not a bug. It's not even a feature. It's a _neccessary_ safeguard against major screwups! One _could_ argue, that rpm could stat(2) only those filesystems that are to be written to by installing the package, but would you want to program that? Replacing the "oh, what the heck, just stat all mounted filesystems"? You can't just exclude "unavailable" devices. Because, to find out if it's available, you have to stat. And you'd get the error message. You'd have to parse the rpm filelist, see where it'd go on the current devices ... *argh* I wouldn't. As the error-message (just the message) only appears on mounted _and_ unavailable devices anyway, "Bugger off already!" would probably be my reaction ;) -dnh, it is nice to a) see users care about error-messages and b) be able to explain them :) PS: I hope I have got nothing wrong ... *yawn* -- The steady state of disks is full. -- Ken Thompson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org