Bug 116511 - Exception at end of install: Operation not permitted: '/dev/null'
Exception at end of install: Operation not permitted: '/dev/null'
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
: 116973 119326 (view as bug list)
Depends On:
Blocks: FC2Blocker
  Show dependency treegraph
 
Reported: 2004-02-21 23:10 EST by Brian Stretch
Modified: 2007-11-30 17:10 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-07-12 18:03:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brian Stretch 2004-02-21 23:10:42 EST
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-23 22:29:20 EST
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 14:40:52 EST
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 18:38:20 EST
*** Bug 116973 has been marked as a duplicate of this bug. ***
Comment 8 Mike McLean 2004-03-29 15:59:12 EST
*** Bug 119326 has been marked as a duplicate of this bug. ***
Comment 9 Mike McLean 2004-03-29 16:02:55 EST
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 18:05:42 EST
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-30 21:10:11 EST
Is this reproducible always in the lab? 
Comment 14 Bill Peck 2004-03-30 23:31:07 EST
yes.
Comment 15 Stephen Tweedie 2004-03-31 05:37:25 EST
What fs is mounted on ram0 at the time when those warnings appear? 
Comment 16 Dave Jones 2004-03-31 07:37:27 EST
ah, those warnings also appear in the crash I saw in bug 119447 
(also amd64). dupe ?
Comment 17 James Morris 2004-03-31 08:14:34 EST
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 10:06:23 EST
Is this only seen on ia32e?

Comment 23 Stephen Smalley 2004-04-01 08:15:13 EST
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 12:49:34 EDT
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-18 20:32:05 EDT
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-19 21:51:03 EDT
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 00:58:18 EDT
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 14:13:37 EDT
Looks like this is resolved.
Comment 39 Mike McLean 2004-07-12 18:03:19 EDT
I haven't seem this since May. Closing.
Comment 40 Jonas Lindemann 2004-09-24 07:11:36 EDT
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-28 20:10:35 EST
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.