This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 708966 - Fedora 16 Live refuses to install to disk on 384MB RAM, but installs fine with a simple workaround
Fedora 16 Live refuses to install to disk on 384MB RAM, but installs fine wit...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
16
i686 Linux
unspecified Severity low
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-30 05:44 EDT by Tomasz Ostrowski
Modified: 2016-03-27 10:31 EDT (History)
18 users (show)

See Also:
Fixed In Version: anaconda-17.25-1.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-26 12:31:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Tomasz Ostrowski 2011-05-30 05:44:03 EDT
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.
Comment 1 Steve Tyler 2011-05-30 15:48:11 EDT
Did you try this with logical volumes on the target disk?
Comment 2 Steve Tyler 2011-05-30 16:43:50 EDT
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.
Comment 3 Tomasz Ostrowski 2011-06-02 09:08:42 EDT
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.
Comment 4 Steve Tyler 2011-06-02 18:27:03 EDT
(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.
Comment 5 Tomasz Ostrowski 2011-06-03 02:56:09 EDT
(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
Comment 6 Steve Tyler 2011-06-03 05:40:32 EDT
(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
Comment 7 Tomasz Ostrowski 2011-06-03 06:50:06 EDT
(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.
Comment 8 Steve Tyler 2011-06-03 09:30:36 EDT
(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
Comment 9 Steve Tyler 2011-06-03 10:03:24 EDT
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
Comment 10 Tomasz Ostrowski 2011-06-03 11:52:23 EDT
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.
Comment 11 Tomasz Ostrowski 2011-06-03 12:15:44 EDT
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
Comment 12 Brian Lane 2011-06-03 12:33:28 EDT
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.
Comment 13 Steve Tyler 2011-06-03 13:34:23 EDT
(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
Comment 14 Brian Lane 2011-06-03 14:53:13 EDT
Posted another patch to add a nomemcheck / --nomemcheck flag that will let the install continue in low memory situations.
Comment 15 Steve Tyler 2011-06-03 15:21:12 EDT
(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 ...
Comment 16 Patrick Dubois 2011-08-26 11:29:54 EDT
Has anyone tested F16 yet ?
Comment 17 Tomasz Ostrowski 2011-10-10 11:24:33 EDT
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.
Comment 18 Brian Lane 2011-10-10 13:21:07 EDT
--nomemcheck patch was not acked so it is not supported in Anaconda.
Comment 19 Andre Robatino 2011-10-29 22:00:09 EDT
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?
Comment 20 Bruno Wolff III 2011-10-29 23:06:29 EDT
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
Comment 21 Tomasz Ostrowski 2011-10-30 06:18:28 EDT
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"
Comment 22 Andre Robatino 2011-11-04 17:26:33 EDT
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.
Comment 23 d. johnson 2011-11-05 17:08:47 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 24 Adam Williamson 2011-12-05 17:27:13 EST
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
Comment 25 vvs 2012-02-22 08:35:56 EST
(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.
Comment 26 Bruno Wolff III 2012-03-24 13:18:28 EDT
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.)
Comment 27 Brian Lane 2012-03-26 12:31:23 EDT
anaconda 17.14 has added --no-memcheck to skip the check.
Comment 28 Adam Williamson 2012-03-27 16:24:13 EDT
How can you pass that when using DVD/netinst?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 29 vvs 2012-04-06 07:54:57 EDT
inst.no-memcheck=1 works for me.
Comment 30 vvs 2012-04-12 06:30:20 EDT
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).
Comment 31 SignedAdam 2012-05-03 02:02:12 EDT
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
Comment 32 Adam Williamson 2012-05-04 09:35:48 EDT
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
Comment 33 Fedora Update System 2012-05-04 18:59:41 EDT
anaconda-17.25-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/anaconda-17.25-1.fc17
Comment 34 Fedora Update System 2012-05-08 00:17:59 EDT
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.
Comment 35 vvs 2013-01-15 07:38:03 EST
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!
Comment 36 Adam Williamson 2013-01-15 13:35:04 EST
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.
Comment 37 vvs 2013-01-16 07:33:12 EST
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.

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