Public releases are done at certain milestones; but development is continuous. Currently, all MINIX 3 sources are kept in a Git repository. 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. 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.
# cd /usr # mv src src.release
# pkgin in scmgit-base calculating dependencies... done. nothing to upgrade. 1 packages to be installed: scmgit-base-22.214.171.124nb2 (0B to download, 286M to install) proceed ? [y/N] y
# git clone git://git.minix3.org/minix src Cloning into src...
Now, you have the “bleeding edge” of sources installed under “/usr/src”, and you can update to a later bleeding edge by saying,
$ git pull
at any time in the future.
NOTE: The system should be compiled using
as, and NOT the GNU Toolchain (
To understand how to recompile the system, consider the following basic system units:
The commands, kernel, servers, and drivers depend on the libraries and include files. Everything depends on the include files! Before all of that can work, .depend files and library Makefiles must be generated. When building a system from scratch, “/etc” files must be installed first, and the basic hierarchy with proper permissions and ownerships must be created.
So, the proper build-order after getting a new Git tree is first generating the depend files and the library Makefiles. Then installing the include files, then rebuilding the libraries, and then rebuilding the kernel, servers, drivers, and commands. To make sure old builds are not confusing the issue, an unconditional rebuild is advised.
Fortunately, all of that is automated in the 'make world' build target in the top-level directory. But, if anything goes wrong, it's good to know what is happening behind the scenes.
The procedure to rebuild after a Git checkout is as follows:
$ cd /usr/src $ make world
That will create the necessary .depend files and library Makefiles, and then proceed to install the new includes, build and install the new libraries, and then rebuild the system (servers, drivers, and kernel), install it as a new image, and build and install the commands (linked with the new libraries).
Make world does not erase or upgrade many of the 'etc files'. Sometimes, it might be necessary to update /etc files. 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 usually commented in src/docs/UPDATING.
Another way to do it is to 'git fetch' first, and then (assuming your remote is 'origin' and your local branch is 'master)
git diff origin/master..master -- etc > /usr/tmp/etc.diff
– before you update – to see what will change in the etc files. Then, later, you can patch the “/etc” files with those differences.
To boot your new image, see that your 'image' boot environment variable is set to /boot/image (the default). That means that the newest image from “/boot/image” will be booted.
You should check to make sure that the just-installed image indeed does have the newest modification time. If that is all in order, reboot your system by saying:
as root. (Or, you can type
$ shutdown -r
bin user.) 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, then boot your previous image by setting the “image” boot monitor variable, and booting:
c0d0> image=/boot/image/<name of previous image> c0d0> boot
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.