Use "inst" instead of "inst_symlink" for insmod, since insmod might not
necessarily be a symlink on some distros. inst_symlink is functionally
the same as inst, with an additional check to make sure that it's a
symlink (which we don't care about either way).
The "kpatch install" command is broken because the kpatch script has
some missing dependencies in the initramfs. Make sure the new
dependencies (readelf and awk) are added to the initramfs.
On RHEL I'm seeing issues with putting the core module in the "extra"
path. On the next depmod run, it gets added to modules.dep, and on a
subsequent kpatch install I see the following errors:
/usr/lib/dracut/modules.d/50drm/module-setup.sh: line 26: /lib/modules/3.10.0-123.4.4.el7.x86_64//weak-updates/kpatch/kpatch.ko: No such file or directory
/usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh: line 14: /lib/modules/3.10.0-123.4.4.el7.x86_64//weak-updates/kpatch/kpatch.ko: No such file or directory
modinfo: ERROR: Module /lib/modules/3.10.0-123.4.4.el7.x86_64/weak-updates/kpatch/kpatch.ko not found.
Until the core module gets merged into Linux, I think we can put it in
/usr/lib/kpatch, which is also where the patch modules are going to be
delivered in the RHEL RPM.
Making sure the other options still work with the kpatch utility for
now, so as to keep backwards compatibility between a newer kpatch
utility and older core modules. We can break this compatibility for
kpatch 0.2.0.
The user-installed vs system-installed dichotomy is confusing. Let's
just have "installed". RPM-installed modules can just call "kpatch
install" in their post-install step.
