This repository was archived by the owner on May 30, 2023. It is now read-only.
Conversation
pothos
force-pushed
the
kai/no-lib-symlink
branch
from
441b8f6 to
158c854
Compare
1 task
pothos
force-pushed
the
kai/no-lib-symlink
branch
from
dc1af29 to
88c628f
Compare
jepio
reviewed
Mar 15, 2022
pothos
force-pushed
the
kai/no-lib-symlink
branch
3 times, most recently
from
9af23f6 to
b34475c
Compare
1 task
pothos
changed the title
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
force-pushed
the
kai/no-lib-symlink
branch
from
23ba755 to
d0af519
Compare
krnowak
approved these changes
Mar 17, 2022
pothos
force-pushed
the
kai/no-lib-symlink
branch
from
d0af519 to
fed0675
Compare
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.
pothos
force-pushed
the
kai/no-lib-symlink
branch
from
fed0675 to
3d11e1c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.
This pulls in
systemd: add helper service to start sysext services flatcar/init#65
The systemd-sysext.service activates sysext images on boot.
Enable it by default.
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 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, tooTested sysext images for custom Docker and a converted Torcx image from https://github.com/flatcar-linux/flatcar-docs/pull/232/files
changelog/directory (user-facing change, bug fix, security fix, update)