Bug 972547

Created attachment 759031 [details]
screenshots of various ttys

The attached screenshot showing Anaconda running out of memory. Not only that it shows loop1 and loop0 reniced to -20 which explains anaconda freezing. I understand that this is probably done to make netinstalls download faster but it freezes anaconda as anaconda has a nice priority of 0. 

The nice priorities are unrelated as the system runs out of RAM, has no swap and crashes.

I don't know why you're so hung up on the nice levels, but I can reproduce the behaviour in a netinstall (but not a DVD install). I wouldn't call it a blocker, though. A minimum specification is a *minimum*, it doesn't mean we guarantee that all installation attempts with 512MB of memory will succeed.

My tty4 shows anaconda being killed for OOM at around 75 seconds.

Note that a *text* network install works fine; anaconda's interface uses rather a lot less RAM in text mode.

Discussed at 2013-06-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-10/f19final-blocker-review-4.2013-06-10-16.01.log.txt . Agreed that this is not accepted as a blocker. The 512MB listing in the documentation and hard floors in anaconda code (we can make the minimum for text and graphical different if we choose to) is not a guarantee that any installation attempt with that much RAM will work, but an absolute low-end on what amount of memory is needed before _any_ install attempt can reasonably be expected to work. As a graphical DVD install works with 512MB of system RAM (assuming swap is made available during partitioning), it doesn't seem a good idea to bump the hard floor above that number.

However, I'm setting the release notes flag so that if the 512MB graphical net install failure isn't fixed prior to release, it can be documented: roughly "We know graphical network install with 512MB of system RAM is likely to fail, use text mode if you want to do a network install or DVD or live image if you want to do a graphical install, or get more RAM".

Proposing as "NTH"?

Well, FE for what? anaconda devs don't seem to think there's any code changes needed here.

If you mean FE for actually 'fixing' anaconda to be able to do a network install in 512MB, sure, I'd be +1 for that. I'm not sure if it's going to be practical to pull sufficient RAM savings out prior to Final, though.

Boot a machine with 256MB in text mode. Anaconda actually TELLS YOU the minimum is 512MB to install.

"If you mean FE for actually 'fixing' anaconda to be able to do a network install in 512MB, sure, I'd be +1 for that. I'm not sure if it's going to be practical to pull sufficient RAM savings out prior to Final, though"

Yes

9: yes, and no-one thinks that's a particular problem. we have several examples of 512MB installs that succeed - including all text installs anyone's tried - and one case that fails, graphical network install. so what's wrong with saying 512MB is the minimum, exactly?

