Skip to content
This repository has been archived by the owner on May 30, 2023. It is now read-only.

Split lib and lib64 for sysext support #1713

Merged
merged 7 commits into from
Mar 17, 2022
Merged

Split lib and lib64 for sysext support #1713

merged 7 commits into from
Mar 17, 2022

Conversation

pothos
Copy link
Contributor

@pothos pothos commented Mar 11, 2022

  • profiles: disable SYMLINK_LIB
    The profile Flatcar is on had SYMLINK_LIB set for amd64 which set up
    (/usr)/lib as symlink to (/usr)/lib64. This is not the case for arm64
    nor common in other recent distributions and causes systemd-sysext
    loading to fail.
    Disable SYMLINK_LIB for the amd64 board for now, leaving the SDK as is
    but we could also set it for the SDK, too. A future profile update will
    also bring this change.
  • coreos-base/coreos-init: create compatibility symlinks
    The split of /usr/lib64 into /usr/lib and /usr/lib64 means that paths
    to /usr/lib64/X that worked before now wouldn't.
    Therefore, create compatibility symlinks.
  • coreos-base/coreos-init: add helper service to start sysext services
    This pulls in
    systemd: add helper service to start sysext services flatcar/init#65
  • sys-apps/systemd: enable systemd-sysext.service
    The systemd-sysext.service activates sysext images on boot.
    Enable it by default.
  • sys-apps/baselayout: force link creation in tmpfile rule
    The /lib symlink does not point to /usr/lib but instead points to
    /usr/lib64 on current releases which have a single /usr/lib64 folder
    and a symlink from /usr/lib to it. This means that when they update to
    a release with a split lib vs. lib64 setup, the kernel modules are not
    found because /lib/modules does not exist (because /lib still points
    to /usr/lib64 instead of /usr/lib).
    Force link recreation to match the new layout. The system will still be
    able to rollback because the link to /usr/lib is still valid because
    /usr/lib is itself a link that forwards to /usr/lib64.
  • coreos-base/coreos-oem-gce: use usr/lib/systemd folder
    The lib64/systemd location only happened to work through the used
    symlink on Flatcar. The standard location is lib/systemd.
    Use the standard location as we now want to split the libs folders.

How to use

together with flatcar/scripts#255

Testing done

Full tests

Manually executed the L+ tmpfile on a split-lib system that got updated from last Alpha, which got it into a working state, then rolled back and the system worked, too

Tested sysext images for custom Docker and a converted Torcx image from https://github.com/flatcar-linux/flatcar-docs/pull/232/files

  • Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)

@pothos pothos force-pushed the kai/no-lib-symlink branch 3 times, most recently from 9af23f6 to b34475c Compare March 16, 2022 09:15
@pothos pothos changed the title profiles: disable SYMLINK_LIB Split lib and lib64 for sysext support Mar 16, 2022
The /lib symlink does not point to /usr/lib but instead points to
/usr/lib64 on current releases which have a single /usr/lib64 folder
and a symlink from /usr/lib to it. This means that when they update to
a release with a split lib vs. lib64 setup, the kernel modules are not
found because /lib/modules does not exist (because /lib still points
to /usr/lib64 instead of /usr/lib).
Force link recreation to match the new layout. The system will still be
able to rollback because the link to /usr/lib is still valid because
/usr/lib is itself a link that forwards to /usr/lib64.
The profile Flatcar is on had SYMLINK_LIB set for amd64 which set up
(/usr)/lib as symlink to (/usr)/lib64. This is not the case for arm64
nor common in other recent distributions and causes systemd-sysext
loading to fail.
Disable SYMLINK_LIB for the amd64 board for now, leaving the SDK as is
but we could also set it for the SDK, too. A future profile update will
also bring this change.
The split of /usr/lib64 into /usr/lib and /usr/lib64 means that paths
to /usr/lib64/X that worked before now wouldn't.
Therefore, create compatibility symlinks.
@pothos pothos marked this pull request as ready for review March 17, 2022 11:26
@pothos pothos requested a review from a team March 17, 2022 11:26
changelog/changes/2022-03-10-systemd-sysext-service.md Outdated Show resolved Hide resolved
sys-apps/systemd/systemd-250.3.ebuild Outdated Show resolved Hide resolved
The systemd-sysext.service activates sysext images on boot.
Enable it by default.
The lib64/systemd location only happened to work through the used
symlink on Flatcar. The standard location is lib/systemd.
Use the standard location as we now want to split the libs folders.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
3 participants