[olpc-nz] Sugar onna Stick

[Mikus Grinbergs]

Vic wrote:
> On my laptop the USB does not now reliably boot.

In my case I'm using q2e41.rom, and I'm not having boot problems.

I do have /security/develop.sig on the USB stick I'm booting 
strawberry from.  Also, I normally press the <check> front panel 
button as I boot.

That allows me to look at the XO screen and tell *if* the USB stick 
is being recognized.  The first (leftmost) image OFW draws on the 
screen is a purple "USB device".  If the black "open lock" image 
appears below the (leftmost) "USB device" image, then OFW has been 
able to read (and use) the content of the develop.sig on my USB 
stick.  [Also, the screen text (evoked by the <check> button) will 
tell me whether files on the USB stick were successfully accessed.]

Further, I look at the screen text (evoked by the <check> button) 
just before OFW starts loading the build itself (e.g., just before 
the white-background screen used by OFW is cleared).  It tells me 
whether the executable image is being loaded from 'u:' (or perhaps 
'disk:') - those are the USB stick - or from 'nand:' - that is the 
"non-USB" build already installed on that XO.

By looking at the above information, I can tell whether "booting 
from USB" is being performed.  If there *is* a problem with the 
particular USB stick, the symptom very often is inability of OFW to 
perform "boot from USB".


If the boot stalls *after* OFW loads the executable (e.g., in the 
case of the <check> button having been used, the XO screen has now 
switched to a black background), then it is no longer an "XO boot" 
problem, but instead an "XO build" problem.

Historically, there have been a multiplicity of "the boot stalls" 
problems while trying to load the system - for instance, caused by 
the system loader failing to mount the '/' filesystem.  [Some of 
these have been blamed on a "race" condition, where event B is 
supposed to follow event A - but for whatever reason, B happens to 
occur before A completes.]

The best one can do with a "the boot stalls" problem after OFW has 
finished its work is to write down as much about the problem as 
possible, and contact the build maintainer.  For "the boot stalls" 
problems before OFW has finished, I normally simply retry (some 
months back there was a situation {now fixed} where it took eight or 
more retries before one happened to get past the stall point).  [It 
is *not* supposed to make any difference, but I suspect I get 
different internal timings by switching my USB stick to a different 
socket on the XO (my XO's left side socket seems to be slightly more 
reliable).]


Brenda wrote:
> Ctrl-alt-F2 will get you to a console.

If possible, I prefer to launch Terminal.

The default console font is hard to read, and the console does not 
support scrolling (to look at previous screen inputs/outputs). 
Plus, in strawberry Terminal has tab support, which is like having 
multiple consoles.


Alastair wrote:
> I'm not sure about sugar on a stick but on the XOs the logs are only
> persistent for the current session to minimise writing to the flash memory

Although "minimize writing to the flash memory" *is* implemented, on 
my XOs logs from Activities (they go into ~/.sugar/default/logs/) do 
ultimately get written to "flash memory".  [Note:  on each restart 
of Sugar, any previously existing files in ~/.sugar/default/logs get 
put into a newly-created sub-directory having a ten-number name; 
thus individual files found in the ~/.sugar/default/logs/ directory 
itself are from the current Sugar session.]

When I boot from nand (which is a kind of "flash memory"), the logs 
from Activities (they are in ~/.sugar/default/logs/) do get written 
   to nand, where they persist.  [In the interest of not taking up 
too much space, strawberry keeps no more than four of those log 
sub-directories with ten-digit names - when creating a new such 
sub-directory would make five, the oldest gets deleted.]


I apply a number of "customizations" to each new build I install, to 
make the build "easier to use" for me, and to apply packages which I 
use which did not come pre-installed in that build.  It would be a 
bother if I had to re-apply all those changes whenever I rebooted. 
To make all changes persistent, I create my USB sticks with an 
'overlay area' for preserving changes applied to the original image. 
The command I use to fashion an USB stick is {all on one line} :

   livecd-iso-to-disk.sh --format --xo --xo-no-home --reset-mbr
     -- overlay-size-mb 400 strawberry.iso /dev/sdf1

In addition, to make sure that that the 'overlay area' is 
persistent, I go into /boot/olpc.fth on the created USB stick and 
delete the token 'reset-overlay' from the parameters being placed in 
the  boot-file  variable.

The side effect of me having made all system changes to be 
persistent when booting from such an USB stick is that changes to 
~/.sugar/default/logs are also persistent.  I'm willing to tolerate 
the additional "wear" to my USB stick's flash memory from doing so. 
  [If someone were paranoid about not writing Activity logs to flash 
memory, they could 'mount' ~/.sugar/default/logs as a tmpfs !]


mikus