This page has been updated for Maemo-2.0 Mistral
.
Rsync is a lot more functional for making backups than prior
software, particularly rdist. I've installed the Gnu extended find command
from package findutils-find-xargs (some-gnu-utils in Maemo-1.1), and the
rsync package. The find
in the provided Busybox knows about -newer, which is mandated by IEEE 1003.1
(POSIX dated 2003), but not -cnewer which is a Gnu extension. The script at this link
backs up the ITB to a
directory on my server -- the destination is hardwired in the script, as
is the list of directories to be backed up.
Trans-net backups are done daily. Weekly, the backups of all my machines get burned on a CD, which is rotated in a modified binary tree, and at longer intervals additional CDs are burned and put in my safe and offsite in my deposit box.
All important and hard-to-replace data is covered by the listed directories, plus a fair amount of data which is much more easily replaced. However, it takes work to restrict the backup to only configuration files that I have modified. The memory card is not backed up because its content is large and can be rebuilt easily, e.g. re-rip a (legally owned) music disc.
The Osso suite includes a backup application, which is configured in /etc/osso-backup/osso-backup.conf. It is a sub-page of the Control Panel. The backup appears as a directory on the memory card; the help doesn't say what its name is. It would appear that only /home/user/MyDocs is backed up, which is important but there's a fair amount beyond that which a system hacker would not want to have to re-do by hand. Applications can add their special files or directories to the backup list but that doesn't seem to have happened for the applications that I installed.
I describe the Cryptographic Vault in this document. Software such as OpenVPN and Postfix need to use your X.509 certificate to authenticate to a remote server and they don't have any good way to talk to you, the authorized user, to get a passphrase. Therefore the secret key needs to be unencrypted. The basic idea of the vault is that you put your various secrets in a small crypto filesystem. You mount it, giving a passphrase, and the daemons can get at the secrets whenever they need them. When your laptop or ITB gets suspended -- and you make sure this happens when the machine is not in immediate, hands-on use -- the machine clams up by unmounting the vault. The passphrase is required again when the machine wakes, to make the clam re-open.
On Maemo there are a few problems with this approach:
The stock kernel lacks any crypto support.
Apparently there's a howto on the Maemo wiki about kernel compilation, but I'd prefer not to introduce any instability into the ITB just before my vacation. Certainly I'll compile the modules (and modprobe!) after I return.
I still haven't found what, if anything, happens specially when the machine suspends, which is when I want to erase secrets.
So the less secure substitute will be to use GPG to decrypt a tar file containing the secrets, which will be erased upon clamming up, which will have to be done manually.
Comparing the files in Scratchbox with those on the device I found some significant differences, e.g. xterm was pre-installed and had a place on the main menu. Do I have an old version, and specifically, have troublesome bugs been fixed in the latest version?
It's not easy to find a definitive indication of the software version. SuSE has /etc/SuSE-release, for example. The Nokia 770 has /etc/osso_software_version which says SU-18R_3.2005.51-13_PR_MR0 (not too revealing). Perhaps the best clue is /etc/apt/sources.list which in Scratchbox refers unambiguously to Maemo 1.1, but on the device points to a non-resolveable host from which one could obtain sputnik-pe1.
MD5sums of libraries and binaries reveal that about 2000 are identical on the device and in Scratchbox, out of about 5000 on the device and 16500 in Scratchbox. This test was inconclusive.
The most authoritative clue was found in the package inventory list. Almost all packages that are on the device match the 1.1 Scratchbox item in version, and I didn't see any which matched 1.0 (except if 1.1 and 1.0 were equal, which did occur). Thus it's official: the production devices have Maemo 1.1 on them.
Look at Control Panel - Device - About Product. The most recent root filesystem version (as of 2006-04-07) is 3.2005.51-13. This string appears in the filename of the root filesystem image, if you're downloading it in order to re-flash your ITB.
The first step to improving your Nokia 770, and to wiping out your root filesystem, is to become root.
Out of the box, your loginID is user
. su is part
of busybox, which of course is not setUID, so you can't become root that way.
It turns out that you need to enable RD mode (for Research & Development).
Hint of how to become root: sudo gainroot (password rootme)
Then alter this to make it properly secure. Everyone knows that root password,
not that it does any good, so change it promptly.
/usr/sbin/gainroot checks in /mnt/initfs for RD Mode
and gives you
a root shell if it is Enabled
, which it isn't.
What that blog doesn't tell you is that you need to put the
ITB into RD mode by following
the instructions below. And it turns out that in the current filesystem
image, gainroot does not need a password.
http://www.karoliinasalminen.com/blog/?page_id=68 How to get root on the Nokia 770. Karoliina is one of their developers. She says:
flasher --enable-rd-mode -R
Boot it up and you can become root. There's also an option
--enable-usb-host-mode and you can also turn on the serial console
(if you have the connector).
But... Unfortunately there are a few missing details, for which see the following section about the flasher.
Sergio in Italy pointed out an interesting writeup in the Maemo Wiki. This has a good description of how to run the flasher, in English and Spanish, plus oddities that some users have encountered. There are two additional payloads.
At the end of the article there's a reference to two small programs that can split up a Nokia filesystem image into its parts. You can then mount the JFFS2 root image and hack away, and then recreate a flashable image. This is useful if the flasher cannot be used to turn on RD mode, or if you need to make a custom image with extensive configuration and software installation, e.g. if you're giving a Nokia 770 to everyone in your department for inventory control or customer support.
A major theme in the article is that you can modify /usr/sbin/gainroot, commenting out the test for RD mode, so it gives you a root shell whether or not the ITB is in RD mode.
Unfortunately the instructions in the previous section for using the flasher are not quite complete. This link is to instructions for using the flasher on MacOS, but the command line method works just as well with Linux. There are a few key steps that were not obvious in other web posts:
mount -t usbfs usbfs /proc/bus/usb
| Print help message | flasher --help |
| Print board ID (to test) | flasher -i |
| Turn on RD mode | flasher --enable-rd-mode -R |
| Flashing Image | flasher -F Nokia_770_etc.bin -f -R |
Suitable USB device not found, waiting.
In the above procedure the ritual of turning on the ITB after the flasher is running is optional, I believe, being a maneuver to overcome problems recognizing a new USB device on some operating systems. However, I wouldn't try any of this with the operating system running on the ITB; it's important to power it off and then have only enough BIOS activation to do the USB connection.
With RD mode enabled, sudo gainroot will give you a root shell
without requiring a password.
Several of the escapades described in the following sections had a baleful effect on the ability of the ITB to boot. Here is what I did to recover from that problem.
The symptom is that the ITB is in an infinite loop of rebooting. It may or may not show the progress bar, but the user interface fails to start, specifically fails to signal its aliveness to the watchdog timer, and the watchdog reboots the machine. To put it out of its misery, remove the battery, wait ten seconds, then put the battery back in. This link is to a script that will automatically revert hacks after 3 reboots.
It is assumed that you were smart enough to back up your filesystem just before you did whatever stupid stunt that made it unbootable. The procedure herein will replace the entire root filesystem with a new copy, wiping out all evil changes, but also all your user data (memory card excepted).
In my case the backups are on my server and will be restored over wireless. For me, the provided backup application saves only the files in ~user, and most of the work is in the system area, so that's not enough. This procedure certainly can be varied -- you could also copy the backup data via USB onto the memory card, then restore from there. But remember that the memory card has a vfat filesystem, which can't do symlinks or ownership by a specific user, and limited access modes.
Follow the procedure in the previous section to download the flasher and the root filesystem. Flash your root, reverting everything to factory defaults, except turn on RD mode in the likely case that you had it turned on before. You need this to execute as root.
When the machine reboots, go through initial
setup again. You're setting the preferred language, the date and time,
and the device name
to be shown by the file manager (this is not the
hostname of the device). Cancel phone setup if you have no Bluetooth phone.
Configure the wireless connection. The most annoying item here is to type in your WEP key. If you parked the relevant files in a backup directory on the memory card you can save yourself some work; same for several steps below.
Download and install xterm. If you're doing this over wireless, install
OpenSSH or Dropbear, and make sure they work. You will get new host keys,
which you will want to replace with the old ones as soon as you can get at
your backup copy (and /etc/init.d/ssh reload
).
From the ITB you can use scp to copy your public key from your
lap/desktop machine into /root/.ssh/authorized_keys. You'll need to give your
password as known on the laptop. Here's the command line, executing as root on
the ITB (substitute your loginID,
hostname, and any variants in relevant filenames to match reality):
mkdir /root/.ssh
scp yourself@laptop:.ssh/id_rsa.pub /root/.ssh/authorized_keys
Assuming that the original problem was not caused by files now waiting on your backup media to reinfect your machine, you will want to restore your settings and files, or at least that fraction which probably are not giving you trouble. My backup is in the form of actual files on the server, starting at the ITB's root so etc and home are subdirectories of the backup root. In other backup methods a compressed tar file is the form of the backup. In either case, your goal is to pipe a compressed tar file through the aether and then restore it. Here's the command line that works with my backup method. Note, the two halves are best typed on one line, though it's shown split onto two lines so it fits visually. You do this as root, on the backup server.
(cd /home/backup/the_itb ; tar czf - home root usr var) | \
ssh the_itb "cd / ; tar xpzf -"
/etc was not restored in the above step. In one restoration I re-horked my filesystem by restoring everything in /etc, so subsequently I restored very selectively. The files I've hacked (or noticed that they need to be restored) are these:
Except for ldconfig, these special items probably apply only to jimc's particular hacked configuration. Other users will need to manually create symlinks and directories special to their setup that don't get backed up.
Then reboot. This successfully restored almost all of my configuration and user data. The only item that didn't make it, that I've noticed so far, is the designation of my browser's home page. [Fixed in Maemo-2.0.]
Beware (Maemo-1.1 only). There seems to be a problem with the root image Nokia_770_SE2005_5_2006_13_7.bin -- /usr/share/zoneinfo seems to contain only the zone file for Helsinki, so your timezone comes out as Eastern European Time. The zoneinfo is complete on Maemo-2.0, but if you're sticking with the old version, you can recover this way. Apparently zone info has no endian problems, and I was able to install a complete set from my laptop. It really helps if you preserve hard links. Use this command line:
rsync --rsh=ssh --rsync-path=/var/lib/install/usr/bin/rsync \
-aH /usr/share/zoneinfo the_itb:/usr/share
For use after mysterious filesystem horkage, here is a list of setup actions to be taken, in case it was deemed prudent to set it up from scratch rather than to restore system files from backups:
Track, hit
Add to Favorites. Stop the player, then start it again from the Internet Radio icon on the home view; it's the rightmost button. The Favorites list will be shown. If you have non-favored items, select one and hit the icon in the lower left with a minus sign, for
remove from favorites. When the playlist is the way you want it, hit (menu), Playlist, Save. The favorites are saved in /home/user/MyDocs/.sounds/favourites.m3u
new windowimage. Display the image (type in the file: URL), then on the app menu, Web Page, Set Home Page. This is saved in /home/user/.opera/opera.ini
search cft.ca.us math.ucla.eduand
options timeout:2 attempts:2.
Maemo-1.1 had some syndromes of mysterious crashes after some of my hacking campaigns. I've condensed the results so they're of more general interest. The major lesson is, make very sure that /etc/profile and ~user/.profile are bug-free. The user interface runs as <user>, and if something in either of these files prevents the user interface from starting, the watchdog timer will reboot the ITB in an infinite loop.
Someone wrote in and said he had changed the shell of <user> to bash. I was scared to do that, although bash is POSIX-compliant and so it should work if you substitute it for the Busybox version of ash. However, the person had an incorrect or missing entry for bash in /etc/shells, and su or sudo didn't like it, preventing the user interface from starting.
I move files back and forth between my various machines, and having them owned by <user> on the ITB and by <jimc> everywhere else is rather bothersome. In addition, Pine determines the sender of mail from the numeric UID, and I was embarassed to find that all my mail was sent as <user>. I want to change my loginID and numeric UID and GID to match the values elsewhere.
Michiel Toneman sent me this URL that he found, which details two ways to configure Pine to send mail as a user other than <user>, like myself. This is a good hack, but I still need to deal with the file copying issue.
Anyway, here's a summary. First, since Pine 4.1.x you can create a role,
which you can induce Pine to (almost) always use. Second, since version 4.0
Pine has a hidden feature (accessible only by editing .pinerc) by which you can
alter the default From
header. Append allow-changing-from
to the
feature-list (comma separated, put a comma after the formerly last item). Then
append From
to the customized-hdrs list (comma separated, create it if
not formerly existing); the author gives this example (the second line is
indented with a blank):
customized-hdrs=From: AnyPersonalName <AnyUserID@AnyDomain>,
Organization: Your Company Name and URL
Even though the Pine hack would have solved one of my problems, I continued working on the original plan. Here are where the loginID of <user> appears, as far as I can see:
So I can't just rename <user> to <jimc>. Instead I'll try to create a parallel user identity, placing <jimc> ahead of <user> in /etc/passwd. Oops, that wasn't such a good idea. See the previous section for recovery procedures.
I went back and carefully analysed the startup scripts. These are the changes that I made. Links are to paragraphs in the scripts page from which the hacked files can be viewed or downloaded. See that page for the DISCLAIMER OF WARRANTY and additional warnings.
/etc/passwd -- Added an earlier line for <jimc> that duplicates <user> except for the loginID and full name (GECOS). This way, user 29999 is interpreted as <jimc> but <user> still exists and is translated to UID 29999. I'm going to not mess with changing the numeric UID for now.
/etc/group -- Added jimc to the dialout group.
/etc/sudoers -- I inserted this
line at the beginning. There is a
blank before and after the =
and a blank after the comma; I'm
not sure how picky sudo is about whitespace, but it's picky about
everything else.
User_Alias USERS = user, jimcAnd I changed
useron all other lines to
USERS.
/etc/init.d/pickuser -- I created this script (with links in /etc/rc{2,3,4,5}.d) that uses mental telepathy to intuit the loginID of the user who should be logged in. It writes that loginID as /tmp/pickuser so other scripts can find it. In a production system it should be possible for several people to share the ITB, plus password protection (optional), and at this point if there really is more than one user a greeter screen should be shown as with gdm_greeter etc.
/etc/init.d/af-base-apps,
af-services,
af-startup,
maemo-launcher --
All four were changed to read /tmp/pickuser and to su
to that
user, not having <user> hardwired.
/etc/init.d/bluez-utils -- This was not changed. Various daemons and config files refer to /home/user, and this one changes a file's ownership to user, but since <user> and <jimc> have the same UID and homedir, the correct file and ownership happens.
I added three startup scripts in /etc/init.d, with links in runlevels 2, 3, 4 and 5. As it turned out, all should be S13 in the startup order, and none need kill links.
I also hacked /etc/init.d/rc to append startup script output to a file in /var/log where it can survive a reboot, so I might get a clue about what went wrong. This does use up lives in the flash memory, but the ITB reboots rarely and it's worth using those lives.
After detecting a second memory error I wanted to check my root image for concealed damage. Here is the procedure I used.
The filesystem image that you download from Maemo is referred to as a FIASCO image. You can disassemble it using the flasher, with this command line:
flasher -F mistral.img --unpack
In the current directory you get rootfs.jffs2, initfs.jffs2, zImage (the kernel), xloader.bin (the booter), secondary.bin and 2nd.bin (not sure just what these do, but they have to do with loading).
You now have the actual root image (and don't forget initfs.jffs2),
but you cannot read it because it's compressed (zlib_deflate). A loopback
mount doesn't work: Attempt to mount non-MTD device "/dev/loop0" as
JFFS2
. But an obscure Google reference and an IRC log preserved by
chance revealed the secret.
Mtdram creates a RAMdisc that emulates a MTD device. So only do this on a machine that has plenty of RAM. Your udev daemon should create /dev/mtdblock0 automatically; if you don't have udev, the major number is 31 and minor is 0. The sizes are specified in decimal Kbytes (1024 bytes). You can find the correct values (in hex bytes) on the ITB in /proc/mtd. Here's a trick to save you errors: use the shell (bash or busybox) to convert hex to decimal:
echo $((0x07b80000/1024))
(it prints) 126464
I raised the total size to a round number, 128 Mb, and it worked for readonly access. However, you can alter the data in /mnt, unmount the filesystem, and then re-extract it from /dev/mtdblock0. If you do that, I'm pretty sure the size has to be an exact match -- in other words, I should not have messed with the size.
In a RPM-based system you can use rpm to get a list of files provided by a package. There's an equivalent on Debian systems: look in /var/lib/dpkg/info . This is a big flat directory with various files for each package, as follows:
The manual (page 9, Insert the Memory Card
) says, make sure that
the memory card is formatted with a FAT16/32 filesystem; other filesystem
types will not work. Just what part of will not work
do I not
understand; just what part can I slither around?
A major issue with flash memory is that each block can only be written about
100,000 times, so upon repeated writing the same
block needs to migrate
to many places on the memory chip. In general, filesystems on flash work on
top of
a translation layer which makes the block device imitate a rotating
magnetic disc, while dealing with the migration issue.
Here are the filesystem types which the provided kernel can do, and a discussion of their use on flash memory. Nonphysical filesystems such as procfs are omitted.
This is what the Maemo distro wants to see, warts and all: it requires a translation layer, it has a max of 2^16 allocation units and hence requires big clusters, 16 kb on a 1 Gb filesystem. It can't do UNIX-style symbolic links, FIFOs, devices or sockets. Both FATs have to be rewritten for every allocation of space. Vfat is just about pessimal as a filesystem on Flash, and I'd really like to get away from it.
This is vfat's little brother, with the same disadvantages.
While it's an excellent filesystem for a real disc, on flash there's no advantage to ext2 and there's the disadvantage that it needs to rewrite metadata frequently (the free block map).
Since journalled filesystems like ext3 and Reiser write metadata into both the journal and the real location, they just wear out the flash memory faster and they ensure frequent CPU-intensive migrations. Never put ext3 on flash memory.
This filesystem was specifically designed to be used on flash memory, and should not work through a translation layer. It is quasi-journalled, in that metadata (and payload data) is written in an order which is failsafe if the process is killed at any point, and a half-written block can be recognized and recycled. Blocks are compressed (with zlib) intrinsically, a big advantage trading CPU time for file space (and the time needed to read from the flash memory). The filesystem intrinsically uses flash blocks in a non-repetitive order including on rewrites. Rewritten metadata is minimized.
This filesystem is superior on flash memory to all others, and should be used if feasible. But, will it bypass the translation layer in the block device? No, the kernel source suggests that jffs2 is closely integrated with the MTD block driver, and empirically jffs2 can only be mounted on a MTD device, not a MMC device.
Here are some speed tests and comparisons. All times are elapsed seconds. Generally the system plus user time does not add up to the elapsed time.
df.
| Command | Time (secs) | Speed (by/sec) |
|---|---|---|
| grep 'Bill Gates' file.gz | 172 | 3.97e5 |
| dd file.gz /dev/null | 49.2 | 1.39e6 |
| cat file.gz > /dev/null | 49.3 | 1.39e6 |
| dd file.gz other.gz | 155 | 4.39e5 |
| cat file.gz > other.gz | 103 | 6.58e5 |
To put a jffs2 filesystem on a card you need the source code for mkfs.jffs2.
According to the kernel sources, the JFFS2 code is closely integrated with
the MTD driver. Empirically if you try to mount a MMC device with JFFS2
you get a kernel message about attempt to mount non-MTD device
/dev/mmcblk0p1 as JFFS2
. I posted a message to jffs-dev@axis.com asking
if the situation was likely to change. (No answer seems to be appearing.)
To search for additional sleeping dragons I did a trial run, putting a ext2 filesystem on the card using another machine. It was possible to mount the card manually. However, something in there is fixated on the idea that the card will have a VFAT filesystem; when it's hotplugged, VFAT is the only filesystem tried. (It's not an issue with fstab; I edited that.) So I'm going to put everything back the way it was, and just live with the Gatesoid filesystem. At least for a while. Update, I think I found it. Look in /usr/sbin/mmc-mount -- it hardcodes the vfat filesystem, and it's in /etc/sudoers.
Another idea: see this HOWTO. <Wolfram> suggests to split the memory card into a VFAT partition and a ext2 partition. That way Maemo gets what it wants (even if small) and I get some of what I want. He also suggests what to do with your expanded space: move your downloaded software and /home/user over there, so if you hork the root filesystem, reflashing is not so catastrophic. He also discusses swap files. (Maemo-2.0 has a feature to put a swap file on the VFAT filesystem of the MMC card.
Yet another idea: /etc/sudoers has a line for execing /usr/sbin/mmc-mount. This is a one-line shell script that mounts the MMC card using specifically vfat, ignoring what's in fstab. Hacks here could be productive (of horkage?)
OS2006, has a memory corruption bug in the wlan driver. My experiences with the bug are detailed here. Another annoying behavior also appears to be related. Recently the bug has been tracked down and fixed.
Since my ITB is supposed to be in production mode, I wimped out and applied the hotfix, not the hacker's edition. Here is the procedure.
I've found that WLAN operation has been much more reliable. However, unfortunately there is a bad interaction with the clock: formerly the alarm clock feature was 99.9% reliable, but coincident with installing the WLAN hotfix, when it's time for the alarm the operating system freezes solid. (Remove and replace the battery to recover.) Hiss, boo! On three alarm actions, it died three times. This has been reported as comment #59 in the bug report.
List of init scripts in /etc/init.d: The default runlevel is 2.
Runlevel directories are directly under /etc like with Solaris, e.g.
/etc/rc2.d. [Updated for Maemo-2.0 Mistral
.]
Suto user, run a script, stop the progress bar. The script does the following:
telinint Qto inform init. This is how a serial console is done, according to comments. But I haven't figured out what the USB host needs to do to make ttyUSB0 appear. Nor what to do about the watchdog timer. This should be handled through hotplug/udev, not init! And the same for all the gettys.
Hacked scripts likely need runlevel links in /etc/rc5.d as well. On one occasion the ITB did this nasty behavior: It was powered off. I plugged in the charger. It booted partially and the hacked /etc/init.d/rc logged that it was going into runlevel 5. There was no link for /etc/init.d/pickuser in rc5.d, and this spoiled the boot process leading to an infinite booting loop. (Recovery: unplug the charger, boot normally, provide links in rc5.d.)