Red Hat Bugzilla – Bug 116511
Exception at end of install: Operation not permitted: '/dev/null'
Last modified: 2007-11-30 17:10:37 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
Description of problem:
After all the rpm's have been installed,
/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,
/usr/bin/anaconda/packages.py, line 1091, doPostInstall devnull =
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
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):
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
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:
invalid context system_u:object_r:zebra_log_t on line number 1590
*** Bug 116973 has been marked as a duplicate of this bug. ***
*** Bug 119326 has been marked as a duplicate of this bug. ***
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)
475, in run
line 169, in gotoNext
line 237, in moveStep
line 1093, in doPostInstall
OSError: [Errno 5] Input/output error: '/dev/null'
<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
Is this reproducible always in the lab?
What fs is mounted on ram0 at the time when those warnings appear?
ah, those warnings also appear in the crash I saw in bug 119447
(also amd64). dupe ?
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?
Is this only seen on ia32e?
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?
The ramdisk is being mounted by the kernel (it's the initrd), so I
can't very well control how it's mounted :-)
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...
Using one big / partition on the desktop works. So, for whatever
strange/odd/demented reason, FC doesn't like multiple partitions?
Or maybe it didn't like the 70+ GB /home partition? I haven't tested
multiple smaller partitions yet.
I just did a clean install with the April 25th 2004 devel tree and it
works! So, problem solved?
Looks like this is resolved.
I haven't seem this since May. Closing.
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.
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.
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.