[Bug 503779] Re: Support 128MB machines in Ubiquity.

[Seth Arnold]

Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Public Security to Public

** Tags added: karmic

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/503779

Title:
  Support 128MB machines in Ubiquity.

Status in “ubiquity” package in Ubuntu:
  Opinion

Bug description:
  Binary package hint: ubiquity

  We can support 128MB installs from the LiveCD (ubiquity) simply but
  increasing the size of the compcache device on those machines. Since
  this is just a configuration change, I suggest we do this for Lucid.

  Previously, I suggested that we should "Support 256MB machines in
  Ubiquity" by adding compcache (bug #193552). This has been
  implemented. Since then there has also been added an option to the
  boot screen to install Ubuntu without loading the full Gnome
  environment. Using this new option it is possible to install Ubuntu
  using Ubiquity onto 128MB machines if we set the compcache/ramzswap
  device to 128MB.  However setting this manually is difficult and the
  user should not be expected to know what a compcache is.

  I propose that we automatically set the compcache to 100% or 128MB of
  ram for machines with less than 200MB of ram when booting straight
  into ubiquity. This should allow Ubiquity installs to "just work" on
  machines with as little as 128MB of ram.

  I note that:
  1) 128MB machines are still in operation, work quite well with e.g. LXDE.
  2) Compache tends to achieve a 4:1 compression ratio [1], so if the compcache device is the same size as physical ram it will only use up about 25% of ram, so a 100% sized compcache is reasonable.
  3) Even if the primary workload involves filling ram with random data, a 100% compcache device will use significantly less than 100% of memory since filling ram with random data will still cause system processes to be evicted, and these processes will compress well [1].
  4) Despite the above I am not convinced that using 100% sized compcache is a good idea when it is not needed. In principle the compcache device only allocates memory on demand so it is plausible that 100% compcache would improve performance. However the back-of-an-envelope benchmark [1] I performed suggested that using more than 50% compcache could reduce performance. Until better benchmarks are available, I see little point in switching the default liveCD compcache size to 100% (50% may be a good idea since it helps prevent OOM kills and doesn't seem to harm performance, but there isn't a compelling argument to switch to 50% unless it is needed to prevent OOM kills messing up the primary functions of the LiveCD.)

  [1]  http://code.google.com/p/compcache/wiki/Eeepc701

  ProblemType: Bug
  Architecture: i386
  CheckboxSubmission: 404bd18599e0899eb2769ef0d7f6c695
  CheckboxSystem: 6944d89cd962d3dec0d4098e584fb8ff
  Date: Wed Jan  6 20:28:11 2010
  DistroRelease: Ubuntu 9.10
  Package: ubiquity (not installed)
  ProcEnviron:
   SHELL=/bin/bash
   PATH=(custom, user)
   LANG=en_AU.UTF-8
  ProcVersionSignature: Ubuntu 2.6.31-16.52-generic
  SourcePackage: ubiquity
  Tags:  ubuntu-unr
  Uname: Linux 2.6.31-16-generic i686
  XsessionErrors:
   (gnome-settings-daemon:2210): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
   (gnome-settings-daemon:2210): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
   (nautilus:2398): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
   (polkit-gnome-authentication-agent-1:2437): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/503779/+subscriptions