As one of five, I've been chosen for participating in Google Summer Of Code (GSoC) this year for NetBSD. My project is to write a binary upgrade tool for NetBSD, optionally with a “live update” functionality.
Why an upgrade tool? – Yes, updating currently is easy. You download the set tarballs from a mirror, unpack the kernel, reboot, unpack the rest, reboot, and done. But this is an exhausting procedure, and you have to know that there are actually updates, and what they affect.
The goal is to simplify and stabilize this procedure. The finished script should also automatically check whether there are updates, and inform the administrator if there are some, without forcing him to read mailing lists to know about them. There are many small caveats that have to be taken care of when upgrading the system: Verifying the signatures of the sets, making backups, running etcupdate properly, ignoring some special files, etc. There also is the server side of the project: You have to automatically supply signatures and mtrees from the recent release.
While there is already the tool
systools/sysupgrade written by jmmv last year, this project's goal is to refine this idea and integrate it into the base system. The “great idol” is
freebsd-update(8) from FreeBSD, but with a more flexible way of changing releases and the possibility tracking NetBSD-current builds. As I already have commit access to NetBSD, there is no need to make the mentors care for the integration, I can just do it myself.
This will take up most of the work of the first half of the project, until the code is written, tested and integrated. Then, there is the “research” part: The “live upgrade” functionality. Optimally, after the upgrade, you boot into the new environment and have the chance to test it. If the upgrade does not work as expected, you should have the chance of just booting into the old environment and then continue running the old system. But the question is how to implement this:
Only the second way is currently supported without further code modifications, but it is the one requiring the most effort by the user: You have to think about the free partition when doing the installation, and if you failed to do so, you have to cope with resize_ffs(4).
So, one of the other ways is preferrable and the second part of the project is to investigate and maybe integrate this live upgrade functionality.