Bug 116511
| Summary: | Exception at end of install: Operation not permitted: '/dev/null' | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Brian Stretch <bstretch> |
| Component: | anaconda | Assignee: | Jeremy Katz <katzj> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | bpeck, davej, dwalsh, jmorris, lockhart, mikem, sct, sdsmall |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-07-12 22:03:19 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 114961 | ||
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. 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 *** 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)
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'
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? Is this reproducible always in the lab? yes. 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... AHA!!!!!!! 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. 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. 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. |
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: