Pull the cleanup code to a helper function, and ensure we delete
leftover temporary files also when aborting a transaction. Mainly
this will happen if a local 'ostree commit' fails.
While we're here, also change it to use gs_shutil_rm_rf() which also
handles directories, should we start using those.
Reviewed-by: Jeremy Whiting <jpwhiting@kde.org>
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
When running the test-admin-deploy-1.sh unit test,
cat shows the following error:
cat: boot/vmlinuz-3-6.0: No such file or directory
due a trivial typo in the kernel image file name.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=706371
make distcheck was unhappy for various reasons:
* headers aren't data, so use _HEADERS otherwise compilation fails
* Mark the gir & typelib data as cleanfiles so they aren't left around
after make clean
* Don't nuke the .la file. This breaks make uninstall, leave it up to
distributions to not install .la files if they don't want them.
https://bugzilla.gnome.org/show_bug.cgi?id=705850
Jeremy Whiting
Colin Walters
Vivek Dasmohapatra
Javier Martinez Canillas
Sjoerd Simons
Sjoerd Simons