kernel: Create kernel-devel squashfs and bind into host containers #701
Conversation
This allows them to be installed into the filesystem image without creating a file conflict over "/usr". Signed-off-by: Ben Cressey <[email protected]>
| What=/usr/share/thar/kernel-devel.squashfs | ||
| Where=/var/lib/thar/kernel | ||
| Type=squashfs |
There was a problem hiding this comment.
I'd like to mount this on /usr/src/kernels so that it shows up in a semi-standard place for bind mounting into orchestrated containers.
There was a problem hiding this comment.
IIRC I went this way because /usr/src is read-only when mounting this; I'll go back and double check.
There was a problem hiding this comment.
The actual issue here ends up being systemd complaining out symlinks in the path; I've worked around this by inserting the correct %{_cross_usrsrc} path into the .mount file at build time, and systemd-izing the filename.
packages/kernel/kernel.spec
Outdated
| @@ -28,7 +28,8 @@ BuildRequires: hostname | |||
| BuildRequires: kmod | |||
| BuildRequires: openssl-devel | |||
|
|
|||
| %global kernel_sourcedir %{_usrsrc}/kernels/%{version} | |||
| %global kernel_sourcedir %{_cross_usrsrc}/kernels/ | |||
There was a problem hiding this comment.
nit: can omit trailing slash
packages/kernel/kernel.spec
Outdated
| done | ||
| mksquashfs src_squashfs kernel-devel.squashfs | ||
| install -D kernel-devel.squashfs %{buildroot}/%{_cross_datadir}/thar/kernel-devel.squashfs |
There was a problem hiding this comment.
nit: ... %{buildroot}%{_cross_datadir} ... to eliminate extra '/' in expanded form
packages/kernel/kernel.spec
Outdated
| # For completeness set up a link in the host to the (eventual) headers location | ||
| install -d %{buildroot}%{kernel_sourcedir} | ||
| ln -sf %{_cross_sharedstatedir}/thar/kernel/%{version} %{buildroot}%{kernel_sourcedir}/%{version} | ||
|
|
||
| # Replace the incorrect links from modules_install. These will be bound | ||
| # into a host container (and unused in the host) so they must not point | ||
| # to %{_cross_usrsrc} (eg. /x86_64-thar-linux-gnu/sys-root/...) | ||
| rm -f %{buildroot}%{kernel_libdir}/build %{buildroot}%{kernel_libdir}/source | ||
| ln -sf %{_usrsrc}/kernels/%{version} %{buildroot}%{kernel_libdir}/build | ||
| ln -sf %{_usrsrc}/kernels/%{version} %{buildroot}%{kernel_libdir}/source |
There was a problem hiding this comment.
If we mount the squashfs at /usr/src/kernels (per comment below), that would also make these links non-broken on the host.
We wouldn't need the "completeness" symlink but would still want the directory.
There was a problem hiding this comment.
The fixup here is separate from the mountpoint; these links by default point to the build tree:
[ec2-user@ip-192-168-11-152 ~]$ ls -l /lib/modules/4.19.75/build
lrwxrwxrwx 1 root root 42 Feb 3 17:56 /lib/modules/4.19.75/build -> /home/builder/rpmbuild/BUILD/linux-4.19.75
|
Pushed a new version to address @bcressey's comments. |
| Description=Kernel Development Sources | ||
| DefaultDependencies=no | ||
| Conflicts=umount.target | ||
| RequiresMountsFor=/var/lib/thar |
There was a problem hiding this comment.
This RequiresMountsFor doesn't seem accurate.
There was a problem hiding this comment.
Whoops, forgot to update that in the latest change.
As part of the kernel build install the kernel development headers into a squashfs file installed onto the Thar host. On boot this will be unpacked to make the headers available, saving a significant amount of space in the root partition. For superpowered host containers host-ctr bind mounts in /lib/modules -> /lib/modules, and /usr/src/kernels -> /usr/src/kernels allowing the kernel headers to be transparently accessed from within the container. Signed-off-by: Samuel Mendoza-Jonas <[email protected]>
|
Updated to remove the old "RequiresMountsFor" line as well as the "DefaultDependencies=no" as this mount has no special dependencies or requirements to be mounted early. |
Issue #, if available:
#680
Description of changes:
As part of the kernel build install the kernel development headers into
a squashfs file installed onto the Thar host. On boot this will be
unpacked to make the headers available, saving a significant amount of
space in the root partition.
For superpowered host containers host-ctr bind mounts in
allowing the kernel headers to be transparently accessed from within the
container.
Signed-off-by: Samuel Mendoza-Jonas [email protected]
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Tested by launching a Thar instance, ensuring the kernel headers are visible in both the host and container, and compiling a module against them successfully.