Tracking Current

Public releases are done at certain milestones; but development is continuous. Currently, all MINIX 3 sources are kept in a Git repository. A GitHub mirror is also available.

The state of all of the newest versions of the files in the master Git repository (called 'minix', branch 'master') is called 'current', after a BSD convention. You can update your own MINIX 3 installation with those sources; and get a 'current' system. Doing that regularly in the context of MINIX could be called 'tracking current'.

Tracking current consists of first obtaining the current sources, and then recompiling them. The host machine compiling the system is assumed to be a machine running MINIX. And, of course, running your system! This document explains how to obtain and run current.

It does assume a network connection. If you don't have one on your MINIX machine, perform the git steps elsewhere, copy the 'src' hierarchy to /usr/src on your MINIX machine, and follow the steps from there, as normal.

Here be dragons! Finding unexpected bugs and incompatibilities is “par for the course” when tracking current. By and large, you are on your own if anything goes wrong; although, you always can try to ask for help in the newsgroup. Good bug reports, however – if it comes to that – are very welcome.

It's a great way to give new code early exposure; so, everyone who wants to is encouraged to give it a try.

Due to lack of developer time, tracking current is only supported from the latest snapshot of Minix. You can find the latest snapshot here

• You'll be grabbing a new “/usr/src” tree, which will contain Git metafiles also.
• Obtain the toolkit from pkgin_sets

# pkgin up
# pkgin_sets
calculating dependencies... done.
[..]

proceed ? [y/N] y

• Do the git clone of the trunk of the source:

# cd /usr
# git clone git://git.minix3.org/minix src
Cloning into src...

• <!> Read src/docs/UPDATING for any tips you might need. <!>

Now, you have the “bleeding edge” of sources installed under “/usr/src”, and you can update to a later bleeding edge by saying,

# cd /usr/src
# git pull

at any time in the future.

Make build upgrades some but not all etc files. This means that any change you did to the updated configuration files will not survive to the build process. The normal way to customise locally is to store your changes in a .local configuration file which is then read by the system; not all configuration files provide such hooks however.

Sometimes, it might be necessary to update a locally-managed /etc file, like for example to add a new user to /etc/master.password. There is no automated procedure for that, though. Compare the files in “/usr/src/etc” and “/etc”, and see if any updates have happened. This kind of things are typically commented in src/docs/UPDATING.

Now that the MINIX project has switched to using the NetBSD project infrastructure to build the system, much of the work is automatic.

The procedure to rebuild after a Git checkout is as follows:

# cd /usr/src
# make build

That will create the necessary .depend files, and then proceed to install the new includes, build and install the new libraries, build and install the commands (linked with the new libraries), and then rebuild the system (servers, drivers, and kernel), and install it as a new current ready-to-boot system.

The above procedure is conservative and does a full clean and rebuild, which can take a long time. If you are confident your build can be done incrementally, invoke it like so:

# cd /usr/src
# make build MKUPDATE=yes

Sometimes a new version of some upgraded tool is needed, or some operation should be performed for the automatic build to succeed. This is announced as new entries at the top of src/docs/UPDATING, usually with the commands you need to type or the points you should be attentive to.

Please read src/docs/UPDATING before building a newer current system.

Your new system has been installed as /boot/minix_latest, which is the default system the monitor will boot. After the build finishes, reboot your system by typing (as root):

# reboot

When you see the boot monitor's menu, either choose to boot the custom MINIX, or just wait three seconds – the monitor automatically will boot the latest revision that it sees. (Rebuilding the system creates a custom version of MINIX! So, you don't want to boot the original version.)

If all goes well, your new system will come up normally. If something goes so wrong that you can't boot, you can boot your previous image manually using the boot monitor menu: all the system images stored in subdirectories of /boot/minix are given a separate entry in the menu, as well as the system used when installing for the first time which is stored under /boot/minix_default. You can also proceed manually: select the option to Drop to boot prompt and then issue the following commands:

> load_mods /boot/<minix_old>/mod*
> multiboot /boot/<minix_old>/kernel rootdevname=<device>

where <minix_old> refers to the directory containing your previous MINIX system, and <device> refers to the device containing the root file system, usually c0d0p0s0.

If you still have problems then, it could be because the (new) userland is messed up, or the new userland is incompatible with the old image. In rare cases or big upgrades, that can happen. Depending on your MINIX expertise, you'll be able to fix it by, for instance, booting from CD, and recompiling your old (saved) source tree, or simply reinstalling.

If you have problems you can't solve, you can try to post to the newsgroup. The “you're on your own” disclaimer notwithstanding, the object of the exercise is to find problems in MINIX.