Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a rebase on top of 2022.1. Here's a list of our commits on master relative to our previous 2020.8:
I think it's time to cut the cord on these two. The last time the ostree client would pull these legacy files was in EOS 2.3(!). Even if someone followed the manual EOS 2 to 3 upgrade, the chances that one of the commits that was pulled from that time hasn't been pruned away is very low. I would say the systems this affects is 0.
See ostreedev/ostree#1612. I think the last comment from jlebon makes sense but I haven't looked into the feasability. Will file a task to upstream this.
This is really unfortunate. The upstream way to handle this is to specify the bootloader in the repo config like so:
Maybe we should start having the image builder setup repos that way and add another ugly eos-boot-helper script to set it on existing repos so we can someday rely on it. Will file a task to handle that. The other part of reliably saying
bootloader=none
is that we could stop trimming the ostree-boot package.Ugly hacks to make ostree work when
/boot
is a FAT filesystem like when it's the UEFI ESP on PAYG. GNOME OS developer has a nicer solution in ostreedev/ostree#1967, but I don't believe it's ready yet. Will file a downstream task to clean this up.From debian/patches. We could probably drop this as I've never seen this failure locally or in OBS. From other discussions it sounds like debian's s390x builder has other problems. Leaving it for now.
Upstream backports.
Another FAT hack. See above.
Upstream backports.
https://phabricator.endlessm.com/T32964