First off I'm not a kernel hacker so apologies if I've got terms wrong and such like.
Second, I must explain our environment: A small single-board computer (no, NOT a Raspberry pi, but similar style) which runs Linux / Busybox based on an SDK / dev stack supplied by the (disinterested) SoC manufacturer and basically hacked together by hordes of Elbonian code slaves with zero support.
An old-ish kernel build and Busybox means we don't have access to a LOT of the commonly used more modern Linux commands/tools,
modprobe being the especially relevant one here.
While we have done our best to exorcise great swathes of WTFery, it's still a work in progress.
Which brings me to where we are now:
In an attempt to clean up the kernel build by removing/disabling things which are not required, I hit the snag that if I disable something we can live without (for example, CONFIG_DEBUG_FS), a whole heap of modules fail to load (using
insmod in the boot process), for example:
[ 16.490979] loop: disagrees about version of symbol set_blocksize [ 16.497116] loop: Unknown symbol set_blocksize (err -22) [ 16.503304] loop: disagrees about version of symbol ioctl_by_bdev [ 16.509440] loop: Unknown symbol ioctl_by_bdev (err -22) [ 16.515656] loop: disagrees about version of symbol set_user_nice [ 16.521898] loop: Unknown symbol set_user_nice (err -22) [ 16.527686] loop: disagrees about version of symbol add_disk
The issue is that the kernel itself resides in one partition of the device's flash, and the user file system (including Busybox and the aforementioned modules) reside in another partition, along with the flash upgrade tools. The upgrade routine downloads & flashes a partition at a time.
So we hit a catch 22 situation: If we update the Kernel image, we risk the board failing to boot because the .ko modules on the file system image are not yet updated, but if we update the file system image we risk the board not booting because the kernel is not yet updated.
Although there's some ways we could work around this, they risk giving customers the opportunity to brick the board by not following instructions (and if it's possible to break it, someone will manage it).
So my question is:
(How) can we modify the kernel (mostly, removing things) and/or rebuild the modules such that we can move from one build of kernel + modules etc. to a newer one without the interim risk of awful breakage and failure?