IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In glib 2.62 this has been changed to emitting a warning. Use G_STRFUNC
instead, which has been available for a long time and is already used in
other places in ostree.
Same as https://github.com/coreos/rpm-ostree/pull/1923
Quoting that rationale:
> Since we're not using Homu anymore (and Tide instead looks at
> all statuses by default), let's just drop it. This brings down the
> number of statuses on PRs by one more (and so one less context to
> override when needed).
zipl is a bit special in that it parses the BLS config files
directly *but* we need to run the command to update the "boot block".
Hence, we're not generating a separate config file like the other
backends. Instead, extend the bootloader interface with a `post_bls_sync`
method that is run in the same place we swap the `boot/loader` symlink.
We write a "stamp file" in `/boot` that says we need to run this command.
The reason we use stamp file is to prevent the case where the system is
interrupted after BLS file is updated, but before zipl is triggered,
then zipl boot records are not updated.
This opens the door to making things eventually-consistent/reconcilable
by later adding a systemd unit to run `zipl` if we're interrupted via
a systemd unit - I think we should eventually take this approach
everywhere rather than requiring `/boot/loader` to be a symlink.
Author: Colin Walters <walters@verbum.org>
Tested-by: Tuan Hoang <tmhoang@linux.ibm.com>
Co-Authored-By: Tuan Hoang <tmhoang@linux.ibm.com>
More "scan-build doesn't understand GError and our out-param conventions"
AKA "these errors would be impossible with Rust's sum type Result<> approach".
I was trying to fix a clang `scan-build` error that jlebon
ended up tracking down in
9344de1ce1
But in the process of tracing through this I found it
way easier to read as "new style" code, so this also ports the
code.
I added a `g_assert()` in there too to help assert that
`g_key_file_get_value` won't leak in the error path.
Got this error when trying to rebase libostree in RHEL:
```
Error: CLANG_WARNING: [#def1]
libostree-2019.2/src/libostree/ostree-repo-checkout.c:375:21: warning: Access to field 'disable_xattrs' results in a dereference of a null pointer (loaded from variable 'repo')
```
I think what's happening is it sees us effectively testing
`if (repo == NULL)` via the `while (current_repo)`. Let's
tell it we're sure it's non-null right after the loop.
I tried to balance reflecting the reality of who works on libostree
today with keeping some of the existing committers - particularly
committers from multiple organizations.
Part of switching libostree over to OpenShift Prow.
When building without --enable-trivial-httpd-cmdline, don't build or install
the ostree-trivial-httpd binary.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Since Fedora 30 grub2 has support to populate its menu entries from the
BootLoaderSpec fragments in /boot/loader/entries, so there's no need to
generate menu entries anymore using the /etc/grub.d/15_ostree script.
But since ostree doesn't update the bootloader, it may be that the grub2
installed is an old one that doesn't have BLS support.
For new installs, GRUB_ENABLE_BLSCFG=true is set in /etc/default/grub to
tell the /etc/grub.d/10_linux script if a blscfg command has to be added
to the generated grub2 config file.
So check if BLS is enabled in /etc/default/grub and only add the entries
if that's not the case. Otherwise the menu entries will be duplicated.
The approach has the drawback that if a user sets GRUB_ENABLE_BLSCFG=true
in /etc/default/grub without updating grub2, they will get an empty menu.
Since there won't be any entries created by the 30_ostree script and the
blscfg command won't work on the older grub2.
Unfortunately there is no way to know if the installed grub2 already has
BLS support or not.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1751272#c27Closes: #1929
Approved by: jlebon
Tiny release. Just want to get out the important bugfixes instead of
backporting patches (notably the gpg-agent stuff and
`ostree-finalize-staged.service` ordering).
Closes: #1927
Approved by: cgwalters
In Fedora 31, `systemd-journal-flush.service` uses a new
`--smart-relinquish-var` switch which fixes the
`umount: /var: target is busy` bug by telling journald to stop logging
to `/var` and back to `/run` again during shutdown.
This interacted with `ostree-finalize-staged.service` in a tricky way:
since we weren't strongly ordered against it, when we happened to
finalize after `/var` is relinquished, we never persisted the output
from that service to disk. This then threw off `rpm-ostree status` when
trying to find the completion message to know that finalization went
well.
Just fix this by adding an explicit `After=` on that unit. That way we
shut down *before* `systemd-journal-flush.service` (the `/var`
relinquish bit happens in its `ExecStop=`).
For more info, see:
3ff7a50d661e187d2dd5https://bugzilla.redhat.com/show_bug.cgi?id=1751272Closes: #1926
Approved by: cgwalters
Without this, rerunning ostree-prepare-root will fail in mkdir()
because /sysroot.tmp already exists, which complicates debugging from
the dracut emergency shell.
Closes: #1919
Approved by: cgwalters
The ostree fsck test is aimed to check that it will still fail an fsck
if the repository has been repaired by fsck. It also checks that a
pull operation corrects the error and ostree fsck will exit with zero.
The test was modeled after the following script:
rm -rf ./f1
mkdir -p ./f1
./ostree --repo=./f1 init --mode=archive-z2
mkdir -p ./trial
echo test > ./trial/test
./ostree --repo=./f1 commit --tree=dir=./trial --skip-if-unchanged --branch=exp1 --subject="test Commit"
rm -rf ./f2
mkdir -p ./f2
./ostree --repo=./f2 init
./ostree --repo=./f2 pull-local ./f1
echo whoops > `find ./f2 |grep objects |grep \\.file `
./ostree fsck --repo=./f2 ; echo Exit: $?
./ostree fsck --delete --repo=./f2 ; echo Exit: $?
./ostree fsck --repo=./f2 ; echo Exit: $?
./ostree --repo=./f2 pull-local ./f1
./ostree fsck --repo=./f2 ; echo Exit: $?
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
fsck: Update test so that it will pass on fs without xattrs
The fsck test does not require xattrs to prove that it works. It is
simple enough to change it to use an archvie instead of a bare type
repository.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Closes: #1910
Approved by: cgwalters
After the corruption has been fixed with "ostree fsck -a --delete", a
second run of the "ostree fsck" command will print X partial commits
not verified and exit with a zero.
The zero exit code makes it hard to detect if a repair operation needs
to be run. When ever fsck creates a partial commit it should add a
reason for the partial commit to the state file found in
state/<hash>.commitpartial. This will allow a future execution of the
fsck to still return an error indicating that the repository is still
in the damaged state, awaiting repair.
Additional reason codes could be added in the future for why a partial
commit exists.
Text from: https://github.com/ostreedev/ostree/pull/1880
====
cgwalters commented:
To restate, the core issue is that it's valid to have partial commits
for reasons other than fsck pruned bad objects, and libostree doesn't
have a way to distinguish.
Another option perhaps is to write e.g. fsck-partial into the
statefile state/<hash>.commitpartial which would mean "partial, and
expected to exist but was pruned by fsck" and fsck would continue to
error out until the commit was re-pulled. Right now the partial stamp
file is empty, so it'd be fully compatible to write a rationale into
it.
====
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Closes: #1910
Approved by: cgwalters
