Error message

Deprecated function: The each() function is deprecated. This message will be suppressed on further calls in menu_set_active_trail() (line 2405 of /var/www/html/includes/menu.inc).

Customisation of OpenZaurus 3.5.2 (Collie / sl5500 )

  • Posted on: 12 March 2005
  • By: agittins

Perhaps "Customisation" is a bit strong - basically I am talking about the fine-tuning that I do for my tastes, and I must say, Open Zaurus has come along really well in the last few releases, so this is a bit different from my older page on Customisation of OpenZaurus 3.5.1.

I am using an SD card for all my storage, along with the rboot scripts to pivot root onto the SD, so if you are not doing similarly this info may be of limited use to you. Who am I kidding? This is of use to only me, really - it is I who needs these cheat pages to remind me how I set things up - you may not have this problem :-)

Flashing
Nothing special here, just follow the instructions. Suggest you use the md5sum tool to make sure that the files you copy on to your CF card arrive intact. Using corrupt image files is both common and disastrous. Secondly, remember to take out the CF card (and SD card if you had one in) before the final bootup, otherwise you'll get caught up in the media mounter before the screen calibration.

First Boot
Again, follow the bouncing ball, so to speak. If you are going to restore your old data don't spend too much time filling out your address book entry :-)

Rootme is an invitation...
Change your root password. Nuff said.

Netgear MA-701 WiFi card
Yay! Glad to report that OZ 3.5.2 now recognises and uses the MA701 802.11b card from Netgear "Just Fine"(tm). It detects as a Zcomax AirRunner thingy, but I think only Netgear are concerned about the branding :-)

Time and Date
I suggest you install the "timezones" package before proceeding much further, this seems to resolve some issues with ntp and the hardware clock - not sure if this applies to all timezones, but here in BNE at least the Z gets all mixed up between GMT and AEST on suspends/reboots without the timezones package. After that link your suitable timezone file to /etc/localtime, thusly...

ipkg update
ipkg install
ln -s /usr/share/zoneinfo/Australia/Brisbane /etc/localtime

Opeie's taskbar doesn't seem to notice all this going on, so wait until your next reboot before getting worried about time/date stuff again - just make sure that your ntp server works etc.

Package Management
Unfortunately the shipped opie-packagemanager is still a bit hairy, and not really recommended for production use. If you want a GUI package manager (I sure do) then we'll install the more reliable old one...

ipkg remove opie-packagemanager
ipkg install opie-aqpkg

Also, it's a good idea to go and get any updates that might be out (although this might also break things too, who knows.. just as well we have all this documented in case you need to start again!)....

ipkg upgrade

As of this writing (12/03/2005), the only package that gets upgraded is dropbear (an ssh implemtation, no relation to this website :-)), which causes no issues that I've noticed. If more packages get updated from the base image you might risk running out of root space (= reflash) or other problems (see the 3.5.1 notes). For now though, all is rosy....

Speaking of SSH...
Now's as good a time as any to grab your public keys (or mine if you like, see if I care!) and drop them in so you (or I) can ssh into your zaurus securely.

mkdir .ssh
chmod 755 .ssh
cd .ssh
wget http://www.purple.dropbear.id.au/downloads/keys/agittins.pub
mv agittins.pub authorized_keys
chmod 444 authorized_keys

Finger-savers
Add the following to /root/.profile:

# This makes backspace work in Vi:
stty erase ^?
# These are just 'cause I'm lazy...
alias d='ls -aF'
alias da='ls -alF'

End of Part I
That pretty much sorts out a solid, workable base install (for my tastes, anyway). Probably a good time for a reboot and a fresh coffee. Then, onward to....

Boot from SD
<drumroll/><fanfare/> The great Daniel Steen has prepared a set of scripts that make rotating your boot environment onto SD a breeze. Furthermore, it allows you to boot from disk images installed on SD too. You can find the latest on SD booting at the OpenEmbedded wiki, but it has a lot of outdated guff before it gets to the good part - a single link to these great scripts. Find the tarball here: http://mysite.verizon.net/dfsteen/rboot.tar.gz, but you may as well just go straight to your Z and...

wget http://mysite.verizon.net/dfsteen/rboot.tar.gz
tar xvzf rboot.tar.gz
cd rboot
# - read the readme, otherwise don't toast me if this blows up on you
./modify_base.sh
./install_init.sh

The rboot environment is now set up, but we have not created any additional boot entries as yet. So if we reboot now we should get a prompt for just the (i)nternal system, plus the two example entries, (o)pie and (g)pe - neither of which will work since you don't have those images on your card. This is the default behaivour, so you don't really need to customize anything in the rboot system, but I still recommend you read the readme.

Preparing your SD card

Note that the scripts perform the kernel module insertion and mounting of your SD card, as a result of which you must use ext2 on your card, or you can probably modify the script to work with a fat card with ext2 images on it - in which case you don't need my advice :-)

So, let's format our card (make sure there's nothing you want on it first though, duh!). First I fdisk it, since the partition table on the card says that mmcda1 is a FAT16 partition, which will not be the case. I am not sure if this is truly vital, but it might help with manual mounting later on. Fdisk should go something like this... (stuff in square braces are my comments)

