summaryrefslogtreecommitdiff
path: root/src/libostree/ostree-sysroot.c
Commit message (Collapse)AuthorAgeFilesLines
* Update FSF license notices to use URL instead of addressJoseph Marrero2021-12-071-3/+1
|
* sysroot: Fix gcc `-fanalyzer` warningColin Walters2021-10-131-2/+6
| | | | | | | | | In general, we're probably going to need to change most of our `g_return_if_fail` to `g_assert`. The analyzer flags that the function can return `NULL`, but the caller isn't prepared for this. In practice, let's abort.
* lib/sysroot: Fix error message about creating `/var/lib`Jonathan Lebon2021-08-031-1/+1
| | | | Reported-by: Seth Arnold <seth.arnold@canonical.com>
* Merge pull request #2375 from cgwalters/generator-remountJonathan Lebon2021-06-181-1/+0
|\ | | | | Use generator to enable ostree-remount.service and ostree-finalize-staged.path
| * Use generator to enable ostree-remount.service and ostree-finalize-staged.pathColin Walters2021-06-161-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We struggled for a long time with enablement of our "internal units", trying to follow the philosophy that units should only be enabled by explicit preset. See https://bugzilla.redhat.com/show_bug.cgi?id=1451458 and https://github.com/coreos/rpm-ostree/pull/1482 etc. And I just saw chat (RH internal on a proprietary system sadly) where someone hit `ostree-remount.service` not being enabled in CentOS8. Thinking about this more, I realized we've shipped a systemd generator for a long time and while its only role until now was to generate `var.mount`, but by using it to force on our internal units, we don't require people to deal with presets anymore. Basically we're inverting things so that "if ostree= is on the kernel cmdline, then enable our units" and not "enable our units, but have them use ConditionKernelCmdline=ostree to skip". Drop the weird gyrations we were doing around `ostree-finalize-staged.path` too; forking `systemctl start` is just asking for bugs. So after this, hopefully we won't ever again have to think about distribution presets and our units.
* | Fix small typo in ostree-sysroot.cChristian Kellner2021-06-151-1/+1
|/
* sysroot: Add _require_booted_deployment() APIColin Walters2021-03-171-0/+21
| | | | | This is a common pattern that is replicated both in our code and in rpm-ostree a lot. Let's add a canonical API.
* Merge pull request #2287 from jlebon/pr/deployment-parsing-commentsOpenShift Merge Robot2021-03-031-1/+11
|\ | | | | lib/sysroot: Add comments and debug statements around sysroot parsing
| * lib/sysroot: Add comments and debug statements around sysroot parsingJonathan Lebon2021-03-021-1/+11
| | | | | | | | | | Was looking at this code more closely today to investigate issues related to bootlink mismatches (#2283).
* | sysroot: Handle ro /boot but rw /sysrootColin Walters2021-01-101-11/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The recent change in https://github.com/coreos/fedora-coreos-config/pull/659 broke some of our tests that do `mount -o remount,rw /sysroot` but leave `/boot` read-only. We had code for having `/boot` read-only before `/sysroot` but in practice we had a file descriptor for `/sysroot` that we opened before the remount that would happen later on. Clean things up here so that in the library, we also remount `/boot` at the same time we remount `/sysroot` if either are readonly. Delete the legacy code for remounting `/boot` rw if we're not in a mount namespace. I am fairly confident most users are either using the `ostree` CLI, or they're using the mount namespace.
* | sysroot: Also maintain canonical boot_fdColin Walters2021-01-101-0/+15
|/ | | | | | | Just like we hold a fd for `/sysroot`, also do so for `/boot` instead of opening and closing it in a few places. This is a preparatory cleanup for further work.
* deployment: Ensure query_deployments_for returns nullable valuesColin Walters2020-11-111-2/+2
| | | | | Since that's a common case; hit this while working on rpm-ostree code using the ostree-rs bindings.
* sysroot: Fix up some GI nullable annotationsColin Walters2020-11-061-9/+9
| | | | | Hit `ostree_sysroot_repo()` shouldn't be nullable while using the ostree Rust bindings.
* fixup! Refactor `ostree_sysroot_query_bootloader`William Manley2020-10-271-0/+3
|
* fixup! Refactor: Centralise choosing the appropriate bootloaderWilliam Manley2020-10-271-1/+0
|
* Refactor `ostree_sysroot_query_bootloader`William Manley2020-10-261-49/+47
| | | | | This is more regular, so will make it easier to add more bootloader types in the future.
* Add support for explicitly requesting any specific bootloader typeWilliam Manley2020-10-261-0/+9
| | | | | | | | | ...with the `sysroot.bootloader` configuration option. This can be useful when converting a system to use `ostree` which doesn't currently have a bootloader configuration that `ostree` can automatically detect, and is also useful in combination with the `--sysroot` option when provisioning a rootfs for systems other than the one you're running `ostree admin deploy` on.
* Refactor: sysroot.bootloader: Store enum value rather than stringWilliam Manley2020-10-261-33/+36
| | | | | | It's easier to extend and it centralises the config parsing. In other places we will no longer need to use `g_str_equal` to match these values, a `switch` statement will be sufficient.
* Refactor: Centralise choosing the appropriate bootloaderWilliam Manley2020-10-261-18/+41
| | | | In preparation for enhancing `_ostree_sysroot_query_bootloader`
* lib/deploy: Add support for overlay initrdsJonathan Lebon2020-09-301-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | In FCOS and RHCOS, the need to configure software in the initramfs has come up multiple times. Sometimes, using kernel arguments suffices. Other times, it really must be a configuration file. Rebuilding the initramfs on the client-side however is a costly operation. Not only does it add complexity to the update workflow, it also erodes a lot of the value obtained from using the baked "blessed" initramfs from the tree itself. One elegant way to address this is to allow specifying multiple initramfses. This is supported by most bootloaders (notably GRUB) and results in each initrd being overlayed on top of each other. This patch allows libostree clients to leverage this so that they can avoid regenerating the initramfs entirely. libostree itself is agnostic as to what kind and how much data overlay initrds contain. It's up to the clients to enforce such boundaries. To implement this, we add a new ostree_sysroot_stage_overlay_initrd which takes a file descriptor and returns a checksum. Then users can pass these checksums when calling the deploy APIs via the new array option `overlay_initrds`. We copy these files into `/boot` and add them to the BLS as another `initrd` entry.
* deploy: Remove deployment bootcsum assertionColin Walters2020-09-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When support for devicetree was added, it created a problem because old and new ostree versions would compute different checksums for the "boot data". The scenario here is: - Have system with ostree < 2020.4 - Reboot into system with ostree 2020.5 - Try to perform an operation that would retain that previous booted deployment (common) Currently ostree iterates over all the deployments that will be retained and calls `install_deployment_kernel()`, even for the booted one (which is a bit silly), but just to verify that all boot data for the targeted deployments are installed. This then re-computes the checksum and we'd trip this assertion. In practice though, we don't strictly require them to match; the only thing that will happen if they don't is that we'll end up with another copy of the kernel/initramfs - and that only temporarily until the previous deployment gets GC'd. Longer term, I think what we really want to do anyways is probably closer to like a little ostree repo for `/boot` so that we can e.g. still hardlink kernels there even if the initramfs changes, or hardlink both kernel/initramfs if just the devicetree changes, etc. Closes: https://github.com/ostreedev/ostree/issues/2154
* Add "transient" unlockColin Walters2020-08-071-7/+21
| | | | | | | | | | | | | | | | | | | | | | I was thinking a bit more recently about the "live" changes stuff https://github.com/coreos/rpm-ostree/issues/639 (particularly since https://github.com/coreos/rpm-ostree/pull/2060 ) and I realized reading the last debates in that issue that there's really a much simpler solution; do exactly the same thing we do for `ostree admin unlock`, except mount it read-only by default. Then, anything that wants to modify it does the same thing libostree does for `/sysroot` and `/boot` as of recently; create a new mount namespace and do the modifications there. The advantages of this are numerous. First, we already have all of the code, it's basically just plumbing through a new entry in the state enumeration and passing `MS_RDONLY` into the `mount()` system call. "live" changes here also naturally don't persist, unlike what we are currently doing in rpm-ostree.
* sysroot: Reorganize sysroot load code a bitColin Walters2020-03-311-47/+59
| | | | | | No functional changes; prep for a future patch which will load the "live" deployment rather than reading the bootloader configs.
* lib: Add error prefixing for sysroot load and repo openColin Walters2020-03-281-0/+1
| | | | | | | | Noticed this while writing tests for a core `ostree_sysroot_load()` entrypoint. And decided to do the same for `ostree_repo_open()`, and while there also noted we had a duplicate error prefixing for the open (more recently `glnx_opendirat()` automatically prefixes with the path).
* lib: Fix Since versions for 2020.1fixup-since-versionsDan Nicholson2020-02-201-3/+3
| | | | | | | | These had been added assuming 2019.7 would be the next version, but now it's 2020 and there's been a release. In the case of `OstreeCommitSizesEntry`, I'd forgotten to move it forward from 2019.5 to 2019.7 in the time between when I started working on the feature and it landed.
* Support mounting /sysroot (and /boot) read-onlyColin Walters2019-12-111-44/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to support extending the read-only state to cover `/sysroot` and `/boot`, since conceptually all of the data there should only be written via libostree. Or at least for `/boot` should *mostly* just be written by ostree. This change needs to be opt-in though to avoid breaking anyone. Add a `sysroot/readonly` key to the repository config which instructs `ostree-remount.service` to ensure `/sysroot` is read-only. This requires a bit of a dance because `/sysroot` is actually the same filesystem as `/`; so we make `/etc` a writable bind mount in this case. We also need to handle `/var` in the "OSTree default" case of a bind mount; the systemd generator now looks at the writability state of `/sysroot` and uses that to determine whether it should have the `var.mount` unit happen before or after `ostree-remount.service.` Also add an API to instruct the libostree shared library that the caller has created a new mount namespace. This way we can freely remount read-write. This approach extends upon in a much better way previous work we did to support remounting `/boot` read-write. Closes: https://github.com/ostreedev/ostree/issues/1265
* tree-wide: [scan-build]: Add some asserts that pointers are non-NULLColin Walters2019-10-161-0/+1
| | | | | 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".
* sysroot: [scan-build] Remove a dead assignmentColin Walters2019-10-151-4/+1
| | | | Just quieting the scan.
* sysroot: Add a clearer error if /boot/loader isn't foundColin Walters2019-08-261-1/+12
| | | | | | | | | | | | | | | I've seen people confused by this error in the case where `/boot` isn't mounted or the BLS fragments were deleted, etc. If you understand ostree deeply it's clear but, let's do better here and a direct error message for the case where we can't find `/boot/loader` which is the majority of these. The other case could happen if e.g. just the BLS fragment for the booted deployment was deleted; let's reword that one a bit too. Closes: #1905 Approved by: rfairley
* lib/kargs: Make API public and upstream new rpm-ostree APIsAllen Bai2019-06-181-3/+3
| | | | | | | | | | | | | | | | This change makes public the current kargs API in src/libostree/ostree-kernel-args.c and adds documentations. Upstreams the new kargs API from rpm-ostree/src/libpriv/rpmostree-kargs-process.c Merges libostree_kernel_args_la_SOURCES to libostree_1_la_SOURCES in Makefile-libostree.am Upstreams tests/check/test-kargs.c from rpm-ostree. Closes: #1833 Closes: #1869 Approved by: jlebon
* lib: add parameter annotations for sysroot_load_if_changedFelix Krull2019-05-191-0/+4
| | | | | Closes: #1861 Approved by: cgwalters
* lib: add minimum version to various symbols based on libostree-released.symFelix Krull2019-05-191-0/+13
| | | | | Closes: #1861 Approved by: cgwalters
* lib/sysroot: Match deployment /usr mode for overlayJonathan Lebon2019-04-241-5/+13
| | | | | | | | Rather than hardcoding 0755, let's directly look at what `/usr`'s mode is and copy it when creating the overlay. Closes: #1843 Approved by: cgwalters
* lib/sysroot: Call `chmod` on overlay dirs when unlockingJonathan Lebon2019-04-241-4/+20
| | | | | | | | | | | | | | | | | Otherwise, we'll be subject to whatever `umask` is currently. Normally, processes should respect `umask` when creating files and directories, but specifically for `ostree admin unlock` (or `rpm-ostree usroverlay`), this poses a problem since e.g. a `/usr` with mode 0700 will break any daemon that doesn't run as root and needs to read files under `/usr`, such as polkitd. This patch just does a `chmod()` after the `mkdir()`. An alternative would be to do `umask(0000)` after forking into the child process that'll call `mount()`, but that'd require also moving the `mkdir()` calls into there, making for a more intrusive patch. Closes: #1843 Approved by: cgwalters
* boot: Add ostree-finalize-staged.pathJonathan Lebon2018-10-231-0/+1
| | | | | | | | | | | | | | | | Rather than manually starting the `ostree-finalize-staged.service` unit, we can leverage systemd's path units for this. It fits quite nicely too, given that we already have a path we drop iif we have a staged deployment. To give some time for the preset to make it to systems, we don't yet drop the explicit call to `systemctl start`. Though we do make it conditional based on a DEBUG env var so that we can actually test it in CI for now. Once we're sure this has propagated, we can drop the `systemctl start` path and the env var together. Closes: #1740 Approved by: cgwalters
* sysroot: Add error prefixing to deployment parsingColin Walters2018-10-171-0/+4
| | | | | | | | | | I think this is where the bare `readlinkat` came from in https://github.com/ostreedev/ostree/issues/1459 `Error setting up sysroot: readlinkat: No such file or directory` Closes: #1757 Approved by: jlebon
* sysroot: Update some code to use fstatat_allow_noent APIColin Walters2018-10-171-12/+12
| | | | | | | | It's much easier to read and use correctly. Making this change since I saw an unprefixed error in an issue. Closes: #1757 Approved by: jlebon
* sysroot: Reject attempts to pin the staged deploymentColin Walters2018-06-291-1/+5
| | | | | | | | | | From https://github.com/projectatomic/rpm-ostree/pull/1434#discussion_r198936674 To support it we'd have to actually write it to disk, which...let's not try that right now. Closes: #1660 Approved by: jlebon
* lib/sysroot: Maintain one variable for "root is ostree booted"Colin Walters2018-05-021-11/+7
| | | | | | | | | This was pointed out in a previous PR review; we don't have a need for the separate variables. Prep for adding an API for this. Closes: #1568 Approved by: jlebon
* lib/sysroot: Move staged into deployment list, rework handlingColin Walters2018-04-181-6/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Followup to: https://github.com/ostreedev/ostree/pull/1503 After starting some more work on on this in rpm-ostree, it is actually simpler if the staged deployment just shows up in the list. It's effectively opt-in today; down the line we may make it the default, but I worry about breaking things that e.g. assume they can mutate the deployment before rebooting and have `/etc` already merged. There's not that many things in libostree that iterate over the deployment list. The biggest change here is around the `ostree_sysroot_write_deployments_with_options` API. I initially tried hard to support a use case like "push a rollback" while retaining the staged deployment, but everything gets very messy because that function truly is operating on the bootloader list. For now what I settled on is to just discard the staged deployment; down the line we can enhance things. Where we then have some new gymnastics is around implementing the finalization; we need to go to some effort to pull the staged deployment out of the list and mark it as unstaged, and then pass it down to `write_deployments()`. Closes: #1539 Approved by: jlebon
* sysroot: Clean up origin loading functionColin Walters2018-04-131-24/+18
| | | | | | | | | | | | In prep for staging work, where we'll need to load the origin for the staged deployment too. The function was previously trying to avoid operating on an instantiated deployment, but the data we need is in the deployment object at that point. Closes: #1538 Approved by: jlebon
* Add concept of "staged" deploymentColin Walters2018-04-121-9/+89
| | | | | | | | | | | | | | | | | | | | | | Add API to write a deployment state to `/run/ostree/staged-deployment`, along with a systemd service which runs at shutdown time. This is a big change to the ostree model for hosts, but it closes a longstanding set of bugs; many, many people have hit the "losing changes in /etc" problem. It also avoids the other problem of racing with programs that modify `/etc` such as LVM backups: https://bugzilla.redhat.com/show_bug.cgi?id=1365297 We need this in particular to go to a full-on model for automatically updated host systems where (like a dual-partition model) everything is fully prepared and the reboot can be taken asynchronously. Closes: https://github.com/ostreedev/ostree/issues/545 Closes: #1503 Approved by: jlebon
* lib/deploy: Port various functions to declare-and-initializeColin Walters2018-03-171-20/+11
| | | | | | | Just noticed this while working on the code. Closes: #1499 Approved by: jlebon
* sysroot: Rework how we find booted deploymentColin Walters2018-03-151-94/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was looking at this code in prep for "staging" deployments, and there are several cleanups to be made here. The first thing I noticed is that we look for the `ostree=` kernel argument, but the presence of that should be exactly equivalent to having `/run/ostree-booted` exist. We just added a member variable for that, so let's make use of it. Related to this, we were erroring out if we had the karg but didn't find a deployment. But this can happen if e.g. one is using `ostree admin --sysroot` from an ostree-booted system! It's actually a bit surprising no one has reported this so far; I guess in the end people are either using non-ostree systems or running from containers. Let's add a member variable `root_is_sysroot` that we can use to determine if we're looking at `/`. Then, our more precise "should find a booted deployment" state is when both `ostree_booted` and `root_is_sysroot` are TRUE. Next, rather than walking all of the deployments after parsing, we can inline the `fstatat()` while parsing. The mild ugly thing about this is assigning to the sysroot member variable while parsing, but I will likely clean that up later, just wanted to avoid rewriting everything in one go. Closes: #1497 Approved by: jlebon
* sysroot: Track whether /run/ostree-booted existsColin Walters2018-03-151-0/+13
| | | | | | | Prep for further work around deployment staging. Closes: #1497 Approved by: jlebon
* lib/sysroot: Fix retrieving non-booted pending deploymentJonathan Lebon2018-02-281-4/+4
| | | | | | | | | | | | If we're booted into a deployment, then any queries for the pending merge deployment of a non-booted OS will fail due all of them being considered rollback. Fix this by filtering by `osname` *before* determining if we've crossed the booted deployment yet. Closes: #1472 Approved by: cgwalters
* sysroot: Add concept of deployment "pinning" đź“ŚColin Walters2018-02-261-0/+44
| | | | | | | | | | | | | Example user story: Jane rebases her OS to a new major version N, and wants to keep around N-1 even after a few upgrades for a while so she can easily roll back. I plan to add `rpm-ostree rebase --pin` to opt-in to this for example. Builds on the new `libostree-transient` group to store pinning state there. Closes: https://github.com/ostreedev/ostree/issues/1460 Closes: #1464 Approved by: jlebon
* Add SPDX-License-Identifier to source filesMarcus Folkesson2018-01-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | SPDX License List is a list of (common) open source licenses that can be referred to by a “short identifier”. It has several advantages compared to the common "license header texts" usually found in source files. Some of the advantages: * It is precise; there is no ambiguity due to variations in license header text * It is language neutral * It is easy to machine process * It is concise * It is simple and can be used without much cost in interpreted environments like java Script, etc. * An SPDX license identifier is immutable. * It provides simple guidance for developers who want to make sure the license for their code is respected See http://spdx.org for further reading. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Closes: #1439 Approved by: cgwalters
* tree-wide: Use autoptr for OstreeKernelArgsColin Walters2017-10-251-2/+2
| | | | | | | | Much nicer looking. Prep for more cleanup from https://github.com/projectatomic/rpm-ostree/pull/1013 Closes: #1302 Approved by: peterbaouoft
* lib/sysroot: Expand docs for ostree_sysroot_get_repo()Philip Withnall2017-10-231-2/+5
| | | | | | | | | | Add some missing annotations and clarify that it always returns an open repository on success. Signed-off-by: Philip Withnall <withnall@endlessm.com> Closes: #1300 Approved by: cgwalters
View Lorry Controller Status