Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use a different source for our os-release vars #2907

Open
Tracked by #2909
Itxaka opened this issue Oct 1, 2024 · 5 comments
Open
Tracked by #2909

Use a different source for our os-release vars #2907

Itxaka opened this issue Oct 1, 2024 · 5 comments
Labels
blocked bug Something isn't working

Comments

@Itxaka
Copy link
Member

Itxaka commented Oct 1, 2024

Kairos version:

latest, ubuntu

CPU architecture, OS, and Version:

all

Describe the bug

if someone creates a derivative version and upgrade the system, there is a possibility of the upgrade overwriting the os-release file, which makes it lose our variables, thus breaking the system in several places.
One example of this is a base ubuntu 24.04.01 which was upgraded to 24.04.02 and then it didnt boot anymore as the upgrade overwrote the os-release file to update the versions

This affects EFI systems only as we run a workaround for Ubuntu EFI and we need to identify the system as being ubuntu.

To Reproduce

Get a base ubuntu 24.04.01 kairos image, run apt-get upgrade and build/upgrade to that image. It wont boot anymore

Expected behavior

If vars are not available on os-release, we have a backup file to read them for.

Logs

Additional context

The idea here would be to have 2 files.

  • /etc/os-release to keep backwards compatibility
  • /etc/kairos/info.yaml with the info about the system, version, etc...

Then make everything that reads os-release to get info, read first /etc/kairos/info first, then fallback into os-release
And with time, deprecate writing to os-release as much as possible as its owned by the OS/Distro

We could even during the transition time, just on initramfs check if the info its on /etc/os-release and if its not, fill it with the info from the info file so we can keep the same behaviour as before, but not be vulnerable to changes from the OS. So have it filled on runtime, but actual info is in a different place.

Then we can deprecate havint he info in there if we want or keep it that way.

Reported on community slack, real case.

@Itxaka Itxaka added bug Something isn't working triage Add this label to issues that should be triaged and prioretized in the next planning call unconfirmed labels Oct 1, 2024
@Itxaka
Copy link
Member Author

Itxaka commented Oct 1, 2024

requires changes to:

@Itxaka
Copy link
Member Author

Itxaka commented Oct 1, 2024

Ideally we would not need to to keep a lot of the fallback in place for the following.

  • kairos: If we build with kairos-release then thats it, no need ot keep os-release as fallback as the images will have the stuff in kairos-release
  • agent: only reset and install use them and those will be shipped in the new kairos version that only ship kairos-release, so we would not need to fallback

For this is necessary:

  • grub config: this is needed as you can have an updated active but not passive/recovery so we still need it there
  • static configs: Still needed due to reasons above, booting from an old recovery would not work as expected (its only a printed line that uses it, but still)
  • enki+osbuilder: Needed because you can use an updated osbuilde/enki to build an older version

@Itxaka Itxaka added blocked and removed unconfirmed triage Add this label to issues that should be triaged and prioretized in the next planning call labels Oct 1, 2024
@Itxaka
Copy link
Member Author

Itxaka commented Oct 1, 2024

blocked until patch release for 3.2.x is done

@jimmykarily
Copy link
Contributor

This one is full of os-release logic too: https://github.com/kairos-io/kairos-sdk/blob/main/versioneer/versioneer.go

@jimmykarily
Copy link
Contributor

This one is full of os-release logic too: https://github.com/kairos-io/kairos-sdk/blob/main/versioneer/versioneer.go

I see we changed some things here but we may have to rename some functions to not imply /etc/os-release anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked bug Something isn't working
Projects
Status: No status
Development

No branches or pull requests

2 participants