NAND out of space crash (was Display warnings in sugar (Emiliano Pastorino))
erik at laptop.org
Sat Jul 19 13:39:20 EDT 2008
On Sat, Jul 19, 2008 at 12:58:13PM -0400, Benjamin M. Schwartz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Erik Garrison wrote:
> | On Sat, Jul 19, 2008 at 11:47:21AM -0400, Greg Smith wrote:
> |> Hi All,
> |> Emiliano has an elegant workaround but crashing the XO on NAND full (to
> |> un-recoverable state?) is a heinous bug that affects essentially all users.
> |> If someone has the bug ID handy can you send it out and mark it a
> |> blocker for 8.2.0 (priority = blocker and keyword includes blocks:8.2.0)?
> |> Can I get a design proposal (no re-partitioning please!), scoping and
> |> lead engineer on it ASAP?
> |> If you have to stop working on something else to do this, let me know
> |> what will drop and I'll help weigh the consequences.
> | My impression is that the long-term benefits of partitioning mean that
> | it's worthwhile to devote effort to it. Are we not going to work on
> | partitioning in the future?
> Adding partitioning does not automatically solve the NAND fillup problem.
> ~ The fundamental issue is that Sugar tries to write files on boot, and
> fails to boot if it cannot write those files.
> The correct solution is to make sure that Sugar can boot even if it cannot
> write files. This change is needed in order to enable booting on full
> NAND, whether or not partitioning is used to separate system and user
> files. In short, these issues, while related, are largely decoupled, and
> can be attacked separately.
You are absolutely correct.
Partitioning can be used to isolate the system filesystem(s) from the
effects of user-level data creation, and thus mitigate the risk of
fillup of a partition yielding an unbootable system. However, the
solution is wholly ineffectual wrt. the fillup issue until we ensure
Sugar only needs to write to the partition which we are confident will
have space. If we are going to check all the file write requirements of
the Sugar shell, we might as well implement the far better solution of
enabling Sugar to boot without writing anything.
Below is a patch to Sugar which resolves the only python-side case of a
file write during startup which I was able to find.
I couldn't find reference to the configuration variables saved in
_save_session_info elsewhere in the sugar repository. If these
variables are pulled from the config file after Sugar startup, then this
patch is a bad idea on its own.
diff --git a/src/main.py b/src/main.py
index b1ecc93..1899438 100644
@@ -55,15 +55,19 @@ def _save_session_info():
# do not rely on it
session_info_file = os.path.join(env.get_profile_path(), "session.info")
- f = open(session_info_file, "w")
+ f = open(session_info_file, "w")
+ cp = ConfigParser()
+ cp.set('Session', 'dbus_address', os.environ['DBUS_SESSION_BUS_ADDRESS'])
+ cp.set('Session', 'display', gtk.gdk.display_get_default().get_name())
- cp = ConfigParser()
- cp.set('Session', 'dbus_address', os.environ['DBUS_SESSION_BUS_ADDRESS'])
- cp.set('Session', 'display', gtk.gdk.display_get_default().get_name())
+ except IOError, (errno, sterror):
+ logger.error("Could not open session_info_file. %s" % sterror)
locale_path = os.path.join(config.prefix, 'share', 'locale')
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1085 bytes
Desc: not available
More information about the Devel