Bug 59847

Summary: rpm reports "failed to stat /proc/bus/usb" on installation or installation test
Product: [Retired] Red Hat Linux Reporter: Alexander Stohr <alexander.stohr>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED WORKSFORME QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-02-14 12:51:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alexander Stohr 2002-02-13 20:52:09 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (Win95; U)

Description of problem:
when running with a kernel that does not have the subdir /proc/bus/usb 
then rpm does check and report an error on exactly this specific file when an install
or a test install is done. The complete error message is:
"error: failed to stat /proc/bus/usb: No such file or directory"

Its not clear why the simple RPM package which was used 
should finally require the mentioned proc entry for USB bus.
The whole testing was done in a chroot environment,
that worked nice despite exactly that single problem.

Version-Release number of selected component (if applicable):
RPM version 4.0.3

How reproducible:
Always

Steps to Reproduce:
1. start with a kernel that does not provide any USB support
2. run rpm on some package with "-i" or with "-i --test --nodeps"
3. watch the output on the commandline
	

Actual Results:  installation or check is supposed to complete, 
but the error return value is not zero and the printed information
indicates an error as well.

Expected Results:  rpm should not return an error.

Additional info:

the problem is more critical since the error might happen
whilst i.e. an rpm manager program is running and thus
the desired action might never be caried out. Instead the
user gets beaten with non reasonable error messages.

Comment 1 Jeff Johnson 2002-02-13 20:54:11 UTC
This is probably a packaging, not an rpm, problem.

What package were you trying to install? Kernel?

Were you installing into a chroot or otherwise unusual environment?

Comment 2 Alexander Stohr 2002-02-13 21:04:09 UTC
package is selfmade but contains only a few binaries, X11 modules and shell scritps.
thre is really no relevance to USB bus by design. The package is derived from another
spec file that is some 24 months old. The main change are just the filenames and one 
subdir name of the contained files.

its a chroot environment, a second harddisk with with a nearly original RedHat 7.2 system.
The only thing is that the running kernel and the related proc filesystem do not provide
USB support and thus not entry /proc/bus/usb.

If in doubt , i can provide the RPM - but its most likely  related to the missing kernel feature.
Any hints on how i should analyze the package for determining its dependencys better?

Comment 3 Jeff Johnson 2002-02-13 21:11:02 UTC
I suspect that the problem is in you spec file. Check for
actions that require /proc mounted (even in a chroot) in
the packages %post et al scriptlets.

rpm itself does not care whether /proc is mounted or not.

Comment 4 Alexander Stohr 2002-02-14 12:51:18 UTC
The origin of the problem was an invalid entry in /etc/mtab.
Due to the nature of a chroot execution a few of the system
files are taken from the embedded environment.

After manually deleting the usb line in the file
two further lines did fault (one of them was for /dev/cdrom).

I feel like its a bit odd if rpm is forced to check any mounted devices
before it is allowed to continue. It might be nice to ensure systems
sanity when there is intention for using specific resources, but
if i cant disable such check i think its no good. 

At least when i just want to check the integrity of an rpm package 
by applying "-i --test --nodep" i would prefer beeing able to ignore
the initial testing of /etc/mtab because its doing "stat"s on things
that have nothing to do with my target.

I am not gone to the source code of rpm so far, there are better
people around for doing this. Anyways, i consider the root cause
to be tracked down now - its a combination of system setup and
a specific insane(?) habit of the rpm executeables initialisation code.

Comment 5 Jeff Johnson 2002-02-24 17:21:51 UTC
OK, this looks like WORKSFORME to me.

Comment 6 Alexander Stohr 2003-04-28 13:08:32 UTC
Okay, that looks like RPM is INSANE to me. ;-)