From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5
Description of problem:
I am installing on an Athlon 800, with a QDI Kinetiz 7T motherboard (KT133 chipset) with 512MB of RAM. The machine previously had Red Hat Linux 9 on it, which installed without incident. I'm installing Fedora 0.94 from an NFS share (containing the isos), and just after partitioning with Disk Druid, I'm told that because my system is low on memory, I need to commit the partitioning now, so swap can be used. This didn't happen with the RHL9 installer, installing in the same fashion (isos on an NFS share). I'm guessing that 512MB didn't suddenly become "low" for the installer. :)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot off a CD burned from the boot.iso file found on disc 1
2. Choose NFS install from a server containing the isos
3. Perform a fresh install
Expected Results: Everything should have proceeded without the need for swap initialization...
The memory is in the form of a matched pair of PC-133 256MB DIMMs, the hard drives are four 4.5GB UW SCSI, connected to an Adaptec 2940UW.
Did anaconda report how much RAM it thought your system had?
No, it did not. I didn't think to hit ctrl-alt-F[2-5] to look until it was too late to see if it the amount
detected showed up there or not. I haven't done much of anything on the system yet, so I'll just go
ahead and try starting over from scratch.
Okay, I just started off another install. Exact same message comes up just after I finish laying out
partitions and hit next. It doesn't say how much memory was actually detected, but if I hit ctrl-alt-F3,
the console output shows these two lines:
* Detected 512M of memory
* Swap attempt of 512M to 1024M
Those are surrounded by a a bunch of "moving to step X" messages. So I guess the memory is being
properly detected... But I haven't a clue why the installer would claim there isn't enough. At least this
rules out improper memory detection as the problem. Let me know if you'd like me to do anything else.
Are there any large files in /tmp or /tmp/ramfs?
There are no large files in /tmp, and /tmp/ramfs does not exist. However, this is a few days after the
installation. Did you mean at install time?
The /tmp filesystem is a RAM resident filesystem, so we deduct the size of the
files in /tmp at detection time from the total RAM available. At the time you
get the warning switch to VC2 and 'ls -l' around /tmp and /tmp/ramfs and see if
there is a huge log file, for example.
So yes, you did mean at install time... Alas, there's nothing over even a megabyte in either /tmp or /
tmp/ramfs at install time. But I've now had each of 4 new install attempts result in the "you don't have
enough memory to install without enabling swap even though your have 512MB" message.
For giggles, I'm going to try the same install method with Taroon tomorrow...
For the record, I don't have the problem when doing an NFS-based install of Taroon.
Does this problem still exist with test3?
I was just about to try that... (Drum-roll, please!)
Okay, tried it. Same thing still happens. No files bigger than a few hundred K in /tmp, only one 28K file
Can you provide /proc/e820info and /proc/meminfo from the installer?
Also, the output of
`PYTHONPATH=/usr/lib/anaconda python -c "import iutil; print
iutil.memInstalled(), iutil.memAvailable()"` would be helpful
Okay, sorry for the delay...
First, there is no /proc/e820info at install time.
The contents of /proc/meminfo are:
# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 527527936 151781376 375746560 0 17547264 91860992
Swap: 0 0 0
MemTotal: 515164 kB
MemFree: 366940 kB
MemShared: 0 kB
Buffers: 17136 kB
Cached: 89708 kB
SwapCached: 0 kB
Active: 25796 kB
Inactive: 104524 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 515164 kB
LowFree: 366940 kB
SwapTotal: 0 kB
SwapFree: 0 kB
As far as the results of the python iutil section go, I must be doing something wrong. When I try it
at install time (just after the "not enough memory" message comes up), I get:
-bin/sh: 515164: command not found
I just attempted an identical installation on a completely different system (Athlon XP 1800, MSI KM2M
Combo-L motherboard, 512MB DDR RAM, 40GB ATA/100 hard drive), and got the exact same error
message about not having enough memory...
Something I have NOT tried is booting off CD1 (instead of a CD generated from the boot.iso image on
CD1) to see if it behaves the same when I try 'linux askmethod' and spec NFS.
One other thing I haven't tried is installing on an Intel proc system, though I do have one or two I could
try on, if it would help at all.
Are you including the backticks when you run the python command? If so, leave
them off (I just use them to offset what to run)
Oops. Yes, I was including the backticks. My mistake. Re-running the command, sans-backticks, results
in the output:
Hmmm, so the amount of RAM detected is definitely right. But then finding the
size of /tmp screws up.
Can you do 'ls -lR /tmp | tee /tmp/ls.out' and then copy /tmp/ls.out to a floppy
and attach it? I'm looking at that code and seeing no way that it could get
this confused :/
Also, just checking that `PYTHONPATH=/usr/lib/anaconda python -c "import iutil;
print iutil.getDirSize('/tmp')"` returns something really large (in the range of
600,000 or so) would be helpful.
Created attachment 95366 [details]
Output from 'ls -lR /tmp | tee /tmp/ls.out'
Okay, the output file has been attached to the bug (side-note: Apple's Safari
does NOT work at all well w/Bugzilla, but it could be my settings...). Also, I
have no floppy drive, but scp works fine to move the file. :)
And the results of the iutil.getDirSize('/tmp') command are as you suggested, in
the 600,000 range (668,197 to be exact).
Aha, I see what's going on now.
Now, for the harder problem of fixing it :)
Cool. Care to share a brief bit on exactly what's going on? My only guess is
that it has something to do with the package tree getting counted as taking up
space in RAM, even though they're on an NFS mount. Am I even in the right
Yep, that's exactly what it is. Attaching an updates.img that should be usable
for fixing it. You can either dd it into a floppy or place it as updates.img in
the same directory as the isos on your NFS server. Thanks for the cooperation
in tracking this down.
Created attachment 95368 [details]
updates.img to fix
Hey, I guessed right?!? I just dropped the updates.img file onto my NFS server,
kicked off a new install, and everything is gravy. No more complaints about not
enough memory. Cool, glad I could help out.
I deem this bug squashed! =]