Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 116511 - Exception at end of install: Operation not permitted: '/dev/null'
Summary: Exception at end of install: Operation not permitted: '/dev/null'
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
URL:
Whiteboard:
: 116973 119326 (view as bug list)
Depends On:
Blocks: FC2Blocker
TreeView+ depends on / blocked
 
Reported: 2004-02-22 04:10 UTC by Brian Stretch
Modified: 2007-11-30 22:10 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-07-12 22:03:19 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Brian Stretch 2004-02-22 04:10:42 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
Gecko/20040206 Firefox/0.8

Description of problem:
After all the rpm's have been installed,
anaconda says:

Traceback
...
/usr/bin/anaconda, line 1126, in ? intf.run(id,dispatch,configFileData)
/usr/bin/anaconda/text.py, line 474, in run dispatch.gotoNext()
/usr/bin/anaconda/dispatch.py, line 168, gotoNext self.moveStep()
/usr/bin/anaconda/dispatch.py, line 236, moveStep rc = apply(func,
self.bindArgs(args))
/usr/bin/anaconda/packages.py, line 1091, doPostInstall devnull =
os.open("/dev/null", os.O_RDRW)
OSError: [Errno 1] Operation not permitted: '/dev/null'

Oddly enough, this same line is in anaconda-9.90 that
shipped with FC2 Test 1 and 9.2 in FC1 Release. 
Something interesting has changed somewhere else?  

I mirrored the x86_64 devel tree binaries and ran
/usr/lib/anaconda-runtime/genhdlist --withnumbers --productpath Fedora
/home/stretch/fedora64
from my 32-bit FC1 machine then made an .iso, burned a DVD, and
installed from that.  I tried without doing genhdlist and that failed
to find all the RPMs.  Anyhow, reserve the possibility that I goofed
something up if no one else can duplicate this. 

Version-Release number of selected component (if applicable):
anaconda-9.91-0.20040219213330

How reproducible:
Didn't try


Additional info:
Comment 1 Brian Stretch 2004-02-24 03:29:20 UTC 
I updated to today's devel tree, burned a DVD-RW, and this time the
install finished, but when I rebooted and got past grub I got:

kernel /boot/vmlinuz-2.6.3-1.97 ro root=/dev/hda1 rhgb quiet

Error 15: File not found

Press any key to continue...

Which kicked me back to grub.  I created /, /linux32 (unused), and
/home partitions, formatting the / partition.  The HD is dedicated to
Fedora Linux.
Comment 2 Brian Stretch 2004-02-24 19:40:52 UTC 
Installing from today's tree reintroduced the /dev/null anaconda
exception.  Or maybe it doesn't happen on every install? 

In addition, just before the RPMs start installing, I get a whole
bunch of errors like these:

/etc/security/selinux/src/policy/file_contexts/file_contexts:
invalid context system_u:object_r:zebra_log_t on line number 1590
Comment 3 Jeremy Katz 2004-02-26 23:38:20 UTC 
*** Bug 116973 has been marked as a duplicate of this bug. ***
Comment 8 Mike McLean 2004-03-29 20:59:12 UTC 
*** Bug 119326 has been marked as a duplicate of this bug. ***
Comment 9 Mike McLean 2004-03-29 21:02:55 UTC 
Sometimes the traceback looks like this instead.  (Note same place,
but slightly different OSError accessing /dev/null).

Traceback (most recent call last):
  File "/usr/bin/anaconda", line 1126, in ?
    intf.run(id, dispatch, configFileData)
  File
"/usr/src/build/381370-x86_64/install//usr/lib/anaconda/text.py", line
475, in run
  File
"/usr/src/build/381370-x86_64/install//usr/lib/anaconda/dispatch.py",
line 169, in gotoNext
  File
"/usr/src/build/381370-x86_64/install//usr/lib/anaconda/dispatch.py",
line 237, in moveStep
  File
"/usr/src/build/381370-x86_64/install//usr/lib/anaconda/packages.py",
line 1093, in doPostInstall
OSError: [Errno 5] Input/output error: '/dev/null'
Comment 12 Jeremy Katz 2004-03-30 23:05:42 UTC 
These messages

