Hide Forgot
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): How reproducible: Didn't try 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... Additional info: 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 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! =]