Currently kpatch rely on systemd to load all kmods on startup.
This patch aims to enable kpatch to be used on upstart systems.
Limitations:
With systemd, it would be possible to unload all modules by issuing:
systemctl stop kpatch
It was not possible to make a reasonable upstart's equivalent of it, so
to unload the modules it will be necessary to call kpatch explicitly:
kpatch unload --all
I believe this it an non-issue, as it is still possible to unload
the modules by calling kpatch explicitly.
The file /etc/init/kpatch.conf will be installed unconditionally, and
removed on uninstall.
On my tests I have verified that all newly added files by this commit
are also deleted on uninstall.
It was also verified that applied patches are loaded again on startup.
rpmlint does not complain about anything new.
Signed-off-by: Bruno Loreto <loretob@amazon.com>
This release has many fixes and improvements since 0.3.4. The '0.3' was
bumped to '0.4' because of commit 0bb5c106ef ("kmod: restructure
kpatch sysfs tree"), which broke the ABI between the kpatch core module
and the kpatch script, as it changed the sysfs layout.
Other notable changes since 0.3.4:
- The tools underlying kpatch-build have been made more modular, in
preparation for making create-diff-object more generally useful to
other use cases (kernel livepatch, Xen live patching, user space
patching).
- Support for all new upstream kernels up to 4.10.
- KASLR support.
- Many other bug fixes and improvements.
It may be convenient to be able to turn off the automatic loading of
the patches that kpatch.service does. This helps, for example, if a
buggy patch is installed and crashes the system at boot.
This commit allows to specify kpatch.enable=0 in the kernel command
line. In this case, the binary patches will not be loaded automatically,
and the users should be able to remove or replace the offending patches
after the system boots.
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
Remove the dracut support for adding the kpatch modules to the
initramfs. This creates a sizeable delay in installation time and
doesn't offer any added protect over just applying the patches at boot
time using a systemd service. Additional, we are seeing more platforms,
namely atomic and netboot environments, where changing the initramfs
can't be done.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
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.
