It turns out every builtin (with one special exception) that takes a
repo argument did the same thing; let's just centralize it. The
special exception was "ostree init --repo=foo" where foo is expected
to *not* actually be a repo. In that case, simply skip the
ostree_repo_check() invocation.
https://bugzilla.gnome.org/show_bug.cgi?id=706762
We removed support for writing "related objects" from ostree commits
in ostree git c9b61cbfee because it just
didn't work out as an idea. This also removes the API and code from
"ostree pull".
Note there was no test suite coverage.
https://bugzilla.gnome.org/show_bug.cgi?id=706342
OSTree now supports multiple bootloader backends so
notify which bootloader configuration was detected.
https://bugzilla.gnome.org/show_bug.cgi?id=706548
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Currently, when deploying an OSTree that does not contain a
bootloader configuration it fails with the following message:
"No known bootloader configuration detected"
A bootloader configuration is not strictly necessary if the
bootloader used is able to parse /boot/loader/entries on boot.
So, failing to deploy seems to be a little harsh. It is better
to just not write the bootloader configuration if a previous
one was not found but still swap the bootversion.
https://bugzilla.gnome.org/show_bug.cgi?id=706477
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Before, we were writing the "bootversion", which is either 0 or 1, for
all entries. This is completely wrong; the idea of the "version"
field is to compare between entries.
Fix this by writing out the inverted index - internally, index 0 is
the *first* boot entry, so we give it the highest version number, and
index N is the last, so give it version 0.
Then fix the deployment sorting code to correctly reverse the version
number comparison, so we read back the right order.
In practice before this bug didn't matter because "normally" you only
have at most two deployments.
https://bugzilla.gnome.org/show_bug.cgi?id=706546
The way we recurse into subdirectories in parallel makes it far too
easy to hit up against the arbitrary Linux fd limit of 1024.
Since the fix here is about dropping parallelism, let's just go all
the way for now and make a plain old synchronous API =(
This does simplify both internal callers which wanted a sync API
anyways.
https://bugzilla.gnome.org/show_bug.cgi?id=706380
This patch adds support to generate files that
can be used by Universal Bootloader (U-Boot).
U-Boot allows to modify boards default boot commands by
reading and executing a bootscript file or importing a
plain text file that contains environment variables that
could parameterize the boot command or a bootscript.
OSTree generates a uEnv.txt file that contains booting
information that is taken from Boot Loader Specification
snippets files as defined in the new OSTree deployment model:
https://wiki.gnome.org/OSTree/DeploymentModel2
On deploy or upgrade an uEnv.txt env var file is created
in the path /boot/loader.${bootversion}/uEnv.txt. Also, a
/boot/uEnv.txt symbolic link to loader/uEnv.txt is created
so U-Boot can always import the file from a fixed path.
Since U-Boot does not support a menu to list a set of
Operative Systems, the most recent bootloader configuration
from the list is used.
To boot an OSTree using the generated uEnv.txt file, a
board has to parameterize its default boot command using the
following variables defined by OSTree:
${kernel_image}: path to the Linux kernel image
${ramdisk_image}: path to the initial ramdisk image
${bootargs}: parameters passed to the kernel command line
Alternatively, for boards that don't support this scheme,
a bootscript that overrides the default boot command can be used.
An example of such a bootscript could be:
setenv scriptaddr 40008000
setenv kernel_addr 0x40007000
setenv ramdisk_addr 0x42000000
ext2load mmc 0:1 ${scriptaddr} uEnv.txt
env import -t ${scriptaddr} ${filesize}
ext2load mmc 0:1 ${kernel_addr} ${kernel_image}
ext2load mmc 0:1 ${ramdisk_addr} ${ramdisk_image}
bootm ${kernel_addr} ${ramdisk_addr}
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=706370
ot-bootloader-syslinux.c has a join_lines() function that is rather
generic and can be used in other places. Let's add it as a helper
function.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=706370
We'll always have "bare" mode for keeping files-as-hardlinks as root.
But "archive" was my second attempt at a format for non-root file
storage, used by the gnome-ostree buildsystem which runs as non-root.
It was really handy to have a "tar" like mode where I can create
tarballs as a user, that contain files owned by root for example.
The "archive" mode stored content files as two pieces in the
filesystem; ".file" contained metadata, and ".filecontent" was the
actual content, uncompressed. The nice thing about this was that to
check out a tree as non-root, you could just hardlink into the repo.
However, archive was fairly bad for serving via HTTP; it required
*two* HTTP requests per content object, greatly magnifing the already
inefficient fetch process. So "archive-z2" was introduced.
To allow gnome-ostree to still check out trees as a user, the
"uncompressed-object-cache" was introduced, and that's how things have
been working for a while.
So we should just be able to kill this code. Specifically note just
how much better the stage_object() function became.
https://bugzilla.gnome.org/show_bug.cgi?id=706057
Debian uses /lib/systemd/system for system unit files, while i'm
putting ostree under the /usr prefix which means the hardcoded path
fails. Leave it to configure to work out the right location for systemd
units (method copied from pollkit).
Furthermore instead of installing the unit in local-fs.target.wants by
hand add a [Install] section so systemctl enable does the right thing
https://bugzilla.gnome.org/show_bug.cgi?id=705864
We have APIs to load metadata as variants, and files as parsed
content/info/xattrs, but for some cases such as static deltas, all we
want is to operate on all objects in their canonical representation.
https://bugzilla.gnome.org/show_bug.cgi?id=706031
We used to have a version of this, but since I'm trying to use
GBytes more, this became a more common operation, and it's annoying
to type out the whole G_VARIANT_TYPE ("ay") each time, and pass
TRUE for trusted.
https://bugzilla.gnome.org/show_bug.cgi?id=706031
This will be used to test resuming interrupted downloads for
ostree-pull.
With this option, if a whole file is asked for, only half of the file
is given. Then the client should retry with a range request, and
we'll give them the other half.
https://bugzilla.gnome.org/show_bug.cgi?id=705925
If we pass XATTR_REPLACE then the attribute must already exist, which
is not our intent. Passing zero creates the attribute if necessary,
or replaces it when it already exists.
https://bugzilla.gnome.org/show_bug.cgi?id=705893
* Specifying global options after the command for a more natural:
# ostree commit --repo=/path/to/repo ...
* Support asking for --help without --repo
# ostree commit --help
* Support short form of -h
* Support specifying --repo without equals sign
# ostree --repo /path/to/repo commit ...
* Support global --help and -h
# ostree --help
* Ditto for ostree admin sub commands
* Removed some leaky code
https://bugzilla.gnome.org/show_bug.cgi?id=705903
While the actual commit object format is presently the same, for a
number of reasons we'd like to change it fairly radically. Among
other things, we need to drop our a{sv} types in objects, to protect
against GVariant changing format.
Since now gnome-ostree now longer uses related objects, and nothing
ever used metadata, just drop them both.
If the admin encounters corruption and does:
$ ostree admin fsck --delete
We want them to be able to recover the objects easily from the
network; with this patch, they do:
$ ln -s dummyvalue /ostree/repo/transaction
$ ostree refs --delete remotename:branchname
$ ostree pull remotename
This patch avoids the need for the refs --delete; we might as well
force scan the commit, and with this patch we still print that it
changed.
We may revive this later, but commits in their current form aren't
very useful for humans to read, so it doesn't make sense to have a
tool to show a history of useless stuff.
More interesting things are diffs between commits, object statistics,
etc.
Otherwise it's really easy to keep accumulating deployments. Also, we
may want to run this after rebooting, so we're back down to one
operating system.
And disable devino scan by default. For the gnome-ostree build case,
our commits are from "make install DESTDIR=", so they won't be
hardlinks into the repo. In that case, particularly as the repository
size grows, the cost of building up the devino -> checksum mapping
becomes a problem.
The compose step will use this option though.
While the first was useful way back in the day when we were importing
Debian bits and /sbin/init was expecting to find /dev/.initctl as a
named pipe, that's no longer an issue with systemd since it uses
dynamic Unix sockets.
Likewise, character and block devices in /dev are now dynamically
created by the devtmpfs from the kernel.
Less complexity and code here if we just support directories, regular
files, and symbolic links.
Calling it "cleanup" is better since it does more than repo pruning.
We were also doing a prune twice; ot_admin_cleanup() already does one,
so drop the bits to do it in cleanup.c.
It isn't useful at the moment, since the deploy stuff all changed. It
will make sense to bring back later, but for now let's not carry
broken untested code.
While the systemd integration effectively requires /sysroot, it will
help people trying to use OSTree with other initramfs systems
(e.g. initramfs-tools) if we don't hardcode that requirement in this
tool.
If pull is interrupted, we may have downloaded an arbitrary subset of
the requested objects. Previously, we handled this by scanning for
all objects each time.
However, there's an easy optimization - this patch creates a lock file
in the repo. If we don't see that file when starting a pull, we know
we don't need to stat() every file; presence of a dirtree object for
example implies the existence of everything it references.
Originally, the idea was that clients would replicate "OS/tree"s from
a build server, but we'd run things like "ldconfig" on the client.
This was to allow adding e.g. the nVidia binary driver.
However, the triggers were the only thing in the system at the moment
that really had expected knowledge of the *contents* of the OS, like
the location of binaries.
For now, it's architecturally cleaner if we move the burden of
triggers to the tree builder (e.g. gnome-ostree or RPM). Eventually
we may want OSTree to assist with this type of thing (perhaps
something like RPM %ghost), but this is the right thing to do now.
See https://wiki.gnome.org/OSTree/DeploymentModel2
This is a major rework of the on-disk filesystem layout, and the boot
process. OSTree now explicitly supports upgrading kernels, and these
upgrades are also atomic.
The core concept of the new model is the "deployment list", which is
an ordered list of bootable operating system trees. The deployment
list is reflected in the bootloader configuration; which has a kernel
argument that tells the initramfs (dracut) which operating system root
to use.
Invidiual notable changes that come along with this:
1) Operating systems should now come with their etc in usr/etc; OSTree
will perform a 3-way merge at deployment time, and place etc in
the actual root. This avoids the need for a bind mount, and is
just a lot cleaner.
2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected
that the the OS/ has these as symbolic links into /var.
At the moment, OSTree only supports managing syslinux; other
bootloader backends will follow.
This version of the code doesn't know what to do with new-model trees,
so just abort if we see that. We'll likely never care about upgrades
from 1.0 to 2.0.
A simple HTTP server implementation is so few lines of code when one
is linking to libsoup anyways, so let's just have one here in ostree
that will be used for the test suite.
This allows us to run the archive tests that previously required
apache even in gnome-ostree.
Even if very suboptimally, for now; we copy the files, then copy them
again.
The obvious long term plan is to merge pull-local and pull together,
but truly optimizing that requires the pull code to know how to use
the OstreeRepo APIs when operating on local repositories (as
pull-local does), rather than assuming the remote is an archive-z
fetched over HTTP.
We could drop into g_main_loop_run() after the worker
thread had called g_main_loop_quit().
Fix this by following the pattern suggested by Ryan of a while loop
around our termination condition, and g_main_context_iteration().
Linux creates a copy of the soure mount flags when creating a bind
mount; if the source is read-only, then the bind mount is.
The problem is that systemd will remount the rootfs read/write, but
each mount (/home, /var etc.) will still be read-only. We need to
remount every bind mount except for /usr to read-write too.
This only "worked" with the old ostree-switch-root because it
effectively force mounted the rootfs read-write always, ignoring the
"ro" flag.
This installs a Dracut module which parses the ostree= kernel command
line argument, and if given, sets up the OS/ at /sysroot, which
systemd's switch-root then moves into. This only works if dracut is
configured to use systemd itself.
Rather than attempting to hack up the "switch-root" functionality of
systemd, this binary allows us to simply prepare the root before we
switch into it.
This is useful for the gnome-ostree build system where each build is
one commit, but it's split up into /runtime /devel /debug etc. trees.
Ideally we wouldn't have a /debug subdirectory for "noarch"
components for example.
So add an option to not error out if the given path doesn't exist in
the commit.
When multiple threads need to uncompress an object, there was
a race condition where thread A could get EEXIST, unlink,
then thread B calls linkat(), then thread A tries to link() but
fails.
We can just loop in this case.
While this still isn't fully atomic (that depends on the bootloader),
this better ensures that the deployed kernel is booted with the
intended tree. For example, if we get ENOSPC when writing out the
kernel, we won't have swapped the symlink.
It's possible (likely even) that /tmp is on a separate filesystem; in
that case, a raw rename() is going to fail.
Saw this on the ostree.gnome.org builder.
Previously, I've observed bugs where we either:
1) Exit too early, leaving undownloaded objects
2) Hang while downloading
This rewrite hopefully fixes both.
We shouldn't overwrite deploy/<osname>/previous unless we actually
have something new.
This fixes the bug where two consecutive:
$ ostree admin upgrade foo
$ ostree admin upgrade foo
would end up pruning the data for foo/previous from the repo.
Colin Walters
Jeremy Whiting
Vivek Dasmohapatra
Javier Martinez Canillas
Sjoerd Simons
Stef Walter