build(deps): bump libglnx from ef502aa to 07e3e49
#209
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
If pulling a static delta fails (due to one part of it missing from a mirror, for example), retry the entire pull operation with disable-static-deltas=true. This is a functional, but ugly approach to fixing the problem, and a neater solution may be adopted upstream in future. If so, this commit should be dropped and replaced with the upstream solution: ostreedev/ostree#1612 Signed-off-by: Philip Withnall <[email protected]> https://phabricator.endlessm.com/T22873 Rebase 2018.6 (T23138): Fix a minor merge conflict due to "#ifdef OSTREE_ENABLE_EXPERIMENTAL_API" being gone now.
OSTree recently gained support[1] for recognizing the Debian-style /boot/grub/grub.cfg path in addition to the existing support for the Red Hat-style /boot/grub2/grub.cfg. With this, it decides to run grub-mkconfig in ostree_sysroot_write_deployment_with_options() by calling ostree_bootloader_write_config(). However grub-mkconfig is disabled on Endless OS since the grub.cfg is hand-written and doesn't need updates[2] and therefore returns a non-zero exit status. This causes operations such as "ostree admin unlock --hotfix" and "ostree admin upgrade" to fail. So this commit effectively reverts the Debian grub support, by making _ostree_bootloader_grub2_query() always return TRUE with out_is_active set to FALSE, so that grub-mkconfig is not called and the operations above succeed. In the longer term, Endless should migrate to letting OSTree manage the grub config and drop this patch[3][4]. https://phabricator.endlessm.com/T25195 [1] ostreedev/ostree@74bdf7e17 [2] https://phabricator.endlessm.com/T19614 [3] https://phabricator.endlessm.com/T14870 [4] https://phabricator.endlessm.com/T18848
When trying to deploy on a vfat partitions, such as the EFI ESP, we fail to create the loader symlink, and deployment fails. We'd like to use sd-boot, which only works with the ESP, so we need a way to deploy without using symlinks. For a quick and dirty minimally invasive fix, I've made deployment create a bogus symlink - a text file named loader.sln that contains the name of the real loader dir. I've modified systemd-boot to read these bogus symlinks as well. https://phabricator.endlessm.com/T27040 Rebase 2022.1 (T32964): Handle conflicts with 02b6197 and 9a526bb.
We can now deploy our custom initramfs + kernel efi blobs. This will only happen when we're running in a PAYG system (ie: the kernel cmdline contains eospayg) or when we set the env var OSTREE_DEPLOY_PAYG to force PAYG deployment during image build. https://phabricator.endlessm.com/T27521 Rebase 2020.8 (T31593): Fix conflicts from upstream overlay_initrds feature and dropping flags argument to install_into_boot(). Added a couple more `!payg` to ensure other boot artifacts aren't installed.
Code was introduced to make a symlink from /boot/boot to sysroot, which breaks for us when /boot is FAT (like on PAYG systems) Instead of using our mock-symlink code here, just avoid writing the symlink at all, as it's only for u-boot and syslinux' benefit, neither of which are used in PAYG. https://phabricator.endlessm.com/T31593
This test is expected to fail a small proportion of the time. During the build of ostree 2018.7-1 in Debian, it seems we were unlucky on s390x. Non-deterministic tests are also problematic for autopkgtest, where they can gate migration of our dependencies like GLib, so skip this test unless the caller has opted-in to non-deterministic tests. It would be appropriate to enable this test in environments where failures can easily be retried and are not disruptive to other packages. Signed-off-by: Simon McVittie <[email protected]>
The commit metadata `version` key is well established but getting it for a remote commit is cumbersome since the commit object needs to be fetched and loaded. Including it in the summary additional metadata allows a much more convenient view of what each of the remote refs represents. (cherry picked from commit 6fbf759) https://phabricator.endlessm.com/T33099
lib/repo: Add commit version metadata to summary metadata
This patch makes it so that we mark the .commit file from a static delta as partial before writing the commit to the staging directory. This exactly mirrors what we do in meta_fetch_on_complete() when writing the commit on that codepath, which should lend some credibility to the correctness of this patch. I have checked that this fixes an issue Flatpak users have been encountering (flatpak/flatpak#3479) which results in error messages like "error: Failed to install org.freedesktop.Sdk.Extension.texlive: Failed to read commit c7958d966cfa8b80a42877d1d6124831d7807f93c89461a2a586956aa28d438a: No such metadata object 8bdaa943b957f3cf14d19301c59c7eec076e57389e0fbb3ef5d30082e47a178f.dirtree" Here's the sequence of events that lead to the error: 1. An install operation is started that fetches static deltas. 2. The fetch is interrupted for some reason such as network connectivity dropping. 3. The .commit and .commitmeta files for the commit being pulled are left in the staging dir, e.g. "~/.local/share/flatpak/repo/tmp/staging-dfe862b2-13fc-49a2-ac92-5a59cc0d8e18-RURckd" 4. There is no `.commitpartial` file for the commit in "~/.local/share/flatpak/repo/state/" 5. The next time the user attempts the install, libostree reuses the existing staging dir, pulls the commit and commitmeta objects into the repo from the staging dir on the assumption that it's a complete commit. 6. Flatpak then tries to deploy the commit but fails in ostree_repo_read_commit() in flatpak_dir_deploy(), leading to the error message "Failed to read commit ..." 7. This happens again any subsequent time the user attempts the install, until the incomplete commit is removed with "flatpak repair --user". I will try to also add a workaround in Flatpak so this is fixed even when Flatpak links against affected versions of libostree. (cherry picked from commit 5d3b1ca)
When we clean up from an error, for example copy_file_range() failing while we generate a static delta (perhaps caused by https://gitlab.gnome.org/GNOME/libglnx/-/issues/3 or by a genuine write error), we might free a variant builder that has a non-null parent. Previously, this caused infinite recursion and a stack overflow, repeatedly freeing the same object, but Luca Bruno suggested that the intention here appears to have been to free the parent object. Partially resolves ostreedev/ostree#2525 (the other bug reported in that issue needs to be resolved by updating libglnx to a version where libglnx#3 has been fixed). Signed-off-by: Simon McVittie <[email protected]> (cherry picked from commit 920f85c)
Recent ostree backport fixes
It can be useful to parse the options and initialize the sysroot without actually loading it until later. Factor out the sysroot loading to a new `ostree_admin_sysroot_load` and add a new `OSTREE_ADMIN_BUILTIN_FLAG_NO_LOAD` flag to accommodate this. (cherry picked from commit e30a3b6)
If `/boot` is an automount, then the unit will be stopped as soon as the automount expires. That's would defeat the purpose of using systemd to delay finalizing the deployment until shutdown. This is not uncommon as `systemd-gpt-auto-generator` will create an automount unit for `/boot` when it's the EFI System Partition and there's no fstab entry. To ensure that systemd doesn't stop the service early when the `/boot` automount expires, introduce a new unit that holds `/boot` open until it's sent `SIGTERM`. This uses a new `--hold` option for `finalize-staged` that loads but doesn't lock the sysroot. A separate unit is used since we want the process to remain active throughout the finalization run in `ExecStop`. That wouldn't work if it was specified in `ExecStart` in the same unit since it would be killed before the `ExecStop` action was run. Fixes: #2543 (cherry picked from commit f3db79e) https://phabricator.endlessm.com/T33775
Followup from discussion in ostreedev/ostree#2544 (comment) This is more efficient; no need to have the kernel context switch us in at shutdown time just so we can turn around and call `exit()`. (cherry picked from commit 683e4ef)
Fix staged deployments with automounted /boot
This reverts commit 344474a. All systems have been converted to declare the desired bootloader in the repository configuration `sysroot.bootloader` option. On grub systems this is set to `none` so that only the boot loader spec entries are updated. This and the reverted commit should be dropped during the next upstream rebase. https://phabricator.endlessm.com/T34161
Revert "grub2: Disable use of grub-mkconfig on Endless"
Bumps libglnx from `ef502aa` to `07e3e49`. --- updated-dependencies: - dependency-name: libglnx dependency-type: direct:production ... Signed-off-by: dependabot[bot] <[email protected]>
dependabot
bot
added
dependencies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Bumps libglnx from
ef502aato07e3e49.Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)