(In reply to Adam Williamson from comment #11)
> what's wrong with saying 512MB is the minimum, exactly?

It's inaccurate and misleading and wrong.

Thanks for flagging this, Adam. Given that our documentation roughly targets the default installation, and that installer memory requirements are subjective and incidental, I'm documenting a "Recommended minimum" rather than an absolute floor.  There's also a note about using less than recommended. You can read it here:  https://git.fedorahosted.org/cgit/docs/release-notes.git/plain/en-US/Hardware_Overview.xml?h=f19

Created attachment 759677 [details]
virtio serial log

The full debug output from a configured virtio char device for anaconda logging. Compressed due to upload limit.

Hope it helps, 
--Pete

(In reply to Pete Travis from comment #13)
> Thanks for flagging this, Adam. Given that our documentation roughly targets
> the default installation, and that installer memory requirements are
> subjective and incidental, I'm documenting a "Recommended minimum" rather
> than an absolute floor.  There's also a note about using less than
> recommended. You can read it here: 
> https://git.fedorahosted.org/cgit/docs/release-notes.git/plain/en-US/
> Hardware_Overview.xml?h=f19

A recommended minimum is 768 to install with the netinstall (because it has to download packages). It's kind of annoying because after installation the system uses less than 512MB, and you would think text mode would lower those requirements. TBQH they could be avoided if it didnt download the entire gnome package dependency list probably. A minimal install in text mode should be able to install on a 512MB machine or even 256MB for that matter with the net install.

On the DVD this is a non issue with 512MB of RAM because, well Anaconda isn't busy downloading things.

Dan: I think you're getting rather confused.

Once package installation starts, anaconda has access to the swap space that was created during partitioning. If we assume autopart, that would be 1GB of swap, so total available memory becomes 1.5GB.

I can do a full netinst in text mode with a 512MB VM perfectly fine. The *only case we have found that demonstrably fails* is a graphical net install with 512MB of system RAM, because it exhausts the available RAM before reaching partitioning and hence having swap space available. All other tested cases - graphical DVD install with 512MB, text net install with 512MB - work.

Pete: the text there sounds fine to me, even a tad conservative if anything (I think we tweaked it to talk about '768MB' back at f17 or f18 or whichever release it is where we set the graphical floor to 768MB).

Dan: er, to further clarify things, at the pre-install hub, anaconda is not downloading packages. The difference between DVD and netinst is that it has to retrieve the mirror list and repo metadata remotely rather than having them locally. It's this that pushes the memory usage over the top.

Discussed at 2013-06-12 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-12/f19final-blocker-review-5.2013-06-12-16.01.log.txt . As there's no indication anaconda team is working on reducing, or believes it possible to reduce, memory consumption at this point of installation to below 512MB, and it's agreed there's no need to change the code-specified RAM floors, there's no need to make this a freeze exception issue, and so it's rejected. Anaconda team, if in fact you want to land a change to improve memory usage and think it's safe and appropriate for F19, please re-propose.

er, additional to the above, bcl mentions that vpodzime is working on a fix that may save some 20MB in the language code. vratislav, if you get that done and the fix seems safe for F19, can you provide an updates.img so we can test if that's enough to make a 512MB graphical net install fly? Thanks.

(In reply to Adam Williamson from comment #17)
> Dan: er, to further clarify things, at the pre-install hub, anaconda is not
> downloading packages. The difference between DVD and netinst is that it has
> to retrieve the mirror list and repo metadata remotely rather than having
> them locally. It's this that pushes the memory usage over the top.

The downloading of the metadata causes Anaconda to freeze for almost 2 minutes (depending on connection speed).

This usually occurs after about a minute after Anaconda is started. What I'm saying here is let the user configure everything except software selection first and then do this part.

This will provide a better user experience by not freezing in some random spoke while the loop processes run.

That has nothing to do with this bug, then, and I think is reported in another bug already.

(In reply to Adam Williamson from comment #19)
> er, additional to the above, bcl mentions that vpodzime is working on a fix
> that may save some 20MB in the language code. vratislav, if you get that
> done and the fix seems safe for F19, can you provide an updates.img so we
> can test if that's enough to make a 512MB graphical net install fly? Thanks.

OK. I hope that this helps. If not we could definitely shoot for basic graphics or even text mode.

After an installation of MATE I am using ~256MB RAM or less. Without X or a MATE session running it's less than 200.

For the seventy-sixth time, that's entirely irrelevant. A desktop is an entirely different thing from a system installer. Not to mention you can't actually *do* anything from a bare desktop. Run Firefox and see where it goes. If anaconda just painted a background and a clock it'd use a lot less memory too.

There's no reason 'basic graphics' mode's memory usage would be different from a regular graphical install, really, the only difference is the video driver.

I saw this doing a minimal graphical netinstall on bare metal with 512 MiB. It did complete package installation, then spun its wheels for a long time. Anaconda eventually died but I was able to get to VT2 and create a user account, set the root password, create an /etc/default/grub file (which was not created, even though grub2-tools was installed properly), and run grub2-install and grub2-mkconfig. The resulting system seems fine. (I needed a graphical install in order to do custom partitioning.)

taking myself off the cc list, hence the email being sent out

*** Bug 984308 has been marked as a duplicate of this bug. ***