#12420 Fedora Atomic Desktops ostree 41 stable refs are not setup properly
Closed: Fixed with Explanation a month ago by kevin. Opened a month ago by siosm.

  • Describe the issue

It looks like the ostree refs are not properly setup for Fedora 41.

Silverblue  41               41-updates       41-testing
x86_64      41.20241025.n.0  41.20241027.0    41.20241028.0
aarch64     41.20241025.n.0  41.20241027.0    41.20241028.0
ppc64le     41.20241025.n.0  41.20241027.0    41.20241028.0
  • When do you need this? (YYYY/MM/DD)

As soon as possible, ideally before the release tomorrow.

  • When is this no longer needed or useful? (YYYY/MM/DD)

N/A

  • If we cannot complete your request, what is the impact?

No updates for Fedora Atomic Desktops 41 users.


There is documentation somewhere how to update those branches to have fedora:fedora/41/x86_64/silverblue point to fedora:fedora/41/x86_64/updates/silverblue but I can't find them right now.

Note that the create part of those instructions will have to be skipped as those refs already exists.

I vaguely remember that we had moved that to a script somewhere but I don't remember where.

So it's mainly https://pagure.io/releng/blob/main/f/scripts/update_ostree_refs.sh but WE SHOULD NOT RUN THIS AS IS as this will delete the update refs that we have right now.

Or maybe we should just run this and forget about the history from this weekend.

We'll have to trigger a new compose to get fresh Atomic Desktops builds.

The docs.pagure.org/releng is the 'old' docs. ;( Apparently this didn't make it into the new ones somehow. :(

So, that script, but with lines 19 and 21 commented/deleted, as we already have the updates ref, we just need to point the main one to it?

You mean another updates compose? Or ?

I'm afraid we got to a point where both have history and I don't know what we should do.

Well, we definitely cannot do another base 41 compose. We have already staged the release and switched everything.

We can (and will do) updates composes.

There shouldn't be anymore history on the base repo after the last compose on thursday... updates should have taken over after that, so I am not sure where we have history for both now?

OK, so let's keep the script as is and run it. This will "rewind" the updates branch to the state of the stable one but you're right that it does not matter and the next compose will update "both".

ok. Should I do a new compose right after (takes 1.5hr or so)?

Ideally yes, so that we get the branch updated immediately

And as always thanks a lot for helping. I realized this late :(

Well, it's only been this way/mattered since friday. ;)

So, I ran the script, will do a f41 compose after this f41-updates-testing finishes.

We need to add this to our stage release doc. So, lets keep this open for that...

Metadata Update from @phsmoura:
- Issue tagged with: medium-gain, medium-trouble, ops

a month ago

Looking good now:

Silverblue  41               41-updates       41-testing
x86_64      41.20241028.1    41.20241028.1    41.20241028.0
aarch64     41.20241028.1    41.20241028.1    41.20241028.0
ppc64le     41.20241028.1    41.20241028.1    41.20241028.0

Kinoite     41               41-updates       41-testing   
x86_64      41.20241028.1    41.20241028.1    41.20241028.0
aarch64     41.20241028.1    41.20241028.1    41.20241028.0
ppc64le     41.20241028.1    41.20241028.1    41.20241028.0

Sericea     41               41-updates       41-testing   
x86_64      41.20241028.1    41.20241028.1    41.20241028.2
aarch64     41.20241028.1    41.20241028.1    41.20241028.2

Onyx        41               41-updates       41-testing   
x86_64      41.20241028.1    41.20241028.1    41.20241028.0

Thanks!

Metadata Update from @kevin:
- Issue close_status updated to: Fixed with Explanation
- Issue status updated to: Closed (was: Open)

a month ago

Log in to comment on this ticket.

Metadata
Boards 1
Ops Status: Backlog