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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Even if we're already initialized, we still need to create the subdir
requested. This would cause relabeling to fail because we try to create
the "relabel" subdir, which never actually gets created.
Closes: #993
Approved by: cgwalters
Amazingly we had 3 variations of this bug in the different
layers above using the `RpmOstreeContext` API (in compose, container,
and layering).
We fixed the first two already, this fixes the last one. We
get a warning if librpm holds a ref to a deleted rpmdb.
Closes: https://github.com/projectatomic/rpm-ostree/issues/987Closes: #994
Approved by: jlebon
This ensures we close the rpm database before we start moving
things around during postprocessing, and avoids a warning about
the rpmdb going missing being printed at the end of a compose.
Related: https://github.com/projectatomic/rpm-ostree/issues/987Closes: #989
Approved by: jlebon
The CentOS tester is currently failing because clang is being passed an
argument it doesn't know about:
clang: error: unknown argument: '-fstack-protector-strong'
We get our version of clang from EPEL, which currently has 3.4.2. The
Fedora clang does have support for the flag (4.0.1).
Anyway, the point of this check is just to find unused/uninitialized
vars and other gotchas. In that sense, we're more interested in what the
latest version of clang has to say.
Closes: #992
Approved by: cgwalters
This PR uses https://github.com/ostreedev/ostree/pull/1156
to ensure that when installing packages containing files with
exact same content, the files will be merged.
When installing packages containing conflicting files,
the error will still be detected at the ostree side.
The checkout overwrite option at rpm-ostree side is also
modified to accomodate the changes made in ostree side.
A test is added for regression
Commands like `upgrade` and `deploy` need to know if a new deployment
was actually laid down so that it may print a pkg diff if so. This is
implemented by listening for changes to the DefaultDeployment D-Bus
property. D-Bus emits a signal when the deployment variant changes
value.
However, in #595, with the introduction of `pending-*` related keys, the
deployment variant no longer represents data solely tied to that
specific deployment. In this case, because `deploy` operations currently
set the ref to the resolved checksum, it can happen that deploying the
same base commit when the current refspec *isn't* pointing to that base
commit will result in the `pending-*` keys dropping out and a default
deployment change notification going out.
In this patch, we strengthen how we determine whether a new deployment
was laid down by actually looking at the deployment id, rather than just
assuming that a change to the property implies a new deployment.
Closes: #981Closes: #984
Approved by: cgwalters
Also something I noticed while working on #981. When sitting on a livefs
commit, once a user does `rpm-ostree cleanup --pending --rollback`, it's
impossible to redeploy the same booted commit. Let's allow users to do
this.
Closes: #984
Approved by: cgwalters
Currently, when setting the `override-commit` key in the origin, the
upgrader pulls that commit checksum directly and then updates the
refspec to point to it. This behaviour was inherited from its ostree
version; at the time it was implemented, the pull code didn't support
passing a specific commit for a given refspec. However, we now have
the override-commit-ids option, which will make libostree update the ref
for us.
We change the code here to make use of it and simplify the function.
This also fixes the corner case of local branches: we shouldn't change
the ref if we're on a local branch. This is actually what drove me to
this patch as I was debugging #981.
(Aside: I'm still not convinced updating the refspec is always the
correct thing to do even in the remote case, though it's a bit messy to
disentangle).
Closes: #984
Approved by: cgwalters
Prep for changing `boot_location: new` to use `/usr/lib/ostree-boot`
and `/usr/lib/modules`. Rework our kernel postprocessing
so that we unify the `boot_location` handling with initramfs generation.
Instead of doing the initramfs first in postprocessing, we do it nearly last,
after e.g. `etc` is renamed to `usr/etc`. This has some consequences, such as
the fact that `run_bwrap_mutably()` is now called in both situations. In
general, our handling of `etc` is inconsistent, although understandably so.
As part of this, I finally got around to implementing the bit from
https://github.com/systemd/systemd/pull/4174 however suboptimal it is; need the
unified core so we can cleanly ignore the posttrans like we do others. We
intentionally keep the file around in the generated tree so that installing a
kernel RPM per client doesn't try to do any of this either.
This all gets folded together so that the logic for handling the bootloader gets
simpler - in the Fedora case, we now know to find kernels in `/usr/lib/modules`
and can ignore `/boot`.
Closes: #959
Approved by: jlebon
We have 3 locations to find kernels now; I can't think of
a reason to support placing kernels *only* in `/boot`. The
original commit
15ecaacd36
doesn't give a reason, and I certainly can't think of one now.
This makes `legacy` be an alias for `both`, which should be fully compatible.
Prep for further refactoring towards changing `new` to mean both
`/usr/lib/ostree-boot` *and* `/usr/lib/modules`.
Closes: #959
Approved by: jlebon
Make `upgrade` use the same trick as `deploy` to determine if a new
deployment was laid down. Apart from those two, all other operations
that can lay down a new deployment always do so in the happy path.
Prep for further work.
Closes: #983
Approved by: cgwalters
Today in Fedora the `glibc-all-langpacks.posttrans` is implemented
in lua, for no good reason. See:
https://bugzilla.redhat.com/show_bug.cgi?id=1367585
Since that's stalled out, let's add support for overrides. This
is obviously a much bigger step with more long term maintenance
implications over our current "ignore scripts" list. But we can't
block either.
This is needed for unified core work:
https://github.com/projectatomic/rpm-ostree/issues/729
(We also override `fedora-release-atomichost` but I'll likely
submit a patch for that upstream)
Closes: #980
Approved by: jlebon
I was linking to this code from elsewhere and noticed that
for our hardlink breaks we were not using fd-relative even
though we can. Down the line if we fork librpm into a separate
process and do e.g. `--dbpath=.` it'll do it too.
(Side note, I verified that commenting out the hardlink breaking
here was caught by the `ostree fsck` I added to the test suite)
Closes: #979
Approved by: jlebon
Started on porting to the new `glnx_fstatat_allow_noent()`. The
usage varies a lot and it felt easy to screw up, so I'm just
starting by doing a few of them.
Update submodule: libglnx
Closes: #978
Approved by: jlebon
I'd like to cut down on the number of tempdirs we make; when
debugging with gdb I often use e.g. `r` to restart forcibly, and
that leaves the dirs around.
Previously we'd make a tmpdir per relabeled package; this hoists it into a
well-known "relabel/" subdir of the per-core tmpdir we make. (A next step here
is to dedup the core tmpdir with the tmpdir that the upgrader makes)
Further while I'm here, let's use a single OSTree transaction for all of the
relabeling; the rationale here is that it's better to do fewer `syncfs()`
operations.
Closes: #970
Approved by: jlebon
This fixes `rpm-ostree reload` as root, and supports configuring
it to be enabled for other users as well. This was overlooked
in the polkit work originally.
Closes: https://github.com/projectatomic/rpm-ostree/issues/976Closes: #977
Approved by: jlebon
Let's make SELinux and atomic-host-tests happy with trees we concoct
ourselves by using the new --selinux-policy. (Specifically, we want our
sync'ed binaries to have install_exec_t).
Closes: #953
Approved by: cgwalters
I had meant for this to be in the other PR#968. I originally did both
`make` and `make install` there, but now it only does `make install`, so
let's just rename it to make that more obvious.
Closes: #953
Approved by: cgwalters
At one point `rpm-ostree install libvirt` dragged in libguestfs which in turn
brought in `syslinux-extlinux-nonlinux` which has files in `/boot/extlinux`,
which we rejected. (That dependency chain appears to have been fixed currently)
For the general case, this is just a partial fix in that we haven't nailed down
the semantics of how updates for `/boot` work. But in this particular case,
we'll just break libguestfs' `extlinux` verb, which I'm OK with.
Another case is `fwupdate-efi` - we require manual intervention to copy the
data into `/boot` after installing the package.
This is also preparation for [unified core](https://github.com/projectatomic/rpm-ostree/issues/729)
in that we now ensure imported kernels don't end up in `/boot` unless
explicitly configured.
Closes: https://github.com/projectatomic/rpm-ostree/issues/853Closes: #969
Approved by: jlebon
Let's make using a custom install tree easier and document the process.
We split out the insttree step into `build.sh` so that we no longer have
to `flock(1)` around it, and also share between `overlay.sh` and
`sync.sh`.
Closes: #968
Approved by: cgwalters
I noticed our C-style comments were actually showing up in the generated hash
table. Consistently use gperf's `#`, and also move all comments to the line
above the value for more readability.
Closes: #967
Approved by: jlebon
While working on unified core and the Fedora Atomic Host content set, I hit a
dependency between `docker.posttrans` which tries to read `/etc/os-release`, and
`fedora-release-atomichost.post` which creates that symlink.
It seems best practice to me to run `%post`s strictly before
`%posttrans`; we're not likely to do parallelization anytime
soon anyways.
While here I cleaned things up by having an enum for the script kind,
rather than multiple functions, otherwise we would have had another
wrapper in core.c.
Closes: #963
Approved by: jlebon
I initially thought I wouldn't need this but it turns out it makes things nicer
unified core. In the legacy path we'll need to write
`etc/passwd`, but now we need `usr/etc/passwd` in the unified path, and
we can start to match up with the other code paths which are fd-relative.
Closes: #950
Approved by: jlebon
The core use case always enabled this; we exposed it on the command line, but
honestly I think it's a lot simpler if our imports always enable this. If we
need to *undo* it (for example, generating a "traditional feeling" OCI/Docker
image a la <https://github.com/projectatomic/rpm-ostree/pull/367>), we can
easily do that as postprocessing afterwards.
Closes: #951
Approved by: jlebon
We should be using `g_propagate_error()` to ensure we handle the case where the
caller specifies `NULL` for the error.
Closes: #951
Approved by: jlebon
It turns out there's a much smaller limit than PATH_MAX for Unix
sockets. On Linux, it's 108 characters. It took me some time to figure
out why `vmcheck` would sometimes fail depending on where the src
directory is and how ${topsrcdir} is defined. Let's just make things
safer by just using /var/tmp.
Closes: #949
Approved by: cgwalters
Just noticed this while trying out the unified core work. We were
passing arguments in the wrong order (or alternatively, receiving them
in the wrong order).
Closes: #952
Approved by: cgwalters
Start running the improved-sanity-test from atomic-host-tests to make
sure the system works. This is an easy way to get PR-level comprehensive
integration tests for free.
But note that we *don't* mark it as required since the tests are not
stored here and it can happen that they need to be adjusted for new
rpm-ostree behaviours. In this way, this added check also allows us to
give a heads-up that breaking changes are coming.
Closes: #899
Approved by: cgwalters
I actually stopped using this a long time ago. Looking at it now, it
doesn't make much sense in multi-host situations. Let's just nix it.
Closes: #899
Approved by: cgwalters
