Description of problem: Fedora 15 Live artificially refuses to install to disk on a computer or virtual machine with only 256MB RAM, but installs fine with 2. simple workarounds. Workaround 1. Disable memory check in /usr/sbin/anaconda script changing a line "needed_ram = int((isys.MIN_RAM + extra_ram) / 1024)" to "needed_ram = 0" Workaround 2. Enable swap after start of "Copying Live image to disk", as it is disabled by anaconda right before this stage: - after "Copying Live image to disk" stage starts, run Terminal, and run command: "su -c 'swapon /dev/sda2'" (replace /dev/sda2 with correct swap partition device). The second workaround was not needed on 512MB virtual machine. Version-Release number of selected component (if applicable): anaconda-15.31-1.fc15.i686 How reproducible: Always Steps to Reproduce: 1. fallocate -l 10G Fedora-15.img 2. nice -15 qemu-kvm -m 256 \ -hda Fedora-15.img -cdrom Fedora-15-i686-Live-Games.iso \ -boot order=d 3. Applications -> System Tools -> Install to hard drive Actual results: Fedora requires 640MB of memory to install, but you only have 256MB on this machine. Expected results: Fedora should install just fine, as all it needs to do is to copy a filesystem image to disk. Additional info: Using this 2 workarounds I was able to install Fedora Live Games i686 to 256MB virtual machine, start it and play some Gwelled. It wasn't very fast but usable. Please: - allow for ignoring this "requires 640MB of memory" message or disable it completely for Live installs; - do not disable swap before "Copying live image to disk" stage. This bug is related to but not a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=682555 as that bug is about ordinary install, not Live.
Did you try this with logical volumes on the target disk?
This gives a traceback: 1. $ qemu-kvm -m 512 -cdrom Fedora-15-x86_64-Live-Desktop.iso -hda ../f15-test1.img -boot menu=on 2. Boot from the cdrom. 3. $ su 4. # swapoff -a 5. # fdisk /dev/sda 6. Delete all partitions and write changes to disk. 7. Edit /usr/sbin/anaconda to set "needed_ram = 0". 8. Install to disk and choose default, full-disk partitioning. 9. Write changes to disk ... a traceback occurs. With 640 MB and an unmodified /usr/sbin/anaconda, the partitioning succeeds, and ultimately it is possible to login to the gnome desktop.
Then there must be a big difference between 32 and 64 bit Fedora. I've downloaded Fedora-15-i686-Live-Desktop.iso and it almost installed itself with "Use All Space" install to 256MB VM - it hung on "Performing post-instalation filesystem changes." but it did not use swap, which could be used as soon as partitions/volumes were created. It was turned on for a second just before start of "Copying live image" stage as I saw watching "while sleep 1; do free; done" in terminal during installation. When I issued "lvchange -a y /dev/VolGroup/lv_swap; swapon /dev/VolGroup/lv_swap" during "Copying live image to hard drive" stage then it installed itself and then booted successfully on 256MB. On 384MB/i686 it installed without even manually turning on swap. Anaconda needs to have "I'm Feeling Lucky (Punk)!" checkbox. With prominent warning that if it fails then a system would not be bootable.
(In reply to comment #3) > Then there must be a big difference between 32 and 64 bit Fedora. ... Thanks for your report. With the DVDs, the 64-bit version requires more memory than the 32-bit version.[1] However, the problem was that the Live CD activates logical volumes, and I was deleting the partitions containing them -- not a good idea ... :-) Here is a more reliable test procedure: 1. $ rm f15-test1.img 2. $ qemu-img create f15-test1.img 12G 3. $ qemu-kvm -m 496 -cdrom Fedora-15-x86_64-Live-Desktop.iso -hda f15-test1.img -boot menu=on 4. Edit /usr/sbin/anaconda to set "needed_ram = 0". 5. Install to disk and choose default, full-disk partitioning ("Use All Space"). With 496 MB, the install completes, and it is possible to boot to the gnome desktop. With 384 MB, the install hangs at "Performing post-installation filesystem changes." So in summary, the 64-bit Live CD install requires more memory than the 32-bit Live CD install. In both cases, the required memory is less than 640 MB. [1] Bug 696805, Comment 7. Bug 696805, Comment 8.
(In reply to comment #4) > 2. $ qemu-img create f15-test1.img 12G "fallocate -l 12G f15-test1.img" is as fast but resulting image should be much faster, as it would allocate space for image in small number of fragments. But only ext4, xfs and btrfs support fast fallocate: http://log.amitshah.net/2009/04/re-comparing-file-systems.html
(In reply to comment #5) > (In reply to comment #4) > > 2. $ qemu-img create f15-test1.img 12G > > "fallocate -l 12G f15-test1.img" is as fast but resulting image should be much > faster, as it would allocate space for image in small number of fragments. But > only ext4, xfs and btrfs support fast fallocate: > http://log.amitshah.net/2009/04/re-comparing-file-systems.html Thanks for the tip. qemu-img calls ftruncate. On ext4: $ ls -ls *.img 12582916 -rw-r--r--. 1 stephent stephent 12884901888 Jun 3 01:30 x-fallocate.img 0 -rw-r--r--. 1 stephent stephent 12884901888 Jun 3 01:30 x-qemu-img.img > "while sleep 1; do free; done" $ watch -n 1 free -o With 384 MB, "top" shows the hang occurs while depmod is running. "tail -f /var/log/messages" does not show any kernel out of memory messages. With a "top" delay of 1 second, I haven't seen swap enabled. $ qemu-kvm -m 384 -cdrom Fedora-15-x86_64-Live-Desktop.iso -hda f15-test1.img -boot menu=on
(In reply to comment #6) > With a "top" delay of 1 second, I haven't seen swap enabled. As it is enabled for a moment and then disabled right away with a fast computer you may not see it. With "while sleep 1; do free; done" it is easier to spot, as it is visible for several seconds on screen, and you can also scroll if it moved up too much. I think the problem is that the logic in FSSet.umountFilesystems in /usr/lib/python2.7/site-packages/pyanaconda/storage/__init__.py is wrong: for device in devices: if not device.format.mountable and \ (device.format.type != "swap" or swapoff): continue device.format.teardown() device.teardown() I have trouble following it. I think it should be something like: for device in devices: if device.format.type == "swap" and not swapoff: continue elif not device.format.mountable: continue device.format.teardown() device.teardown() Which is much more clear what it does. When I made this change anaconda did not disable swap before copying live image.
(In reply to comment #7) > ... With "while sleep 1; do free; done" it is easier to spot, ... OK, thanks. That works much better. Swap is enabled for only two successive iterations. Nice work tracking down the unmounting logic. The logic changed between F10 and F11: http://git.fedorahosted.org/git?p=anaconda.git;a=blob;f=fsset.py;hb=refs/heads/f10-branch#l2107 http://git.fedorahosted.org/git?p=anaconda.git;a=blob;f=storage/__init__.py;hb=refs/heads/f11-branch#l1735
This may have been what was intended: for device in devices: if not (device.format.mountable and \ (device.format.type != "swap" or swapoff)): continue device.format.teardown() device.teardown() The conditional expression is logically equivalent to: not device.format.mountable or device.format.type == "swap" and not swapoff
I really think that the best form would be: for device in devices: device_needs_unmount = None if device.format.type != "swap": device_needs_unmount = device.format.mountable else: device_needs_unmount = swapoff if ( device_needs_unmount ): device.format.teardown() device.teardown() This is not the most optimal, but it is much easier to read and understand. It does not need complicated boolean logic and reverse thinking.
When swap support will work I'd suggest to change mem.h based on our testing to something like: #if defined(__powerpc64__) || defined(__sparc__) #define MIN_RAM 1024*1024 // 1 GB #define GUI_INSTALL_EXTRA_RAM 512*1024 // 512 MB #define EARLY_SWAP_RAM 1152 * 1024 // 1152 MB #elif __WORDSIZE == 64 #define MIN_RAM 384 * 1024 // 384 MB #define GUI_INSTALL_EXTRA_RAM 0 * 1024 // 0 MB #define EARLY_SWAP_RAM 768 * 1024 // 768 MB #else #define MIN_RAM 256 * 1024 // 256 MB #define GUI_INSTALL_EXTRA_RAM 0 * 1024 // 0 MB #define EARLY_SWAP_RAM 512 * 1024 // 512 MB #endif
Thanks for tracking down the swap problem. I've submitted a patch to the list after testing it out with live and DVD install isos.
(In reply to comment #12) > Thanks for tracking down the swap problem. I've submitted a patch to the list > after testing it out with live and DVD install isos. Thanks, Brian. Fix up swap unmount logic (#708966) swap was always being unmounted, even when swapoff == False http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=481578486c0beb2772ad5a17dae04b72734a4c1f
Posted another patch to add a nomemcheck / --nomemcheck flag that will let the install continue in low memory situations.
(In reply to comment #14) > Posted another patch to add a nomemcheck / --nomemcheck flag that will let the > install continue in low memory situations. Awesome! That will simplify memory-requirement testing ...
Has anyone tested F16 yet ?
I (In reply to comment #16) > Has anyone tested F16 yet ? I did test beta 32bit XFCE LiveCD. - "liveinst --nomemcheck" did not work. - In "qemu-kvm -m 256" it started, but it was too slow to run installer. - In "qemu-kvm -m 384" it was fairy responsive, and after changing "needed_ram = 0" in "/usr/sbin/anaconda" it did install with defaults (which means LVM and that it created itself a swap partition) on 384MB RAM. - After installation it run very well from disk image in "qemu-kvm -m 256". I was able to browse the web with Firefox - available swap helped much.
--nomemcheck patch was not acked so it is not supported in Anaconda.
It would be nice if there was a way to do a clean install of F16 (even a minimal one) before F14 goes EOL. I'm not clear on what this workaround entails. Is it possible to do this with an existing live image (the 16.RC1 Live KDE ISO still tells me that it requires 768M to install)? Or is it necessary to build a new ISO with the workaround built in? And if so, are there any plans to make images available so naive users (such as myself) could do a clean install with low memory (512M or less), without having to figure out how to apply the workaround?
It doesn't look like this will happen for F16. Doing a yum upgrade might be a reasonable option right now. However it does look like rawhide might be able to install on machines with only 256 MB soon. See: https://www.redhat.com/archives/anaconda-devel-list/2011-October/msg00114.html
It is possible to apply workaround with existing live image of Fedora 16 beta: 1. Start a computer from a standard i686 Live CD. 2. Run Terminal 3. Run "su -" to become root 4. Use your favorite editor to edit "/usr/sbin/anaconda" (there's for example vi and gedit on LiveCD, you can "yum install" any other) 5. Find "needed_ram" 6. Change "needed_ram = [some_number]" to "needed_ram = 0" 7. Save your changes 8. Close Terminal 9. Run "Install to disk"
Thanks, this works fine. I did a test install using Fedora-16-i686-Live-Desktop.iso in a VM with 500M RAM, then on my F14 PC with 512M. I was confused by not realizing that /usr/sbin/anaconda was just a plain text file accessible while the system is running Live.
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
anaconda team, would you like us (QA) to do some real-world testing of how much RAM is actually needed to install F17 once all the RAM-usage-reduction stuff has landed, or are you planning to take care of that? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #13) > Fix up swap unmount logic (#708966) > swap was always being unmounted, even when swapoff == False > http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=481578486c0beb2772ad5a17dae04b72734a4c1f Actually it doesn't work anymore. The devicetree._populate function tears down all devices at the end and the swap too.
I did a successful install of f17 beta rc1 onto a machine with only 512MB of memory. (After changing the anaconda as described in comment 21.)
anaconda 17.14 has added --no-memcheck to skip the check.
How can you pass that when using DVD/netinst? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
inst.no-memcheck=1 works for me.
I've tried to install F17 Beta Gold from 32-bit installation DVD on VM with 256MB of memory. All went well almost to the end and crashed after trying to make a grub2 bootable partition. BTW anaconda 17.20 has different parameter to turn off memory check - inst.nomemcheck=1 (note the missing hyphen).
Power on the computer, Once at the desktop, Open Terminal Type "su -" to enter root Type "gedit /usr/sbin/anaconda" to open anaconda in a text editor Go to search, find, type "needed_ram" the 1st line you see, from top down, its about half way down the page, Change "needed_ram = 1024" to "needed_ram = 5024" (I don't know why, but lowing the number, did not bypass me, making it higher did, if making it higher does not work, please try editing it again as a lower number) Save the text Type "/usr/sbin/anaconda" in Terminal The setup should start now, if it don't, (pops up with a message saying you don't have the ram needed, then change the number to something else till it does work, I got to the end of the install on nothing more than 512mb of ram, I needed a swap part, as that made extra ram, I used this Bypass on Fedora beta 17, I don't think there should be a limit, on anything, so i ask everyone at Fedora, to change this, and maybe show a message telling the user, the hardware there using is not supported, or ram to low, but will still install, if user wants to, Thank you for reading my message, and I hope this helps many people out of this mess, really, it is a mess, and needs changing, hear your commonalty
It seems like we have enough data to support lowering the limit to at least 512MB. At minimum, bcl, can you do that for the next anaconda build? we can try adn schedule some testing to see if it should be lowered to 384. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
anaconda-17.25-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/anaconda-17.25-1.fc17
anaconda-17.25-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
This is just ridiculous. I'm able to run Fedora 18 DVD in rescue mode on just 128 MB and it was said that 512 MB is required!
the check is for a likely minimum to *perform an installation*, not use rescue mode. if you want to argue that the check shouldn't apply to rescue mode, that's a separate bug.
Point taken. I opened the new report for rescue mode. But my point is that the new anaconda is working reasonably well with much less memory. I just successfully installed F18 32-bit DVD with just 256 MB memory and all defaults. I don't know at the moment if this limit could be made even less.