Removing rotation of previous revisions

[antoineL]

MINIX 3 on i386 inherited an integrated system to manage several sets of working (really bootable) systems (kernel and the associated boot-time modules) on the same disk, as well as command to install a new system etc. This is very different to the way it is managed in NetBSD (where there is some provision for one previous kernel named .old, and where new kernels are installed with simple cp commands.)

This difference is a major pain, since in cross-compile cases (normal cases for embedded systems) it adds nothing, yet it prevents easy merging and porting of the NetBSD environment.

A solution might be to remove all that inherited stuff from MINIX, dropping all the specific tools like mkboot or update_bootcfg which has no NetBSD equivalent.

Since it will bring us back to the situation we had in 2011, where there were no easy way to keep a working system safe from an update which prevents subsequent booting, we should propose instead some way to keep the previously-working system; mimicking NetBSD way seems a wise idea here.

So I propose that the process to install a new system should be changed to:

• remove minix.old previous back system
• move minix_latest to minix.old
• install new set of kernel and modules into minix_latest

since minix_latest should be the name of the currently working system (a valid proposal could be to rename it to minix.new or just to minix.) It would be a normal directory (right now it is a symlink.)

A clear advantage is that boot.cfg does not need any change to update the system: it would propose two systems.

[boricj]

This issue is linked with #157 where it was discovered that generating tarballs sets on MINIX with make distribution doesn't work because /boot/minix/.temp is moved around in the destination directory when do-hdboot is invoked.

I'd say always compile and install into minix_latest when compiling ; also install into minix when reinstalling with setup.sh / creating an image. The developer may also want to manually copy minix_latest into minix when he's done developing.

Development and stable versions are thus always separated and beyond providing an initial boot.cfg on installation we do not ever mess with it. If the user/developer needs something more fancy he'll do it on his own. This is the simplest solution I can come up with that will not (automatically) hose the system during development.

While we're there, we could also pack all boot modules+kernel into one file except for the ramdisk to mimic the kernel/initrd mechanism of Linux. The current boot mechanism on ARM is a hack, requiring modules to be loaded at fixed, 8 MiB-aligned addresses ; it got really ugly when I had to make the Beagle and the Raspberry Pi port coexist (the RAM banks aren't mapped at the same addresses). U-Boot doesn't natively support anything beyond one kernel and one initrd, so we might as well align ourselves to the lowest common denominator. Also, I can't come up with a scenario where having 10+ independent boot modules would allow something that a simple "kernel" + initrd wouldn't.