Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 159242 - error: failed to stat proc: No such file or directory
Summary: error: failed to stat proc: No such file or directory
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rpm
Version: 4.0
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-31 20:15 UTC by Aleksandar Milivojevic
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-31 20:25:40 UTC


Attachments (Terms of Use)

Description Aleksandar Milivojevic 2005-05-31 20:15:52 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050523 CentOS/1.0.4-1.4.1.centos4 Firefox/1.0.4

Description of problem:
Not reproducible every time.  On one machine I'm getting this error message
when running "rpm -i", on another practically identical machine everything
if fine.

# rpm -i somepackage-1.2.3.rpm
error: failed to stat proc: No such file or directory
# rpm -q somepackage
somepackage-1.2.3

strace output indicates "missing slash" is to blame:

===== 8< Cut Here 8< =====
22484 open("/etc/mtab", O_RDONLY|O_LARGEFILE) = 4
22484 futex(0x5b41d4, FUTEX_WAKE, 2147483647) = 0
22484 fstat64(4, {st_mode=S_IFREG|0644, st_size=454, ...}) = 0
22484 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c3b000
22484 read(4, "/dev/mapper/sys-root / ext3 rw,n"..., 4096) = 454
22484 stat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
22484 stat64("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
22484 stat64("/sys", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
22484 stat64("/dev/pts", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
22484 stat64("/proc/bus/usb", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
22484 stat64("/boot", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
22484 stat64("/dev/shm", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=40, ...}) = 0
22484 stat64("/srv", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
22484 stat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
22484 stat64("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=60, ...}) = 0
22484 stat64("/proc/sys/fs/binfmt_misc", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
22484 stat64("proc", 0xbffb9170)        = -1 ENOENT (No such file or directory)
===== 8< Cut Here 8< =====

I guess the last stat64() call should have been stat64("/proc", ...)

Not a big problem, since it seems everything works correctly.

Version-Release number of selected component (if applicable):
rpm-4.3.3-7_nonptl

How reproducible:
Sometimes

Steps to Reproduce:
1. rpm -i somepackage.rpm


Additional info:

Comment 1 Aleksandar Milivojevic 2005-05-31 20:25:40 UTC
Sorry, my bad.  I just realized another sysadmin was playing with putting Apache
into chroot, and did something like "mount -t proc proc /blah/blah/proc", which
probably generated bogus entry in /etc/mtab file.


Note You need to log in before you can comment on or make changes to this bug.