At a minimum, it should list the available subcommands. This is
still not perfect, since there is no way to get at the help output
of the subcommands - getting that right needs more refactoring.
Signed-off-by: Colin Walters <walters@verbum.org>
This seems to work around a likely Linux kernel VFS bug, where I
randomly see ENOENT on link() when we *definitely* called mkdir() at
an earlier point in time.
This is an incompatible change to archive-z, thus it is now renamed to
archive-z2 and ostree will no longer parse archive-z.
I noticed in perf that we were spending some time zlib-decompressing
file headers, which is just inefficient. Rather than do this, keep
the headers uncompressed, and just zlib-compress content.
This gives us something closer to the advantages of archive and
archive-z when using the latter. Concretely we get deduplication
among multiple checkouts, along with the "devino" hash table trick
during commits to avoid checksumming content again.
This is enabled by default.
For similar reasons as metadata, this avoids having the main thread
blocked in fdatasync(), and even better - we can achieve much higher
parallelism if we have multiple threads blocked on fdatasync().
We need this hack for "archive mode" repositories; otherwise,
what ends up happening is that we get 10000+ requests pending
for .filemeta files, which we can't process until we also get
the .filecontent.
Note this hack is unneccessary when fetching from archive-z
repositories.
Create a worker thread for processing metadata, reserving the main
thread for HTTP requests.
This can create a very significant efficiency win for large pull
requests since we are much more likely to keep a full pipeline open.
The status display is also nicer now.
This is where loose content objects are stored as one compressed file,
instead of the two separate ones for regular archive mode. This mode
would be suitable for HTTP servers, beause only one HTTP request is
necessary, and the result would be compressed.
Cleanly separate metadata/content APIs, rather than defaulting to
raw streams. This helps most use cases.
Also, drop support for staging content without knowing the total
length. This complicated the code, and for things like streaming
HTTP, we should be able to figure this out from Content-Length.
They're not a large efficiency win at the moment, because we don't
do any delta compression.
At the moment, they simply served to compress data, but we will change
the archive mode to do that by default.
Configuration associated with a specific revision is stored in a folder
named <revision>-etc. In a similar spirit, add /ostree/current-etc, pointing
to the -etc folder for the revision named by current. This allows
easy editing of configuration from the host distribution, and allows
diffing current/etc and current-etc for configuration changes.
https://bugzilla.gnome.org/show_bug.cgi?id=684049
First, move deployments to /ostree/deploy. Having them in the
toplevel clutters the filesystem layout too much.
When we deploy a tree like /ostree/deploy/NAME, there is now also a
writable directory /ostree/deploy/NAME-etc. This is mounted as
read-write inside the system.
On an initial install, that directory is copied from
/ostree/deploy/NAME/etc. On subsequent deployments, we find any
changes made in the current deployment's /etc, and apply that set of
changes to the new deployment's /etc.
See https://live.gnome.org/OSTree/EverythingInEtcIsABug
I run builds on my laptop, but it also crashes about 1/4 of the time
while suspending. It's definitely undesrirable to get e.g. empty
.dirtree objects because they corrupt builds. Concretely, I was
getting empty contents committed for xorg-util-macros.
Now, we used to write out temporary files using g_file_replace() which
does a fsync() during close, but then switched to a more "manual"
g_file_append_to().
We could switch back to g_file_replace(), but the problem is, we don't
want to call fsync() on temporary files in the case where we already
have the object. Attempting to add an object we already have is a
*very* common case.
This is both the old and new code sequence for the case where an
object is already stored:
open(temp, O_WRONLY)
write() write() write()
close()
lstat(objects/3a/9fe332...) = 0
unlink(temp)
In the *new* code, here's the case where an object *isn't* stored:
open(temp, O_WRONLY)
write() write() write()
close()
lstat(objects/3a/9fe332...) = -1
open(temp, O_RDONLY)
fdatasync()
close()
rename(temp, objects/3a/9fe332)
Compare with the *old* code path for when an object isn't stored:
open(temp, O_WRONLY)
write() write() write()
close()
lstat(objects/3a/9fe332...) = -1
link(temp, objects/3a/9fe332)
unlink(temp)
The problem with this is we really need to fdatasync(). Also doing
just rename() instead of the weird link()/unlink() helps us express to
the filesystem that we want atomic semantics. For example, BTRFS has
special handling for rename().
We really don't have a sane story for private files. This is a
defensive step ensuring that with old versions of gnome-ostree,
components that mistakenly have un-world-readable files don't break
pulls.
Use the new update-cache mode of pango-querymodules, which
automatically finds the correct cache file location.
Updated to look in both places by Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=682411
This command regenerates kernel-dependent files. It is meant to
be run after kernel upgrades in the host distribution, to keep
the ostree installation running, and attempts to figure out the
right version automatically (and without changing the ostree checkout)
As the manual page doesn't say, but the in-code kernel documentation
shows, hardlinking for normal users can fail for a variety of
reasons (including very common situations such as non regular file
or non writable file), if the owner of the file does not match
the user linking (e.g. when checking out a shadow repo with a root-
owned master).
If that happens, fail back silently to copying instead of aborting
the whole operation.
https://bugzilla.gnome.org/show_bug.cgi?id=682298
Common code was duplicating the command name and not shifting
arguments properly, which thus required the builtins to be aware
of it, instead of being treated like subcommands.
The qemu helper really wants to copy kernel modules, but not
update the system bootloader. Allow it to reuse ostadmin for
this.
Note that our previous path of shelling out to "cp -al" broke because
it refused to make cross-device links.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: src/libotutil/ot-gio-utils.c
# modified: src/libotutil/ot-gio-utils.h
# modified: src/ostadmin/ot-admin-builtin-deploy.c
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# embedded-dependencies/glib/
# embedded-dependencies/libsoup/
The old command line syntax assumed you wanted the latest from
a given revision, but to bisect, you really want the ability
to deploy any given one.
Old:
$ ostadmin deploy gnomeos-3.6-i686-{runtime,devel}
New:
$ ostadmin deploy trees/gnomeos-3.6-i686-runtime
$ ostadmin deploy trees/gnomeos-3.6-i686-devel
And note that the deploy directory now changes to:
/ostree/trees/gnomeos-3.6-i686-devel
And now it's possible to:
$ ostadmin deploy trees/gnomeos-3.6-i686-devel trees/gnomeos-3.6-i686-devel^^^
This helps make things less confusing when we try to create a file not
owned by our uid, such as running ostree-pull as non-root on a
repository owned by root.
The "status text" code was assuming that libsoup was only doing one
thing at a time, but that's never been the case. Change the code to
display the status of all active requests.
This can be a large performance win in certain circumstances:
* Cold buffer cache (we don't block the whole process)
* Requiring a copy instead of hardlink
The previous fix to just ignore symbolic links for hard linking isn't
really good enough, since it can happen for empty files too.
Since this is an optimization, when we get EMLINK, let's instead just
fall back to copying. This also applies to EXDEV.
Rather than always doing:
1) make temporary link
2) unlink() target
3) rename()
Just try making the link, and only do the second two if the file
already exists. This reduces system call traffic a lot.
We should explicitly distinguish between the case where we have a git
branch we're following, versus an immutable tag. In the latter case,
we can entirely avoid running 'git fetch' for it once we have it.
This is a noticeable speedup in our current scenario of pinning WebKit
to a tag.
The git mirroring code now has a --fetch-skip-secs=X option which
allows us to basically run it in a loop, without hitting remote git
repositories too often.
This is the new workflow:
$ ostbuild import-tree wip-gnome-menus-3.6
$ $EDITOR ~/build/ostbuild/snapshots/wip-gnome-menus-3.6-2012.1-abcd.json
$ ostbuild build
First, "resolve" now just picks git commits. We don't expand
config-opts and patches, nor do we generate tree contents. This makes
the generated files *much* more human editable.
Next, fold "build-components" and "compose" into just "build". One
never really wants to just build components. This lets us eliminate
binary snapshots as a concept; instead we always have a combination of
source snapshot and component/ refs.
First, for binary snapshots we need to include the exact revision of
the architecture buildroot. To do that, introduce
"architecture-buildroots2".
Second, for bin-to-src, we'd like to allow "partial" builds. So while
we do expand everything to source, *also* include the binary
ostree-revision. This will allow building just one component, while
reusing the previously built binaries.
By default, don't delete loose objects which have hard links. This
has the natural semantics that if you delete all the checkouts, you
probably want it packed.
Conversely, if it has a hard link, we do want further checkouts to
share storage, even if we pack in between them.
In the case of not being able to check the repository or not being able
to parse command line arguments, attributes from "pull_data" would be used
with garbage in them. This patch makes initialization of the sctructure to
happen earlier so it is safe to use in those cases.
Call self.parse_config() so that all necessary directories are parsed.
Also don't call nonexistant self.parse_active_branch() and just use
self.active_branch since it's already have been initialized.
For components specified on the command line, we now force a rebuild.
There's also a new option to skip if the git revision matches, but
metadata changed (useful for now to avoid cascading builds if you know
you don't need it).
This builtin did not work for me. It did not initialize self.repo,
it used the nonexisting parse_active_branch function unconditionally,
and it did not actually find the list of components in contents.json.
This commit fixes all three of these issues.
This fixes the case where /tmp resides in one volume, and the build
directory in a different one: by storing the temporary file in the
same directory as the target one, we avoid the case in which os.rename()
would cross file system boundaries.
Reviewed-by: Colin Walters <walters@verbum.org>
By default, when doing a commit, scan all of our loose objects and
build up a (device,inode) -> checksum hash. Then when we're doing a
commit, if we see a file with that (device,inode) pair, we can avoid
checksumming it.
This will allow us to use hard links again for user-mode checkouts,
rather than the hackish link cache. It was pretty silly anyways to
have file objects be stored with just a small metadata header
prepended, but uncompressed.
Either they should be hardlinkable, or compressed (in pack files).
Rather than passing xattr/file_info for all objects, change the API to
assume we're passing the defined object stream for each type. Namely,
for OSTREE_OBJECT_TYPE_FILE, we're now giving the "archive file" data.
This significantly cleans up the code for committing to archive mode
repositories, at the cost of having to (at present) create an
intermediate temporary file when committing to raw repositories.
This will be useful for ostbuild; a user can create their own archive
mode repository which transparently inherits objects from the
root-owned one in /ostree.
The ostree-switch-root tool expects three arguments (argc=4): new root, OS
tree target, and init(8) binary to launch inside it. Also, the error message
when not enough arguments are passed now tells about the second argument
being the target OS tree.
Reviewed-by: Colin Walters <walters@verbum.org>
This is a convenient way to have a lookaside directory of hard links,
which can greatly speed up checkouts. In the future we probably want
to push this down into the repository.
Having the archived vs not distinction in the object system wasn't
useful in light of pack files. In fact, we should probably move
towards generating a pack file per commit by default.
Don't expose GChecksum in APIs. Add a new stream class which allows
us to pass an input stream somewhere, but gather a checksum as it's
read.
Move some bits of the internals towards binary csums.
Previously we had the "staged" state to ensure we didn't add a commit
object without the associated dirtree, etc. However it's
easier/better to just ensure in the pull command that we have all
referenced objects.
Also change pull to download metadata first. This will allow adding
a progress bar later.
Rather than verifying every object, traverse all commit objects we
find. This is a better check, since primarily we care about being
able to check out trees. In the new packfile regime, this ensures
validity of packed data.
It also means we aren't checking loose objects that we most likely
don't care about.
The "resolve" builtin now does a lot more heavy lifting; we expand the
manifest.json, and "build" consequently is less intelligent now, more
of a low-level implementation.
Store the compose contents as a JSON file in the filesystem tree.
This is more flexible compared to defining "compose" as just a literal
layering of filesystem trees. For example, we might want to run
prelink.
We need to be more formal about where we get patches from, and more
specifically what version. Let's assume they're also stored in a git
repository that we fetch, instead of copying them from "wherever the
manifest is".
This meshes nicely with splitting between manifest.json and
snapshot.json.
Let's have chroot-compile-one be the core logic for composing a
buildroot, etc. This allows us to use it as a developer tool by
checking out a tree, then doing a chroot build.
Expose the lower-level functionality in libostree, change checkout
builtin to be a higher level driver. This will allow us to more
easily improve the "checkout" builtin..
Continuing from 16c0cfe9b5, we now have
the problem that we're removing the executable bit, which obviously
breaks things when we chroot in for a build. Fix this by masking over
our bits.
Otherwise
1) Lots of unnecessary shit happens and I like my straces to be clean
2) There is no dbus session bus for system daemons or when we're run
in a root context
We want to support both "bare" lookups where "foo" can be local, or in
any remote, as well as prefixed ones for a specific remote.
This fixes ostree-pull noticing that nothing has changed.
This should be useful on clients to trim old refs. For example,
after an upgrade the system could do:
ostree --repo=/ostree/repo prune --depth=2 gnomeos-3.4-i686-runtime
This would remote all objects that aren't in the current build and the
previous one.
This totally breaks when the file we're trying to request was already
gzip'd. We don't want to uncompress e.g. man pages because that
breaks content-addressed storage.
Before we were creating randomly-named temporary files in repo/tmp
when downloading via pull, but that means if the download process is
interrupted, we have to redownload everything again.
Let's still keep the concept of a "transaction" where files are
stored in the repository as atomically as possible (i.e. we
do a bunch of rename() calls), but now we also have an explicit
"tmp/pending/objects" directory that contains named objects.
This allows us to then skip redownloading things that are pending.
Otherwise we run in inode order which is unpredictable. In particular
this causes problems because we might run e.g. the gtk+ trigger before
the gdk-pixbuf one. And ldconfig should really be first.
Merge the code from ostree-init; now that we're back to targeting an
initramfs (dracut), we don't need to statically link the binary, so
there's no strong reason to have a separate module.
The builder wants the ability to mark a given file as e.g. setuid. To
implement this, the repo now has a callback-based API when importing a
directory to modify or remove items.
The commit tool accepts a "statoverride" file as input which looks like:
+mode /path/to/file
If multiple files have the same hash, we need to ensure we're not
overwriting other tempfiles in the same transaction. Instead
just delete them, since we know they're in the repo.
I'm trying to keep ostree as being closer to just being the versioning
filesystem, so let's split out the triggers into a different binary
(although still namespaced ostree-).
* Only create one build commit which contains multiple artifact trees,
rather than one per artifact. This is atomic. We can use the new
compose syntax like foo:/devel to slice out the /devel tree.
* Create the minimal buildroot for each component by composing the
previous components in the build order, instead of continually
updating one big tree.
* Ensure the artifact builder gets empty directories in /etc
This way other meta-build projects could use it; mainly mock/pbuilder.
Also I don't have to keep running chown root:root; chmod u+s in a
separate root terminal after every install.
The collection of Python scripts here have gotten to the point where
we need to share code. Start refactoring things so that we have one
main command which imports subcommands as libraries.
The tar files we're making of artifacts don't include parent
directories. Now we could change the builder to make them, but we can
also just autocreate them on import. Mode 0755 with no xattrs seems
OK here.
It's pretty trivial to map a previously existing commit tree into a
mutable tree too. While we're here change the command line arguments
for commit so that we can now properly overlay any combination of
directory, commit, or tarfile.
Rather than offering high level "commit directory", instead perform
operations on a mtree. Commits are treated more like regular objects.
Change the commit builtin to drive this all at a lower level.
The tar import code forced the resuscitation of a hackish "FileTree"
data type for representing an in-memory tree. Split this out
into an OstreeMutableTree class for future use by any other in-memory
tree construction.
Add a simple KEY=VALUE metadata file format, and rather than
assuming 'basename' at a low level, allow passing e.g. NAME=gtk3
to override "gtk+".
The wrapper scripts are annoying...for now let's just remove them.
A regular libfoo.so not in one of the regular directories should go in
runtime. (Probably we should double check it's a regular file too).
Also, delete .la files unconditionally.
ostbuild will generate two artifacts: foo-runtime.tar.gz and
foo-devel.tar.gz in the general case. When committing to the devel
tree, it'd be lame (i.e. slower and not atomic) to have to commit
twice.
One thing that made this take significantly longer than it might
have otherwise is that we have to keep PWD "up to date" - otherwise
we hit bugs in glibc's getcwd() implementation.
This will allow us to have hardlink checkouts of archives. A key use
case here is an archive repo of an OS (with root-owned files etc.)
where we want to do builds in a user tree.
A positive side effect of doing things this way is that now the SHA256
checksums for a given file should be identical regardless of whether
it's stored in an archive or bare repository.
It's too confusing that we call the mode "archive" but the actual
files ".packfile". Also, git already has a "packfile" that serves a
totally different purpose.
To use CLONE_NEWPID we have to actually call clone() because it's
not supported by unshare().
To enable CLONE_NEWPID to be useful, we have to allow creating a new
proc mount rather than binding an existing one.
Colin Walters
Matthias Clasen
Giovanni Campagna
Stef Walter
Adrian Perez
Carl-Anton Ingmarsson
Diego Escalante Urrelo