The glob might result in a vmlinuz-* filename that causes mkinitfs to
copy a modified kernel file to the boot-deploy working directory. This
excludes files that boot-deploy has touched from being copied/used by
boot-deploy
At the moment modules in modules.dep are matched even on a submatch
e.g. looking up "msm" ends up matching "snd-soc-msm8916-digital.ko"
instead of "msm.ko". To fix this, disallow submatches using ^ and $.
An earlier revision of this patch had test for invalid lines, but I
decided to remove it because deviceinfo is sourced by so many things in
pmOS that it should be /very/ obvious that there are invalid lines or
other garbage in the file.
I also tried to make the parser fairly forgiving if it does encounter
things that don't meet the deviceinfo "spec", so that mkinitfs will try
as hard as it can to make an initfs.
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* ?
