coreos/rpm-ostree

ostree-override-layers

Closed this issue · 2 comments

Expected vs actual behavior

I'm trying to run the following command:

rpm-ostree compose tree --repo=repo --layer-repo=repo --cachedir=cache --unified-core '--add-metadata-string=version=PhotonPonyOS 38.20230904.0' fedora-photon-pony.yaml

The goal is to build an new OS and the ISO based on fedora-silverblue.
This is my treefile fedora-photon-pony.yaml.

ref: fedora/38/${basearch}/photon-pony
rojig:
  name: fedora-photon-pony
  summary: "PhotonPonyOS"
  license: GPLv3
boot-location: modules
ostree-override-layers:
  - fedora/38/x86_64/fedora-silverblue
packages:
  - cmake

repos:
  - fedora-38
  - fedora-38-updates

postprocess:
  - |
    #!/usr/bin/env bash
    systemctl enable sshd.service

documentation: false
preserve-passwd: false
# rpm-ostree install somepackage
error: installing somepackage: encountered an error

As a result I always get:

Input state hash: 9573086a4f4e02e1856090385e2d8178da1e98ce403f002835274c7f4802a763
Relabeling...done
Checking out packages...done
Checking out ostree layers...done
error: Copy checkout of 53f85ac7095ea7e28220d2201d0abcadde180e283764084260fca5ea79fcd65f to rpm: unlinkat(rpm): Is a directory

I can not figure out what goes wrong here.

Expected:
I expect rpm-ostree compose tree to create a new commit inside the repo dir for my custom OS based on fedora-silverblue

Steps to reproduce it

1 . Clone https://gitlab.com/fedora/ostree/ci-test
2. just compose silverblue
3. rpm-ostree compose tree --repo=repo --layer-repo=repo --cachedir=cache --unified-core '--add-metadata-string=version=PhotonPonyOS 38.20230904.0' fedora-photon-pony.yaml

Would you like to work on the issue?

Yes, I can look into it but I need some pointers.

Long story short, ostree-override-layers isn't intended to be used in this way. You're asking for fedora/38/x86_64/fedora-silverblue to go on top of cmake, not the other way around.

This relates to #4427 but it's the ostree version of it...hmm, I am sure we have an issue for it. Well there's #442 but basically the focus of this project now is on the container flow.

For now, closing as a duplicate of #442