Skip to content

Add OSTree output and remove signed image #49

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 8 commits into from
Aug 11, 2025
Merged

Add OSTree output and remove signed image #49

merged 8 commits into from
Aug 11, 2025

Conversation

@ssssam
Copy link
Contributor

@ssssam ssssam commented Aug 8, 2025 •
edited
Loading

See commit messages for full details.

This PR removes the proof-of-concept "signed image" build, and adds a new toplevel element eos/repo.bst which builds an OSTree repo containing our prototype EOS7. (Which is 99% just GNOME OS).

I've tested this locally by deploying to a clean EOS6 VM, following the steps documented in the README.

As of commit 90425aa, the VM successfully boots into the new OS. The existing user can no longer sudo in the new system (which could be investigated as part of #22). You can force reboot and use the bootloader to reenter the old OS.

Part of #4

@ssssam
Copy link
Contributor Author

ssssam commented Aug 8, 2025

Screencast.From.2025-08-08.17-26-37.mp4

@ssssam
Copy link
Contributor Author

ssssam commented Aug 8, 2025 •
edited
Loading

Issues I spotted so far:

  • Warnings when deploying the new tree about content in /var/
  • Sudoers information is lost
  • GPG key for eos ostree remote seems to be missing
  • OStree commits aren't signed. This will be needed before we can push to the ostree.endlessm.com repo.

@ssssam ssssam mentioned this pull request Aug 8, 2025
Closed
@ssssam ssssam marked this pull request as draft August 8, 2025 16:32
@ssssam ssssam force-pushed the sam/ostree branch 2 times, most recently from a00b953 to d7c0038 Compare August 11, 2025 07:14
ssssam added 7 commits August 11, 2025 11:43
@ssssam
Remove circular dependency
5bd286f 
Introduced in baae943. I missed this when reviewing MR #47.
@ssssam
Add eos/repo.bst element
88be555 
EOS7 now defines its own filesystem instead of reusing the one from
GNOME OS.

The proof-of-concept "signed boot" image is gone.  This is necessary:
the GNOME OS elements define a complete image pipeline, which includes
signing the image and generating the initramfs, and does not support
OSTree.

EOS deploys to OStree and there is existing tooling outside of
BuildStream for signing and image creation.

Some of the files removed in this commit may need to reappear later
with modifications when we implement secure boot.

The new `eos/repo.bst` element is the final stage of the BuildStream
build, producing an OSTree repo that holds the filesystem tree.
@ssssam
Override the bash-config.bst element
0a44426 
The bash-config.bst element in freedesktop-sdk installs files into
/root, which can't work with the OSTree filesystem layout where `/root`
is a symlink to `/var/roothome`.

Strangely, the Freedesktop SDK `minimal-ostree` system manages to stage
bash-config.bst, but with a warning from BuildStream:

    [--:--:--][3050f169][   build:vm/minimal-ostree/filesystem.bst] WARNING [unstaged-files]: Not staging files which would have replaced non-empty directories

        Not staging files which would replace non-empty directories in staging area: /

        From vm/config/ostree.bst:
          /root

This suggests that another element in FDSDK masks the issue.
@ssssam
eos/config/ostree.bst: Avoid installing an 'eos' remote
d77e000 
See comment for rationale.
@ssssam
Match the existing sudo config
688ac2b 
EOS6 uses the default `/etc/sudoers` file from Debian Bookworm. This is
a Debian-specific config file which you can read here:

<https://salsa.debian.org/sudo-team/sudo/-/blob/bookworm/debian/etc/sudoers>

It contains the following rule inline in `/etc/sudoers` that enables
anyone in the `sudo` group to run any command as root:

    %sudo	ALL=(ALL:ALL) ALL

Freedesktop SDK 24.08.22 (in the `vm` elements) uses the `/etc/sudoers`
provided by the upstream project, which you can read here:

<https://github.com/sudo-project/sudo/blob/v1.9.16p2/plugins/sudoers/sudoers.in>

This doesn't enable the `sudo` group rule by default.

For a minimal delta against upstream, EOS7 installs a rule into
`/etc/sudoers.d` adding back the `sudo` group rule, without overwriting
the entire upstream config file with the Debian equivalent.
@ssssam
README: Document the new OSTree output
722cf12
@ssssam
Implement OSTree signing for local development workflow
206b373 
This is a copy of the Freedesktop SDK minimal-ostree workflow.
Note that signing happens outside of BuildStream in a helper script.
The CI pipelines can work the same way.
@ssssam ssssam force-pushed the sam/ostree branch 2 times, most recently from f702424 to f7ab7aa Compare August 11, 2025 11:32
@ssssam
Copy link
Contributor Author

ssssam commented Aug 11, 2025 •
edited
Loading

As of commit f7ab7aa, this is ready for use by early adopters, with the following known issues:

  • The make ostree-repo target fails, but only in CI. (See below)
  • The generated filesystem includes content in /var, which is harmlessly ignored, but triggers a warning at ostree admin deploy time.
  • The EOS ostree signing key is missing in the new system, because eos-keyring package isn't installed.

The issue with sudo mentioned above is now fixed.

Commit signing

I copied the local development workflow from Freedesktop SDK minimal-ostree system. This works on my machine (TM) but fails in CI, as seen in job 47804842712:

5767 metadata, 86389 content objects imported; 0 bytes content written
error: No gpg key found with ID EF6D8C43E6F2B8871A701E301D84B518E61D9C57 (homedir: ostree-gpg)
make[1]: *** [Makefile:40: update-ostree] Error 1
make[1]: Leaving directory '/home/runner/_work/eos-build-meta/eos-build-meta'
make: *** [Makefile:48: ostree-repo] Error 2

The error must be that during ostree commit, the gpgme_get_key() function (called here) returns GPG_ERR_EOF.

  • It only happens in CI -- I tried locally in an Ubuntu 24.04 toolbox, and the error didn't reproduce, so this isn't related to package versions.
  • The key does exist -- the log of that job ran gpg --list-keys as its first step, and the expected key was listed

Going to defer more work on this until the next PR (where we sign the image with real Endless keys) in the hope that it goes away...

Next steps

To close #4, we need a second PR that updates CI to do the following:

  • Fetch necessary keys from the vault
  • Sign the ostree commit with the correct key
  • Use ostree-push to push the commit, with a useful branch name, to the public OSTree server

Also, open followup issue about content in /var

@ssssam ssssam requested review from starnight and zeenix August 11, 2025 12:40
@ssssam ssssam marked this pull request as ready for review August 11, 2025 12:40
zeenix
zeenix approved these changes Aug 11, 2025
View reviewed changes
Copy link
Contributor

@zeenix zeenix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. If it works, ship it! 😆

@ssssam ssssam merged commit efb259a into main Aug 11, 2025
1 check passed
@ssssam ssssam deleted the sam/ostree branch August 11, 2025 14:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@zeenix zeenix zeenix approved these changes

@starnight starnight Awaiting requested review from starnight

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@ssssam @zeenix