Minix 2.0.3 Upgrade Gotchas

written 17 Dec 2002, revised 17 February 2005

There are some major changes between Minix 2.0.2 and Minix 2.0.3 that can complicate upgrading a working system. There is a new nomenclature for disks, a new set of tools for accessing MS-DOS/Windows files, some of the supplied scripts behave differently from those in earlier versions, the default shell behaves differently in some case, and I ran into some other "gotchas" that I never could understand.

This text was first written in 2002, when I first updated a couple of my private systems to Minix 2.0.2. It has been updated in early 2005. I hope it will be useful others doing upgrades. It may also point out a few things to look out for when the next "major" upgrade is due.

These experiences are from both a DOSMinix install and a couple of "standard" installs on native Minix partitions, starting with booting from the Minix install floppy and installing to empty hard disk partitions. Probably the answers to most of the questions that arose are somewhere in the existing documentation, but either I could not find them and figured things out myself or I found them only after some difficulty.

1. The new disk device names were my first gotcha. I had to learn that the usr partition on the install floppy is not fd0c but fd0p2. And I had to mount a sticky note on the front of my computer to remind me that my Windows partition was /dev/c0d0p0 and my Minix partitions were /dev/c0d0p1s0 and /dev/c0d0p1s2. [2005 note: OK, I'm used to it now, and finally I admit it was a good idea.]

2. In the DOSMinix case it wasn't immediately obvious that I could access the hard disk. The key is the controller part of the device name. Under DOSMinix /dev/c0d0 refers to the simulated disk on a DOS file. The hard disk is accessed by a different controller, so the first hard disk partition is /dev/c1d0p0. [2005 Note: Keeping track of multiple controllers is one reason I now like the new nomenclature. I have used several systems with the basic installation on a DOSMinix simulated disk, and native Minix partitions with my web and ftp directories mounted. Just remember to add c1=at in the boot parameters.]

3. Access to Windows/MS-DOS files using Mtools. I almost always install on a system that has some form of Windows on another partition, so I can use Windows to acquire the various archives over the network or via CD-ROM or Zip disk, rather than having to use vol to transfer files too large to fit on a floppy. With Minix 2.0.3 the old dosdir, dosread, and doswrite utilities are not provided on the install floppy, instead mtools is provided. But using mtools was not intuitive for me and the documentation I could find wasn't entirely satisfactory.

Aside: the dos* tools are less useful than they used to be, because as written they don't support large Windows file systems. For this reason I have been in the habit of creating a relatively small primary Windows partition (25M to 50M) on my Minix systems, in addition to the usual large partition from which Windows normally runs. This is a little irksome, since only four primary partitions are allowed per hard drive.

There is no mtools man page for Minix 2.0.3. Mtools for Minix helpfully contains its own help system, and if invoked with no arguments a "Usage" message tells you which commands are available and how to get additional help. But I couldn't figure out how to use mtools to see directories or copy files. Finally I found there is an mtools man page for Minix-vmd 1.7.0 (at http://www.minix-vmd.org/pub/Minix-vmd/ 1.7.0/wwwman/man1/mtools.1.html). The key piece of information I was missing is that mtools uses a colon (':') on the end of a device name to indicate the device is a FAT file system. So, to see my Windows C:\ directory from a standard Minix install I need to say

    mtools dir c0d0p0:

and from a DOSMinix install it is

    mtools dir c1d0p0:

I was not able to get mtools to work on a 386 system with 8M RAM. Out of the box mtools is chmem-ed to use a lot of memory (11,534,336 bytes), more than is available on this machine. But it would not work for me when chmem-ed to values low enough to fit in the user memory available. [2005 Note: I had other problems with this 386 system which were never resolved except by getting rid of it, which I should have done long ago anyway. See below for other problems observed with Minix 2.0.3 on slow old systems.]

4. Using man pages. After unpacking the various .TAZ archives I thought the man command should work, but it would not. All the components were in place: /usr/man was populated, and the man, nroff, and more commands existed. I fact I could read a man page by explicitly specifying the elements:

    nroff -man /usr/man/man1/ls.1 | more

But a simple

    man ls

didn't work.

I found the next time I started up the man command did work properly. I haven't figured out what happened. My guess is that something was invoked during login that hadn't been available earlier. I note that the PAGER environment variable is now defined; I'm not sure it was defined earlier.

I soon found that PAGER, as well as EDITOR and PATH, are redefined in ast's .ashrc installed when unpacking SYS.TAZ. The new .ashrc provided with 2.0.3 does a lot more than the old version I had been using.

Other things still wrong with man and friends: although apropos works, whatis does not. They are both links to the same script. Also, man -k (equivalent to apropos) works but man -f (equivalent to whatis) doesn't work. I think these may be bugs. [2005 Note: These do seem to be bugs. I still have these problems on a 2.0.3 system but there is no problem on a 2.0.4 system. The man binaries on these two systems are identical.]

6. Shutdown problems with a 386. On gateway I started having "fatal file system panic: tried to free unused block" errors when I tried to boot. I gained control by booting to single-user mode (boot -s) and doing fsck on /usr/ The problem was due to /usr/run/cron.pid. This should be deleted at shutdown but it's not being done right. I consulted with Kees, he has seen a similar problem on a 286. He suggests putting one or two sync() calls before the reboot()in commands/reboot/halt.c, and predicts this will make the problem disappear. However, he thinks there is a bug in FS -- this won't fix the bug, but it will avoid it. [2005 Note: This was seen only on the 386, which, as noted above, I disposed of.]

7. The find command gives error "can't get path from environment" -- [2005 Note: That's all I wrote in 2002, I don't remember any more details. I don't see this problem any more on any of my Minix systems but I can't remember what fixed it.]

8. Shell and script problems. This is all being added from the 2005 perspective, I didn't recognize these problems in my initial round of upgrades. In Minix 2.0.2 and earlier versions ash is the shell for ordinary users, but the older and simpler Minix sh is root's shell, which means it is also what is used to execute shell scripts. With 2.0.3 ash became root's shell. It's more powerful, and according to Kees, if there is a difference between the behaviors of ash and sh, ash is probably the one that behaves more like a "standard" Unix shell.

That's all well and good, but the fact is that on the Minix systems I use as servers I had written a lot of shell scripts to do various things -- analyze logs, generate messages, convert text files into html -- and they all worked fine with the old Minix shell. And when I ran them under the new shell some of them broke.

Minix 2.0.3 still includes the old Minix shell, under the name of msh and some of the problems I had with scripts that seemed to be about differences in quoting special characters were cured by using msh. However, some of my scripts still didn't run right. I finally figured out the problems were due to the amount of data one could feed through a pipe. Some of my scripts, for instance the ones that generate web pages, work by piping chunks of text (like directory information) and chunks of html boiler-plate text (for instance the tables that generate the links at the bottom of my pages) to an output file. In some cases boiler plate is generated by here documents in the scripts. I found that when the quantity of text I wanted to feed through a pipe this way became too great some of it got lost.

I've also seen a possibly related problem when working over a network to a Minix machine using telnet, which I do a lot. Sometimes the shell seems to freeze up, and will remain unresponsive for an inconveniently long time, sometimes forever. It usually happens when I'm typing fast, especially if I'm making a lot of cursor movements around the screen while editing a file. I also often see a remote Minix 2.0.3 system freeze up when I am working over the network and try to paste in a large chunk of text that I have cut from a window open on another system. I don't know whether this is a network or a system problem. It seems to be something that happens on 2.0.3 and 2.0.4 systems, and not so much on 2.0.2 systems.

Final note

I'm pleased with the systems I now have running Minix 2.0.3 and 2.0.4. (Actually, the "2.0.3" system is a hybrid, it's still running a 2.0.3 kernel but many programs have been updated.) Some of the problems I encountered were surely my own fault, for not reading the Changes documents carefully or not looking carefully at new versions of scripts such as /etc/rc and /usr/etc/rc or .ashrc, changes in all of which caused some of my problems. But in my defense I'll say that there were good reasons why I wasn't ready to just drop a new /etc/rc into my systems -- for instance, one of my Minix servers runs in a remote location where I don't have daily access (and, in fact, where I have not visited it for over two years), and I have a fairly elaborate customized /etc/rc that does a lot of logging, including grabbing output from the console screen, and that starts the system slowly, so if need be I can trigger a reboot and log on with telnet before other servers are running.

At this writing I am still running Minix 2.0.2 on Minix machines I use as public web servers. I have been running Minix 2.0.3 and 2.0.4 on other systems that are similarly configured and used, except they are not available to the public. I'm almost ready to convert the public systems to Minix 2.0.4, but it has taken a lot longer for me to get to this point than I had expected it would when I first started upgrading from Minix 2.0.2. I have a life and I have other work, and some of the delay has been my choice, of course. And I don't really have reason to expect that Minix upgrades should be easy -- the primary intended user of a Minix system is, after all, a student using Minix to learn operating system principles, and such a user would not normally be expected to need to upgrade an existing system configured in an idiosyncratic way.