:: [DNG] real-world boot system modifi…
Inizio della pagina
Delete this message
Reply to this message
Autore: Rainer Weikusat
Data:  
To: dng
Oggetto: [DNG] real-world boot system modification
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.