Bug 105643

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 
in /tmp/ramfs.

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:

515160 -152984

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
ballpark? ;p

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! =]