NSLU2-Linux
view · edit · print · history

HowTo.UseTheBootDiskMechanism History

Hide minor edits - Show changes to markup

December 06, 2008, at 04:54 AM by mwester -- formatting
Changed line 32 from:

Of course, you can change things with that script. The script and do

to:

Of course, you can change things with that script. The script can do

Changed lines 67-70 from:
  • the device in question must be automagically mounted as HD_(something)

by the Linksys firmware. This implies that a FAT-formatted device is required, although an NTFS-formatted device will work on the one port that supports that.

to:
  • the device in question must be automagically mounted as HD_* by the Linksys firmware. This implies that a FAT-formatted device is required, although an NTFS-formatted device will work on the one port that supports those devices.
Changed lines 69-77 from:
  • bootdisk scripts will be searched for in subdirectories that match the

hostname you assigned to device, its original Linksys hostname ("LKG(something)"), and finally the subdirectory named "default". This permits you, for example, to have a single "toolkit" USB key with your favorite scripts arranged for each of your slugs (you all have multiple of them, no?)

  • the scripts must start with the letter "S", followed by a couple of

digits, and the name. They will be executed in alphabetical order.

to:
  • bootdisk scripts will be searched for in subdirectories that match the hostname you assigned to device, its original Linksys hostname ("LKG*"), and finally the subdirectory named "default". This permits you, for example, to have a single "toolkit" USB key with your favorite scripts arranged for each of your slugs, if you have more than one to deal with.
  • the scripts must start with the letter "S", followed by a couple of digits, and the name. They will be executed in alphabetical order.
December 06, 2008, at 04:49 AM by mwester -- re-organization
Added lines 22-23:

Example: "I Lost My NSLU2 on the Network!"

Changed lines 32-35 from:

Of course, you can change things with that script. I don't know what you might like to change, but the script could do pretty much anything you can do when you're logged in at a shell prompt.

to:

Of course, you can change things with that script. The script and do almost anything you can do as a user when you're logged in at a shell prompt.

You can download a sample boot disk script here: http://moko.mwester.net/unslung_sample_bootdisk.zip -- just unzip this to the top level of a FAT-formatted USB key in order to use it as described above.

Advanced Example: Automatic Unsling

Added lines 62-65:

An example script to do this can be found here: http://moko.mwester.net/unslung_sample2_bootdisk.zip -- use with caution; it is only an example and is not nearly robust enough to be considered reliable!

Building Your Own Boot Disk Scripts

Changed lines 101-112 from:

As an example, you can refer to http://moko.mwester.net/unslung_sample_bootdisk.zip -- just unzip this to the top level of a FAT-formatted USB key in order to use; it's very simple -- it redirects its own output to a log file on the USB key, and prints out various helpful debugging information and logs that can then be examined on another system to see what ails the slug. I also hope that this simple example will help people resolve the "I lost my slug on the network" problem...

