This directory doesn't exist all the time, e.g. if the kernel was built
without modules or no modules were installed for some reason. Assume the
kernel package knows what it is doing and just print a message that
might be helpful if the kernel package ends up not knowing what it is
doing.
The getopt thing was an experiment, and I'd rather lose external
dependencies than use getopt-like parsing especially since the only
argument this app takes is largely for testing/development purposes
only.
It has been determined that this test isn't really necessary. busybox
gzip is probably not going to break (and would be discovered elsewhere
too if it does...)
fixes#4
I misread what strings.Trim does, the 2nd param is a _cut set_, so this
was removing any occurance any characters in the 2nd param. Since the
file extension is always a suffix, this uses TrimSuffix.
Fixes a bug where 'virtio_blk.ko' was being trimmed to 'virtio_bl'
the characters - and _ are indistinguishable for module names, to the
kernel. But obviously are different when it comes to filenames/paths...
so this fixes an issue where the module was previously not found if it
was specified in config with the opposite - or _ than what the real
filename for the module had.
A custom extract test includes reading AND writing the extracted archive
contents to /tmp (which is probably a slow disk), so this uses busybox's
gzip -t ("test file integrity") and seems to take about half the time
(~10s vs ~6s measured loosely on pinephone)
The free space check, checksumming, and moving to the final location
will be outsourced to "boot-deploy", so the verification done here is
just to extract the archive to make sure it is valid.
This adds several steps to the "write" action, by writing it to a temp
location, extracting it, checksumming it, copying to destination,
verifying checksum, and using Rename to atomically replace any existing
file in the destination.
This uses sha256 which, after benchmarking, doesn't seem to be any
faster or slower than sha1. md5 was surprisingly slower (on aarch64),
maybe because there are some CPU accelerated things in sha* ?
