NODOWS

I decided to install etckeeper. It went ahead with an initialization after install on my debian machine, which somewhat surprised me, but not a big deal.

Looks like its a fairly standard git repository, but the README says that it has special support to handle changes caused by upgrades and installations - which I think includes hooks for pre and post installations. Sounds to me like it automatically tracks changes. Cool!

How does this effect NODOWS? I'm not quite sure yet, but I think the first step will be to move the NODOWS codebase to git.

There has got to be something cool that can be done with embedded systems, git and etckeeper.

I've been thinking about configuration management for some time, and on a totally unrelated topic - bookkeeping - I might have some cool ideas in the works.

It may be that reading and writing are completely different paradigms.

Based on the wonderful experience I've had using yui-app-theme with Regdel, I'm planning to use it with NODOWS as well.

In other news, I'm thinking of using Ruby to power NODOWS in general, and switching from Subversion to Git for code revision system.

It took some serious reworking of the mindeb.xml and the use of an old busybox static binary, but I'm happy to report that NODOWS can now again build an operable (although its very rough at the moment) mindeb image!

Todo:

• Autobuild busybox with insmod support (why doesn't the debian busybox-static include insmod??)
• Learn about cross-compiling

General notes:

• Kernel 2.6.30 uses ide-gd_mod.ko instead of ide-disk.ko
• Squashfs is now in the mainline kernel tree
• Aufs2 has a ways to go before it gets mainlined, but patches work at the moment

Its difficult to stop working on a project for 9 months in mid-stride and then pick it up again and remember where I left off.

Right now I'm trying to get mindeb to build and I'm stuck trying to get grub to install properly. For some reason, it looks like the last few builds I successfully made back in February of 2009 depended upon a copy of a disk image I backed up before removing the backup target from the mindeb.xml build file. Doh!

I think that I need to:

• Turn off squash
• chroot-setup
• rsync-temp (restoring this back into mindeb.xml)
• cleanup
• Turn on squash
• chroot-setup
• Run qemu / kvm to install grub
• finalize

Hopefully that is all that's needed to get mindeb image builds working again.

UPDATE: All that might not be necessary. I might be able to just copy the grub files from the squash image, before it is squashed, that is! I do not want to require two different manual paths for squash and non-squash builds!

UPDATE 2: I still haven't figured out what I want to do about the backup image, but I've also come to realize that for mindeb I ended up taking a different approach when I last left development on NODOWS: the use of debootstrap and make-kpkg (from kernel-package). The target names are "go-go-ve" and "go-no-ve". Several packages have changed / evolved from lenny to squeeze. I've updated those and am continuing to try out the builds...

Today I finally found an iota of time to resume work on NODOWS. Unfortunately I spent a bunch of time realizing that gnu-fdisk does not play well with command line scripting.

Now I'm focusing on just getting back up to speed, testing out mindeb builds, and continuing to move more development notes from the Trac wiki to Ikiwiki.

UPDATE: I've made it through the phing build process for mindeb, but so far I've been unable to get an image that will boot with kvm or qemu. I definitely forgot to do the grub-setup, but I just tried it and it didn't work, so I must have forgotten something else. In the process, I recall that chroot-setup is an important task!