Skip to content

set_lsb_release: define Flatcar sysext level#252

Merged
pothos merged 1 commit intomainfrom
kai/define-sysext-level
Mar 10, 2022
Merged

set_lsb_release: define Flatcar sysext level#252
pothos merged 1 commit intomainfrom
kai/define-sysext-level

Conversation

@pothos
Copy link
Copy Markdown
Member

@pothos pothos commented Mar 10, 2022 •
edited
Loading

Sysext images have a compatibility matching mechanism that searches for
the matching OS version or custom sysext level setting. On Flatcar
there is just the OS version set in /etc/os-release until now which
means that sysext images can't easily be used together with autoupdates
that change the OS version.

Define a sysext level for Flatcar so that users can refer to it instead
of the OS version when they have images that don't rely on a particular
Flatcar version.
Here an example of the now possible metadata:
/etc/extensions/NAME/usr/lib64/extension-release.d/extension-release.NAME
ID=flatcar
SYSEXT_LEVEL=1.0
and a symlink /etc/extensions/NAME/usr/lib→/etc/extensions/NAME/usr/lib64
In the future the matching logic hopefully gets more flexible because
now it is just a string comparison. Also, the architecture is not
matched either for now - we should work with upstream to improve this.

Closes: flatcar/Flatcar#643

How to use

Check that the above example works with systemd-sysext merge or systemctl enable --now systemd-sysext

Testing done

started

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

@pothos
Copy link
Copy Markdown
Member Author

pothos commented Mar 10, 2022

Ouch, when testing I realized that /usr/lib on Flatcar is just a symlink and now it gets mounted over and everything breaks^^

@pothos
Copy link
Copy Markdown
Member Author

pothos commented Mar 10, 2022

Ouch, when testing I realized that /usr/lib on Flatcar is just a symlink and now it gets mounted over and everything breaks^^

works when using an additional symlink in the sysext itself

@t-lo
Copy link
Copy Markdown
Member

t-lo commented Mar 10, 2022

Ouch, when testing I realized that /usr/lib on Flatcar is just a symlink and now it gets mounted over and everything breaks^^

Joaquim ran into his when initially playing with sysext on Flatcar, we discussed it with Lennart and he agreed it's a bug that should be fixed. Not sure if they are tracking it though.

@pothos
set_lsb_release: define Flatcar sysext level
7fafef2 
Sysext images have a compatibility matching mechanism that searches for
the matching OS version or custom sysext level setting. On Flatcar
there is just the OS version set in /etc/os-release until now which
means that sysext images can't easily be used together with autoupdates
that change the OS version.

Define a sysext level for Flatcar so that users can refer to it instead
of the OS version when they have images that don't rely on a particular
Flatcar version.
Here an example of the now possible metadata:
/etc/extensions/NAME/usr/lib64/extension-release.d/extension-release.NAME
  ID=flatcar
  SYSEXT_LEVEL=1.0
and a symlink /etc/extensions/NAME/usr/lib → /etc/extensions/NAME/usr/lib64
to work around the problem that using lib/ as path destroys Flatcar's
lib → lib64 symlink.
In the future the matching logic hopefully gets more flexible because
now it is just a string comparison. Also, the architecture is not
matched either for now - we should work with upstream to improve this.

Closes: flatcar/Flatcar#643
@pothos pothos force-pushed the kai/define-sysext-level branch from f0547c1 to 7fafef2 Compare March 10, 2022 17:16
@pothos pothos merged commit e7e9c7a into main Mar 10, 2022
@pothos pothos deleted the kai/define-sysext-level branch March 10, 2022 17:16
@krnowak
Copy link
Copy Markdown
Member

krnowak commented Mar 11, 2022

Just a note - it probably won't be a symlink when we finally switch to the 17.1 profile portage is moaning about forever.

@jepio
Copy link
Copy Markdown
Member

jepio commented Mar 11, 2022

its also not a symlink on arm64, so we need to fix this to get sysext ready.

@pothos
Copy link
Copy Markdown
Member Author

pothos commented Mar 11, 2022

Just a note - it probably won't be a symlink when we finally switch to the 17.1 profile portage is moaning about forever.

Does this mean lib64 would be the symlink or to have two directories?

We have to solve this first or the sysext images get breaking changes later…

@krnowak
Copy link
Copy Markdown
Member

krnowak commented Mar 11, 2022

Just a note - it probably won't be a symlink when we finally switch to the 17.1 profile portage is moaning about forever.

Does this mean lib64 would be the symlink or to have two directories?

From news page about the profile:

In the new profiles, the lib->lib64 compatibility symlink is removed.
64-bit libraries need to be installed directly to lib64.  /lib
and /usr/lib become real directories, that are used for cross-arch
and native non-library packages (gcc, clang) and 32-bit libraries
on the multilib profile (which improves compatibility with prebuilt x86
packages).

So IIUC that means that /lib won't be a symlink to /lib64, and /usr/lib won't be a symlink to /usr/lib64. So it has nothing to do with /lib actually pointing to /usr/lib or /lib64 to /usr/lib64 - that's a split-usr stuff, that will also need a look at, because I think I saw some message in systemd that it's going to be deprecated and removed…

We have to solve this first or the sysext images get breaking changes later…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@jepio jepio jepio approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

[RFE] Define sysext level for Flatcar

4 participants

@pothos @t-lo @krnowak @jepio