(As another example, the script that does the automatic "unsling" operation described above can be found here: http://moko.mwester.net/unslung_sample2_bootdisk.zip -- use with caution; it is only an example.)

to:

Disabling Boot Disk on your Unslung NSLU2

December 06, 2008, at 04:42 AM by mwester -- formatting
Changed lines 8-9 from:
to:

BootDisk

Changed line 11 from:

what's wrong are a few LEDs? and a beeper. Wouldn't it be great to have

to:

what's wrong are a few LEDs and a beeper. Wouldn't it be great to have

Changed line 55 from:

- the device in question must be automagically mounted as HD_(something)

to:
  • the device in question must be automagically mounted as HD_(something)
December 06, 2008, at 04:41 AM by mwester -- Reformatting
Added lines 1-5:

Using the Boot Disk Mechanism with Unslung

This article pertains to:

  • Unslung 6.10

Changed lines 8-11 from:

Mike Westerhof provided the following description - which I've pasted verbatim as initial documentation (now slightly edited)

BootDisk?

to:
Changed lines 74-80 from:
 #bootdisk:nocopy
to:

(:table border=0 width=80% bgcolor=#ddeedd:) (:cell:)

#bootdisk:nocopy

(:tableend:)

October 05, 2008, at 04:35 PM by mwester -- minor edits, added additional link
Changed lines 3-4 from:

Mike Wester provided the following description - which I've pasted verbatim as initial documentation.

to:

Mike Westerhof provided the following description - which I've pasted verbatim as initial documentation (now slightly edited)

Changed lines 12-13 from:

upload files and all that stuff.

to:

upload files and all that stuff?

Changed line 71 from:
  1. bootdisk:nocopy
to:
 #bootdisk:nocopy
Changed lines 81-82 from:

http://moko.mwester.net/unslung_sample_bootdisk.zip for an example. Just unzip this to the top level of a FAT-formatted USB key in order to

to:

http://moko.mwester.net/unslung_sample_bootdisk.zip -- just unzip this to the top level of a FAT-formatted USB key in order to

Added lines 89-91:

(As another example, the script that does the automatic "unsling" operation described above can be found here: http://moko.mwester.net/unslung_sample2_bootdisk.zip -- use with caution; it is only an example.)

April 24, 2008, at 11:42 AM by tlhackque -- Initial documentation for BootDisk mechanism
Added lines 1-92:

The boot disk mechanism is new in Unslung 6.10. It provides a fairly painless means to intercept the boot process and insert your own script - simply by plugging a disk into the NSLU2.

Mike Wester provided the following description - which I've pasted verbatim as initial documentation.

BootDisk?

The poor little sick slug - it's hurting, but all it has to tell you what's wrong are a few LEDs? and a beeper. Wouldn't it be great to have some other means to communicate with the device? Wouldn't it be neat to have a way to customize the internal firmware boot process to do something extra, or change something, without needing to telnet in, and upload files and all that stuff.

Unslung 6.10 supports something referred to as a "bootdisk". In a nutshell, after it completes the normal boot (with or without disks), if it finds a specifically-named file in a specifically-named place on an external USB device, it will execute that file as a shell script.

So what do you do with this? Well, how about having that shell script fetch the network IP address that the device has and write that to the USB device (flash memory device or disk)? This would be a convenient way to find your lost slug -- place the script on an ordinary FAT-formatted USB key, plug it into the slug, boot it up, power it off, and look at the log file that appeared on that USB key to see what IP address your slug was using.

Of course, you can change things with that script. I don't know what you might like to change, but the script could do pretty much anything you can do when you're logged in at a shell prompt.

As a proof-of-concept (it's nowhere nearly reliable enough), I wrote a script that can be placed in this special directory structure on an other-wise empty USB key of almost any size (32 MB or greater), and the key plugged into a freshly-flashed Unslung system.

Upon power-up, the new Unslung system boots, and begins executing the script, which proceeds to format the USB key, copy the files in place to fake the Linksys firmware into thinking that it itself did the format, then performs an "unsling" to the newly-formatted USB key.

Upon reboot you have a fully-unslung system, ready-to-go. As I said, not stable enough for general use, but it does illustrate what you can do with the bootdisk concept. (For those wondering how one can format a device from the command line on a virgin Unslung system, the fdisk provided with Unslung 6.10 is still the crippled Linksys version so that the Linksys firmware continues to work -- but you can now type "busybox fdisk" to invoke a properly-functional fdisk. This might be useful for some situations.)

The requirements for the bootdisk to work are: - the device in question must be automagically mounted as HD_(something) by the Linksys firmware. This implies that a FAT-formatted device is required, although an NTFS-formatted device will work on the one port that supports that.

  • a directory named "bootdisk" must exist at the top-level of the device.
  • bootdisk scripts will be searched for in subdirectories that match the

hostname you assigned to device, its original Linksys hostname ("LKG(something)"), and finally the subdirectory named "default". This permits you, for example, to have a single "toolkit" USB key with your favorite scripts arranged for each of your slugs (you all have multiple of them, no?)

  • the scripts must start with the letter "S", followed by a couple of

digits, and the name. They will be executed in alphabetical order.

In deference to the inevitable, by default the script file will be copied off of the flash device, and MSDOS-style line endings converted to normal line endings. If you wish to avoid this happening (perhaps your script is a very large self-extracting file, and it would fill up the flash on the slug), simply place a line in the script that looks like:

  1. bootdisk:nocopy

(exactly like that, no indentation, no spaces, no tabs, no nothing)

In order for your bootdisk script to know where that USB device is (so it can find supporting files or tools, or know where to write a log file, etc), two arguments are passed in to the script. The first is the full path to script's original location on the USB device; the second is the path to the subdirectory containing the script.

As an example, you can refer to http://moko.mwester.net/unslung_sample_bootdisk.zip for an example. Just unzip this to the top level of a FAT-formatted USB key in order to use; it's very simple -- it redirects its own output to a log file on the USB key, and prints out various helpful debugging information and logs that can then be examined on another system to see what ails the slug. I also hope that this simple example will help people resolve the "I lost my slug on the network" problem...

Finally, what if you don't want the bootdisk stuff? Perhaps you don't trust people, or you don't trust yourself. If you simply create an empty file at "/.nobootdisk", the bootdisk checking will not occur.

view · edit · print · history · Last edited by mwester.
Based on work by mwester.
Originally by tlhackque.
Page last modified on December 06, 2008, at 04:54 AM