The powers-which-are have decreed that the process of installing our product has to become more streamlined than "somebody booting from a special-purpose USB device" and then enabling ssh access so that I can do everything else interactively (not an unreasonable request as this procedure obviously doesn't scale). Among other things, this means that I'll no longer compile a custom kernel for each new installation in order to support whatever Dell put into the box this time. Instead, a more "distribution-style" kernel supporting all conceivably useful features and every piece of not totally obsolete hardware via modularized drivers has to be used. Even with a rather aggressive approach wrt "considering hardware obsolete" (10/100? What's that? Nobody uses this!), the resulting kernel + kitchen sink still ends up needing about 160M of disk space and that's way to much for the /-filesystems of existing installations (typically 300M). Extensive brain surgery on these isn't really possible as burdensome people known as 'users' expect them to deliver a service to them.
Harking back to experiences with an earlier embedded OS, I came up with the idea to turn /lib/modules/`uname -r`/kernel into a squashfs image file and mount that over the empty directory early during the system setup stage (/etc/rcS.d) of booting, specifically, before udev gets started. With the sysvinit-system, this was very easily implemented by running mksquashfs on the existing directory, creating a 2-line script doing the mount and integrating that into the rcS-sequence by letting it provide 'modules' and depend on mountkernfs (Required-Start) while changing the udev Required-Start to modules (the first implementation of this is an experiment to detemine if this can be done at all, although this seemed very likely). Hence, 'our' main development server now runs with a compressed kernel modules directory. NB: This may not be the greatest idea on the planet, however, it's going to solve my space problem with two lines of newly written code. And that's quite ok. _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
