Ubiquity in Kubuntu gets killed by out-of-memory with 256 MB RAM

Raising severity as it prohibits installation on any machine without Linux swap partition (i.e. majority of Windows users) and with less than about 300 MB of RAM.

Possible solutions:
1. Create swap file on Windows partition (currently not possible as NTFS module is compiled without write support) or normal swap partition upon startup if there is space on disk.
2. Use text-mode Ubiquity for such machines (I was told Guidalinex had it).

There is no such thing as text-mode Ubiquity, I'm afraid. Memory-constrained machines should use the text-mode install CD we provide.

1.Install CD AFAIK will not be distributed using ShipIt.
2. I wouldn't call computer with 256 MB memory-constrained. It is well enough to run Ubuntu/Kubuntu in normal conditions, not to mention that even Windows XP works well in such case. And it is only installation-time constraint, not run-time constraint.

1: correct.

2: I'm not arguing that the memory constraint here is too high - it most certainly is - but I think the desktop environment is at fault for a lot of that, not Ubiquity. I'm pretty sure that Ubiquity by itself is not particularly memory-hungry.

According to my tests, my laptop is short in memory about 50 MB during installation. Before installation it has almost 100 MB free (i.e. cached) memory.
During install, right before freeze, last app shown by "top" using most of memory is localedef, second - ubiquity, third - debconf-communi.

So it is not only ubiquity, but some other tools which it is running. I am wondering, why they are run anyway. I think information such as list of locales, timezones, etc. can be generated at the time of generation of Live CD, not during installation.

And going back to Ubiquity. Maybe the solution would be to have boot-time option "Installation for <256 MB RAM", which would spawn only X-server with Ubiquity, instead of whole desktop?

I will try to run such scenario to see how much memory it will use.

I have killed initial X-server and run Ubiquity using:
sudo xinit /usr/bin/ubiquity

It installed fine, though at one point localedef had 50 MB of RSS.
I will try now with 128 MB.

With 128 MB X-server froze before Ubiquitu even showed up.

I have installed Ubuntu beta2 on 256MB qemu image. On 128MB image I can't even start it.

OK first up you can test with arbitray memory sizes by using the kernel's mem= parameter.

Secondly, Krzysztof: what do you expect to happen when this occurs? Do you expect a warning on those systems with 256Mbyte or less RAM and no swap before the installation proceeds? What about the fact that the VSS now plays a large role because it can't be swapped out? Other distros like Fedora stipulate the minimum requirements for a graphical install as being 192MiB - http://fedora.redhat.com/docs/release-notes/fc5/release-notes-ISO/#id3099264 but I think all of them say you have to have swap during the install if your RAM is that constrained.

Thirdly: I know someone who said it was like having a new machine when he moved to 512Mbytes on Windows XP. It definitely runs but these days its easy to make it thrash the swap. Also, I don't think Windows XP would be so happy on a 256Mbyte machine if you took its swap file away.

The swap file can be an issue. I always test ubiquity on fresh machines, i.e. no partitions at all. So expecting some swap/windows partition may not be valid in the "new machine/new hard drive" use case.

To Ante Karamatić:
> I have installed Ubuntu beta2 on 256MB qemu image.
> On 128MB image I can't even start it.

1. Have you tried installing with non-English locale?
2. Can you try with 240MB? This is what is left on some laptops after reserving 16 MB of memory for graphics card.

To Sitsofe Wheeler:
> Other distros like Fedora stipulate the minimum
> requirements for a graphical install as being 192MiB -
> but I think all of them say you have to have swap during
> the install if your RAM is that constrained.

I expect the system to be installable on any sensible machine and I don't really care if it will be using text mode or graphical installer. If graphical installer is so memory consuming, then there should be text-mode installer also available.

> Also, I don't think Windows XP would be so happy on
> a 256Mbyte machine if you took its swap file away.

Yes, but my problem is LiveCD, not Windows XP. If it requires swap to install, then there should be tools to make that swap file/swap partition.

Krzysztof Lichota:
> 2. Can you try with 240MB? This is what is left on some laptops after reserving 16 MB of memory for graphics card.

Please, count 224. For instance, ATI IXP 400 doesn't work with less than 32 MB in ubuntu. There's a bug on it, but it doesn't matter here. Just that you have to count on even less memory than you expect.

It worked with croatian locale. I'll try with 220MB now and report results.

With 220MB it takes ages, but it works. 'free' shows that swap is used (which was created during install).

Ante, the problem is that in fresh machines, even this swap will not be available. I have no kubuntu to test this condition, unfortunately.

As I said, swap was created during install (i.e. this was installation on empty QEMU disk).

I've made a few small improvements to ubiquity process memory use in my bzr branch. My next target is to stop debconf loading all the translations it doesn't need.

OK, I had a look at the size of the debconf-communicate process, and in fact there isn't much we can do about that in the short term. While at first glance it seems profligate for debconf to load all translations into memory even though it isn't going to use most of them, debconf doesn't know when it starts up that it isn't going to have to write out a changed template database due to e.g. the REGISTER command, so it needs to load the whole database in order to ensure that it doesn't lose anything if it needs to save it later.

In theory this could be fixed by mmap()ing the database and just storing pointers, and that's on the roadmap for cdebconf (which we may start using for Ubiquity in Edgy), but it's far too invasive to try to do this in debconf. We'll have to live with this 12MB in Dapper.

Aha, I've got it. It turns out that debconf looks at LANGUAGE in the environment as well as running setlocale(), so if we simply set LANGUAGE correctly there's no need to run locale-gen at all! We get a few perl warnings (which I could suppress with PERL_BADLANG=1 if I felt so inclined), but that's all.

localechooser (0.27ubuntu19) dapper; urgency=low

  * Stop running locale-gen on live CDs and in oem-config when changing
    language. localedef is extremely memory-hungry, and it turns out that
    it's possible to get correct debconf translations (which is all we
    actually care about) by setting LANGUAGE instead (closes: Malone
    #43071).

 -- Colin Watson <email address hidden> Fri, 12 May 2006 15:20:23 +0100

ubiquity (0.99.79) dapper; urgency=low

  * Defend against progress_title being None in debconf_progress_start
    (closes: Malone #44219).
  * Add Brazilian Portuguese .desktop file translation from Malone #39064.
  * Make translations of "How do you want to partition the disk?" work.
  * Add support for getting translations from debconf questions other than
    ubiquity/text/*, including "New partition size:".
  * Reduce the number of strings we slurp into memory (only grab
    partman-partitioning*, not partman*).
  * Make "Step N of M" string translatable.
  * Set LANGUAGE as well as LANG when changing locale; this allows us to get
    correct debconf translations without needing to run locale-gen (closes:
    Malone #43071).
  * Automatic update of included source packages: localechooser
    0.27ubuntu19.

 -- Colin Watson <email address hidden> Fri, 12 May 2006 15:30:04 +0100

I have tested daily live cd 20060513 (Kubuntu) and I have managed to get up to "choosing mount points" step, without swap. Seems memory usage is OK now. See results of my experiments on page
http://lichota.net/~krzysiek/projects/kubuntu/ubiquity-memory-usage/

For plain Ubuntu the problem is still there.

A few months ago I installed Ubuntu breezy server install
on P166 and while waiting for stuff to get installed it seemed
that almost half of it's time it was spending on re-generating
locales. I haven't re-tested on Dapper, but this could speed
up the installation on slower machines quite a bit too...

now kubuntu dapper daily 18/5 works with 192 mb of ram