<4>inode_doinit_with_dentry:  getxattr returned 5 for dev=ram0 ino=35
<4>inode_doinit_with_dentry:  getxattr returned 5 for dev=ram0 ino=29
<4>inode_doinit_with_dentry:  getxattr returned 5 for dev=ram0 ino=66

really make me want to point at the kernel.  At kernel folks have any
ideas?
Comment 13 James Morris 2004-03-31 02:10:11 UTC 
Is this reproducible always in the lab?
Comment 14 Bill Peck 2004-03-31 04:31:07 UTC 
yes.
Comment 15 Stephen Tweedie 2004-03-31 10:37:25 UTC 
What fs is mounted on ram0 at the time when those warnings appear?
Comment 16 Dave Jones 2004-03-31 12:37:27 UTC 
ah, those warnings also appear in the crash I saw in bug 119447 
(also amd64). dupe ?
Comment 17 James Morris 2004-03-31 13:14:34 UTC 
I wonder if this has something to do with the security initcalls.  Is
it possible for someone to post a log of all the kernel messages from
boot until the getxattr messages?
Comment 18 James Morris 2004-03-31 15:06:23 UTC 
Is this only seen on ia32e?
Comment 23 Stephen Smalley 2004-04-01 13:15:13 UTC 
From the syslog sent to me by James, I see an error from
init_special_inode, then attempts to access beyond the end of the
device (which we used to see with vanilla 2.4 before its logic for
detecting fast symlinks was updated, so that it thought that a fast
symlink with EAs was actually a slow symlink), then inode_doinit
complaining that getxattr is returning EIO.  Problem with using EAs
and ramdisks?  Why not mount the ramdisk with context= option to
disable use of EAs?
Comment 27 Jeremy Katz 2004-04-11 16:49:34 UTC 
The ramdisk is being mounted by the kernel (it's the initrd), so I
can't very well control how it's mounted :-)
Comment 28 Brian Stretch 2004-04-19 00:32:05 UTC 
Well, this is odd.  My Athlon 64 3200+ notebook (1GB RAM, nForce3
chipset, GeForce 440 video) installs fine, but my Athlon 64 3200+
desktop (1GB RAM, VIA chipset, GeForce FX 5700 Ultra video) gets these
errors with textmode installs, graphical installs, with and without
swap partitions.  Both systems were doing NFS installs.  The notebook
dual boots and uses one big / partition, the desktop has a drive
dedicated to Linux and has separate / and /home partitions.  Hmm...
AHA!!!!!!!

Using one big / partition on the desktop works.  So, for whatever
strange/odd/demented reason, FC doesn't like multiple partitions?
Comment 29 Brian Stretch 2004-04-20 01:51:03 UTC 
Or maybe it didn't like the 70+ GB /home partition?  I haven't tested
multiple smaller partitions yet.
Comment 30 Brian Stretch 2004-04-26 04:58:18 UTC 
I just did a clean install with the April 25th 2004 devel tree and it
works!  So, problem solved?
Comment 38 James Morris 2004-06-10 18:13:37 UTC 
Looks like this is resolved.
Comment 39 Mike McLean 2004-07-12 22:03:19 UTC 
I haven't seem this since May. Closing.
Comment 40 Jonas Lindemann 2004-09-24 11:11:36 UTC 
We have the iso:s for Fedora Core 2 x86_64 (Opteron 148) and got
exactly the same behavior, so I think the bug still exists. At least
in the available iso-images at the fedora mirrors.

To reproduce:

Install with 1Gb swap and one big 79 Gb / filesystem fails
Install with 1Gb swap, 20 Gb / and 59 Gb /disk/local or /home works

System fails in both the graphical install and in the text install.
Comment 41 Robert Guthals 2005-01-29 01:10:35 UTC 
I've also encountered this same failure, installing to a 200GB IDE
hard drive.  Install attempt with 200MB for /boot, 1GB for swap, & the
rest for / the install fails just after formating the partitions. 
Splitting the same drive up into /boot / /usr /var /home & swap and no
issues with the install.  x86_64 CPU with 512MB RAM, FC2.
Note You need to log in before you can comment on or make changes to this bug.