fdisk /dev/mmcda [note: using mmcda here, not mmcda1]
p [will print out the partition table, which on my 1gb card looks like:]
Disk /dev/mmcda: 1015 MB, 1015808000 bytes
32 heads, 63 sectors/track, 984 cylinders
Units = cylinders of 2016 * 512 = 1032192 bytes

Device Boot Start End Blocks Id System
/dev/mmcda1 1 984 991840+ 6 FAT16

t [command to change the fs type]
83 [the system id for Linux/ext
p [should print out a better looking partition table like this:]
Disk /dev/mmcda: 1015 MB, 1015808000 bytes
32 heads, 63 sectors/track, 984 cylinders
Units = cylinders of 2016 * 512 = 1032192 bytes

Device Boot Start End Blocks Id System
/dev/mmcda1 1 984 991840+ 83 Linux

w [writes out the new partition table and quits = a good thing]

Now you should be well and truly sweating, you just knacked your card! No worries, we can format it now...

umount /mnt/card
mke2fs /dev/mmcda1

Note that we are doing this to "mmcda1", not "mmcda". The latter is wrong, you should use the first (or subsequent) partition(s), not the block device itself - remember the fdisk stuff? It is rumored that using the block device directly has lead to card death, you have been warned.

If you just try and mount /mnt/card now though you will be left scratching your head - the mount options in /etc/fstab assume that it's going to be FAT16 or similar. Just edit /etc/fstab and remove the mount options "user,exec,suid" from the line for /mnt/card only. The other options "defaults,sync,noatime" are just dandy and should be left there.

Option (A): just boot from SD

This is not the one I use, I prefer to keep my bootup files in separate disk images for easier management. But, if you want to just boot off the SD card and not muck about further, this is for you. To create "boot systems" for rboot to select from, you run the "copy_files.sh" script, with the destination dir as the only paramater, then you add an entry to /etc/rboot.conf. This works on destination directories only, not for disk images directly. So if you are running your SD in ext2 then you are good to go. Eg, "./copy_files.sh /mnt/card" will create a "root" environment on your SD card. Then add a line like "b sdboot sd" to /etc/rboot.conf. Note that you don't include a name for an image file in this case.

Option (B): Boot Images

This is the path I chose. I like the idea of being able to keep the SD card layout pretty clean and having the flexibility of running several different environments at will. Since each "installation" ends up just being a single file on the SD card this is pretty flexible. The process is pretty simple. First we create an empty image file, then we format that file as a filesystem, mount it, and populate it. Break it down...

dd if=/dev/zero of=/mnt/card/base.img bs=1M count=256
mke2fs /mnt/card/base.img
losetup /dev/loop0 /mnt/card/base.img
mount -t ext2 /dev/loop0 /mnt/image
./copy_files.sh /mnt/image
umount /mnt/image
sync

Some notes on the above:

  • Yes, that dd command takes AGES - this is because the card is mounted with the "sync" option, which means that writes are not buffered in memory. Don't worry, when we mount the images they will have buffering enabled, so they will be faster on IO.
  • When you start mke2fs it will complain about the file not being a block device - say "yes, on you go".
  • Don't do thinking that the copy_files script has hung - once the buffers fill up (the image uses buffering) the copy will grind to a crawl. On my unit this happened at the "cleaning up" part. Have patience, grasshopper, the prompt shall return.
  • For extra points, you can run the "df -h" command just before the umount so you can see how things are laid out and verify that your copy used up some of the space.
  • The umount and sync calls are there from my paranoia, they may not be necessary.

Now that you have created a shiny new disk image, you can add it to your rboot.conf - for the file above the entry would go something like "b baseimage sd /mnt/card/base.img" - you can change that however you like, per the requirements of rboot.conf.

Reboot, and see how you go!

Knowing it worked
The rboot stuff (it's init script, specifically) will generate some useful output on the console during bootup if anything goes wrong. But maybe you missed it and just want to know if you are indeed running on an image, or if you fell through to the original internal system. The "df" command is pretty useful here - it will show you where root (/) is mounted and other things. If you came up on an image, it should look something like this:

root@zaurus:# df -h
Filesystem Size Used Available Use% Mounted on
/dev/loop0 14.1M 13.2M 960.0k 93% /mnt/root
/dev/mmcda1 953.3M 256.3M 648.6M 28% /mnt/card
/dev/loop0 247.9M 26.3M 208.8M 11% /
tmpfs 30.5M 52.0k 30.4M 0% /var

Note that / is mounted on a loop device (loop0). This is showing you that you have indeed successfuly booted from an image. Yay for you :-)

Essemtial packages
This is just a basic list of the first packages I install once I've completed the above.
service-release-1, subapplet, oz-compat, opie-zsafe, opie-tetrix, mileage

Comments

Has anyone had success migrating their boot image over to SD with 3.5.3? I get everything OK but at boot time i see the menu but i'm unable to select anything. Instead I get "Sorry that choice not found, try again" scrolling down the page with no meaningful response from the keyboard. Did 3.5.3 do something to break these scripts?

Much better explained than at http://openzaurus.org/wordpress/howto/root-on-sd/

Congrats ;-)
Elimar

The same here :-)

Thank you very much for your howto.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
CAPTCHA
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.