Tracking Current
1. What does it mean?
Public releases are done at certain milestones, but development is continuous. Currently, all MINIX 3 sources are kept in a Subversion repository. The state of all of the newest versions of the files in Subversion is called 'current', after BSD convention. You can update your own MINIX 3 installation with these sources, and so get a 'current' system. Doing this 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 Subversion steps elsewhere, copy the 'src' hierarchy to /usr/src on your MINIX machine, and follow the steps from there as normal.
2. Warning
Here be dragons. Finding unexpected bugs and incompatabilities is par for the course when tracking current. By and large, you are on your own if anything goes wrong, although you can always 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.
3. Obtaining the Sources from Subversion
- You'll be grabbing a new /usr/src tree, which will also contain Subversion metafiles, so move your old /usr/src tree somewhere safe as root if it isn't a Subversion tree already.
# cd /usr # mv src src.release # mkdir src # chown bin src
- Obtain a Subversion client, e.g. by using packman and selecting the subversion package. You can do the rest of these instructions as bin.
- Do the SVN checkout of the trunk of the source:
$ svn --username anonymous checkout https://gforge.cs.vu.nl/svn/minix/trunk/src
- Press Enter when prompted for a password. A lot of output follows if all goes well.
Read docs/UPDATING for any tips you may need.
Now you have the bleeding edge of sources installed under /usr/src, and you can update to a later bleeding edge by saying
$ svn update
at any time in the future, from the top of the hierarchy you want updated (/usr/src or lower). When updating like this, you don't have to repeat earlier steps.
4. Recompiling the System
NOTE: The system should be compiled using cc and as and NOT the GNU Toolchain (gcc, etc.).
To understand how to recompile the system, consider the following basic system units:
- etc files
- include files
- libraries
- kernel, servers, drivers
- commands
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 have to be generated. When building a system from scratch, /etc files have to be installed first, and the basic hierarchy with proper permissions and ownerships has to be created.
So the proper build order after getting a new Subversion 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 this 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 Subversion checkout is as follows:
$ cd /usr/src $ make world
This 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 with the new libraries.
Make world does nothing with the 'etc files'. Sometimes it may be necessary to get new or updated etc files. There is no automated procedure for this, though. Compare files in src/etc and /etc and see if any updates have happened.
5. Rebooting
To boot your new image, see that your 'image' boot environment variable is set to '/boot/image' (the default). This means the newest image from /boot/image will be booted.
You should check to make sure that the just-installed image does indeed have the newest modification time. If that is all in order, reboot your system by saying:
# reboot
as root. If all goes well, your new system will come up normally. If something goes so wrong that you can't boot, boot your previous image by setting the image boot monitor variable, and booting:
c0d0> image=/boot/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, this can happen. Depending on your MINIX expertise, you'll be able to fix this by, for instance, booting from CD and recompiling your old (saved) source tree, or simply reinstalling.
6. GCC
The above procedure doesn't take the rebuilding required for the system libraries for GCC into account. If you have GCC installed, you can update your system libraries in /usr/gnu/lib by doing this in /usr/src/lib, as bin:
$ cd /usr/src/lib $ PATH=$PATH:/usr/gnu/bin $ make clean all-gnu install-gnu
7. Problems?
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.