Talk:Autoreinstallation image

From OLPC
Revision as of 15:47, 15 September 2007 by MitchellNCharity (talk | contribs) (Doing a "reset to known state" install)
Jump to navigation Jump to search

How do we determine what the current version of the flash and image are?

The current version of your firmware is displayed on the screen at power-on (e.g. Q2B73). Each OS image contains its own build ID in /boot/olpc_build (e.g. 385). You can also see the OS image version in the Developer Console (from a graphical screen, press Alt-= .) It's supposed to show the firmware revision too, but on my machine it says "None".

How are we to know the pros and cons of each version?

The name of each autoreinstallation image includes the name of the software release as well as the name of the firmware release. E.g. olpc303_b76.zip includes software release 303 and firmware release B76. The OLPC Software Release Notes and the Test Group Release Notes contain some information about the various images available. Each firmware release has a page that describes the improvements in it linked from the Firmware page. You can see an index of all firmware-related pages, including all the release notes, at Category:Firmware.

How does this interoperate with bitfrost? Will a reinstalled laptop need to be re-activated?

At the moment, activation is in the code base but cryptography is not available. The autoreinstallation procedure thus generates an unsigned activation lease which will work with the current development builds. When cryptography and real signatures are turned on in the activation procedure, the autoreinstallation scripts will be updated to preserve any existing activation leases.

My disk is not detected because it takes too long to spin up

If firmware does not see it, but probe-usb from the ok prompt does... just do probe-usb followed by boot. In later firmware revs, more time has been allocated between power-up and accessing USB drives. Please report a bug in TRAC if your USB drive doesn't work cleanly with the latest firmware version.

How to force an autoreinstallation

Rename the nandNNN.img and nandNNN.crc files to (say) nand9999.img and nand9999.crc. See the notes on in the article regarding the perils of using this trick for firmware images.

The transcript of an update doesn't include any output about activation

Doesn't the autoinstall script at least tell you when it writes a lease on your USB or SD card? In the transcript it doesn't.

the README file in olpc-auto.zip is obsolete

It doesn't match the latest instructions, e.g. it references old firmware as the latest.

The "latest stable build" link leads to 406, not to 542.

There's no option (in the text of the Autoreinstallation image page) to download the "new stable" release for 256MB machines; the "stable" is 406 and the "latest" is the bleeding edge. I had to find 542 via the link in the little box on the home page of the wiki.

When is it safe to remove the USB key? Won't Linux get upset if you yank it?

Now that the Linux kernel is mounting and reading from the USB key, isn't there something to do to tell the software that you're about to yank out the key, before just pulling it out?

(Also, the final instruction says "2. Power off the machine and remove the USB key..." but the machine has just booted up and is perfectly good. Do we have to power it off merely to safely remove the USB key? If we find a safe way to remove it without powering off, that would save a slow power cycle.)

Possible Problems addition

After installing a build (build 542 seen) your machine may fail to boot completely. Power-supply indicator light will not indicate plugged-in status. Power button will not have any effect. To fix, both unplug and remove the battery from the machine, wait a few seconds, then replace both the battery and the power supply.

Step F

Maybe move the text "Step F is very important: you must remove all power from the laptop in order to reset the embedded controller." into step F, so you don't read it after finishing updating?

Also: MitchellNCharity 11:03, 18 August 2007 (EDT)
  • And it seems to apply to Step G, not F.
  • Does holding the X game key cause any problem before Q2C11? If it's harmless, then the instructions should be simplified, with the X key pressed regardless of version. If this can't be done, then a 'determine your firmware version' step is needed in "Before you begin".
  • Regards After the upgrade, a backup of your user files can be found on the USB key with the name 'backup/<your XO's serial number>/complete.tgz'., does this mean there is a missing last step L 'restore the user's files'? Or is it 'garbage collect the junk file which got left behind'?
  • Regards The USB key must be large enough to hold both the image to be installed and any and all files the user may have created in /home/olpc., some guidance would be useful. Eg, 'the USB should have N hundred MB free'. So I don't have to worry that my empty-but-for-install-files 1GB stick is too small.
    Upon reflection, it seems possible/likely this is included in the 300 MiB of free space in the primary partition note in 'Before you start'. Maybe. That I can't say more than "maybe" illustrates the problem. MitchellNCharity 14:29, 18 August 2007 (EDT)

Please mention size of olpc-auto.zip

Please mention size of olpc-auto.zip next to the download link as it is not detected by the downloader.

Needs an update

Recent updates to b4s or c machines are simple; they ask you to power off by hand rather than powering off automatically; and they can try to do a (blank) update if you have the same biuld as the existing one. The directions here should be split into "also update firmware" and "no firmware update" since the latter can be so much simpler. Sj talk

"if the laptop says "Firmware is already current" you can skip to Step (I) below;" --Walter 18:35, 11 September 2007 (EDT)

Doing a "reset to known state" install

Perhaps the instructions should mention what is needed to do a "clean" install. One which resets the machine to a known state. This is needed, for example, for testing. Saving and restoring user files creates state which persists across builds. Ie, I broke my Journal, and it's brokenness persisted though an upgrade. Is rm -rf ~olpc sufficient? MitchellNCharity 11:47, 15 September 2007 (EDT)