Bug 124029 - Anaconda crashes on doPostInstall with /dev/null Input/output error
Anaconda crashes on doPostInstall with /dev/null Input/output error
Status: CLOSED DUPLICATE of bug 119447
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
2
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
: 124030 132255 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-22 20:48 EDT by Dag Wieers
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 14:03:35 EST
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 Dag Wieers 2004-05-22 20:48:37 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040510 Galeon/1.3.14

Description of problem:
After installing Fedora Core 2, when packages are done. I get the
following error with Anaconda:

  Traceback (most recent call last):
    File "/usr/lib/anaconda/gui.py", line 1048, in handleRenderCallback
      self.currentWindow.renderCallback()
    File "/usr/lib/anaconda/iw/progress_gui.py", line 242, in
renderCallback
      self.intf.icw.nextClicked()
    File "/usr/lib/anaconda/gui.py", line 763, in nextClicked
      self.dispatch.gotoNext()
    File "/usr/lib/anaconda/dispatch.py", line 169, in gotoNext
      self.moveStep()
    File "/usr/lib/anaconda/dispatch.py", line 237, in moveStep
      rc = apply(func, self.bindArgs(args))
    File "/usr/lib/anaconda/packages.py", line 1125, in doPostInstall
      devnull = os.open("/dev/null", os.O_RDWR)
  OSError: [Errno 5] Input/output error: '/dev/null'

This is on a x86_64 system with a custom package selection. I'm now
going to try the default installation.

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


How reproducible:
Always

Steps to Reproduce:
1. ...
2.
3.
    

Additional info:
Comment 1 Dag Wieers 2004-05-22 20:52:13 EDT
Now knowing if this is relevant to this problem, but it seems serious
enough to report. After installation on tty4 the screen is filled with
following messages:

<6>attempt to access beyond end of device
<6>ram0: rw=0, want=4262982920, limit=32768
<3>Buffer I/O error on device ram0, logical block 2131491459
<6>attempt to access beyond end of device
<6>ram0: rw=0, want=5401674258, limit=32768
<3>Buffer I/O error on device ram0, logical block 2700837128
....
Comment 2 Dag Wieers 2004-05-22 21:13:05 EDT
A defaul installation results in the same problem. A "ls -la
/dev/null" results in a "ls: /dev/null: Input/output error". The same
output in tty4.

It may be related to the problem reported in bugzilla #122215, where,
although my 2 disks are configured in RAID1, Linux still allows to use
them as sda/sdb.
Comment 3 Dag Wieers 2004-05-23 13:45:31 EDT
*** Bug 124030 has been marked as a duplicate of this bug. ***
Comment 4 Dag Wieers 2004-05-23 20:51:24 EDT
After another test, I noticed the following weirdness:

  # ls -la /dev/tty0
  ?--------- 29797 19629342 5401632          0 Dec 10  2023 /dev/tty0

  # ls -la /dev/tty6
  c-----x-w-    0 8224     129         0,   3 Jan  1  1970 /dev/tty6

  # ls -la /dev/tty8
  ?rwx-----T   82 21044921 5405920          0 Jan  1  1970 /dev/tty8

  # ls -la /dev/ttyS1
  br-s-wS--T 28257 26478    28015      32,  97 Mar 23  1987 /dev/ttyS1

Most of the other files seem correct, only /dev/tty* and /dev/zero
seem to be corrupt.

Doing ls -la in /dev results in lots of devices generating an error, like:

  ls: ./sunmouse: Input/output error
  ls: ./kbd: Input/output error
  ls: ./ptyp0: Input/output error
  ...

for: sunmouse, kbd, ptyp* agpgart, fd*, sg0, st0, random, urandom,
nvram, adb, rtc, fb*, null, ttyS0, ttyS2, openprom, tty5, tty7

The ISO files have a correct md5sum, and the installation works
without any problems (except the post-install). I have tried using
kernel option 'allowcddma' and using less memory than the 1GB provided.

The system worked flawlessly with FC1 (i386) for a couple of months.
Comment 5 Dag Wieers 2004-05-23 21:30:39 EDT
A new attempt using only mem=128M (instead of previous attempts using
mem=512M) ended successful.

The previously mentioned 'attempt to access beyond end of device'
messages for /dev/ram0 did not manifest and /dev/null (and other
devices) were properly defined.

So for some reason using 512M or 1GB of memory corrupts the ramfs driver.
Comment 6 Jeremy Katz 2004-05-23 22:30:24 EDT
Could you run with memtest86+ and see if it shows any problems?
Comment 7 Dag Wieers 2004-05-23 22:44:46 EDT
Yes, I already did that. memtest86+ works without reporting any problems.

The hardware-specs:

  + AMD Athlon 64 3200+ (2Ghz)
  + Abit KV8-MAX3 v1.0
  + 2 SATA disks in RAID1, SiL 3114 chipset
  + 1024GB RAM

