Support 128MB machines in Ubiquity.

Bug #503779 reported by John McCabe-Dansted
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Opinion
Undecided
Unassigned

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

description: updated
tags: removed: i386 ubuntu-unr
Changed in ubiquity (Ubuntu):
status: New → Opinion
Revision history for this message
Taowa (taowa4-deactivatedaccount) wrote :

There is not actually a bug however it is still a good idea so I marked it as opinion.

information type: Public → Private Security
information type: Private Security → Public Security
Revision history for this message
Seth Arnold (seth-arnold) wrote : Bug is not a security issue

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: Public Security → Public
tags: added: karmic
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.