Initially the system was unstable, most people with this hardware (and
the v1.0 mainboard) reported this problem. The solution was to run
your DDR 400 memory at 333Mhz, since then the system was rock stable.
Comment 8 Dag Wieers 2004-05-23 22:45:25 EDT
1GB RAM of course.
Comment 9 Vladimir Florinski 2004-06-10 19:48:24 EDT
Confirm same behavior as Dag Wieers reported (error with /dev/null).
AMD Athlon 64FX system, ASUS SK8V motherboard, 1GB RAM, single SATA
hard disk (/dev/hde). Error always reproducable. Messages:

<6>attempt to access beyond end of device
<6>ram0: rw=0, want=8589934592, limit=18432
<3>Buffer I/O error on device ram0, logical block 4294967295
Comment 10 Dag Wieers 2004-06-10 19:53:47 EDT
I have to say that since the successful installation using mem=128M
the system has worked rock-stable. So I doubt the cause is flacky
hardware or memory problems.

Vladimir, could you check if that works for you too ?
Comment 11 Vladimir Florinski 2004-06-10 21:57:41 EDT
128 MB was not enough for a graphic install. Tried with mem=256M and
got it installed finally. Posting this from the new system :)
Comment 12 Pete Stieber 2004-07-09 12:27:28 EDT
There seems to be several bugzilla entries with the same theme.

123564, 123692, 123745, 125874, 127128
125502 and 125198 also seem related

I have been encountering the same problem and you suggestion of 
installing with mem=256M did the trick. The install was much slower. 
This is probably due to less CDROM caching available. I installed 
everything and this install required all 4 FC 2 CDs.

At two different points in the install anaconda reported that a 
package had not been installed and it might be a bad CD, but also 
prompted to hit enter to try again. I hit enter and the retries 
seemed to work. The media passed the verification tests on install 
and I have successfully used the media to install on different HW.

The difference I can note from your configurations is a different MB. 
I am using the following:

MB: Tyan Tomcat K8S(S2850G2N)
Processor: AMD Opteron 146 (2GHz)
RAM: 1 GB
HD: Maxtor 80GB 7200 RPM IDE ULTRA ATA 133

This system also worked flawlessly with FC1 (i386) for a couple of 
months.
Comment 13 Nicholas Ritter 2004-07-09 15:17:59 EDT
I had this same problem with Fedora Core 2 on x86_64. The hardware is 
a Opteron 242 based system on a Tyan S2885 motherboard. I am trying 
the mem=256M option now to see if it fixes it.

What is really odd is that I used the same installation media on the 
same system before and had a flawless install. Despite this, I am now 
having the problem described in this bug and it is happening with 
every install attempt no matter what options I use (e.g. package 
selections, install types, etc.)

One thing to note is that the system install failure is occurring 
during a wipe and reinstall over an previously working FC2 install.



My system details are:

MB: Tyan K8W S2885
Processor: AMD Opteron 242 (1.6GHz)
RAM: 1GB
HD: 2 74GB Western Digital SATA HDs, 1 20GB Seagate Barracuda on the 
EIDE
 
I just tried the mem=256M option for the installer, and the 
installation process worked without a hitch. The installation seemed 
to be a bit slower granted, but at least it didn't error out.

Comment 14 Pete Stieber 2004-07-09 15:37:13 EDT
In addition to the Tyan Tomcat MB I listed in an earlier post, I also 
have a Tyan 2885...

MB: Tyan K8W(S2885ANRF)
Processors: 2 AMD Opteron 244 (1.8GHz)
RAM: 2GB total - 1GB for each processor
HD: Maxtor 160GB 7200 RPM IDE ULTRA ATA 133

I used the same media to install on this machine without a hitch, but 
I thnk this was a full install over a previously working FC1 (not 
FC2) install or on a fresh disk (I can't remember for sure, but I 
would guess the former i.e. over FC2), and I didn't need the mem=256M 
option in this case.

I installed over a FC1 install on the Tomcat MB, but can't remember 
if there was some other problem with the first attempt that lead me 
to try again, so I can't really comment on your "related to 
overwriting a previous FC2 install" guess. I would be willing to 
reinstall FC1 on the box then try FC2 again on the Tomcat box without 
the mem=256M option if someone thought that would help solve the 
problem.

Fortunately for me (unfortunately for the purpose of debugging) the 
2885 is working well for me and I do not want to experiment with this 
productive machine.
Comment 15 Stefan Müller 2004-09-10 07:51:01 EDT
*** Bug 132255 has been marked as a duplicate of this bug. ***
Comment 16 Stefan Müller 2004-09-10 08:48:02 EDT
I have a server with the ASUS SK8V mainboard, AMD Opteron 240 (1.4GHz)
and 1024MB ram (2 modules).

After I read this articles here, i took out one ram module and tried
to install FC2. Finally it worked werry well.
Comment 17 Jeremy Katz 2004-10-07 14:27:33 EDT

*** This bug has been marked as a duplicate of 119447 ***
Comment 18 Red Hat Bugzilla 2006-02-21 14:03:35 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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