How does ostree identify 'new' commits?

[fwilhe]

I have the following setup:

I'm booting a system that has one commit 03....

I have a remote that has two commits, the same as the booted system 03... and another one that adds/modifies a few files 97... which has 03... as the parent commit.

On the booted system:

$ ostree log debian/testing/arm64
commit 03ec26bb38463037cef6454dde5dbe13f419c9332cfd693c727131488606bd2f
ContentChecksum:  c39a996de4a8bbd560ddfc9e14a7d74df01b6ab2351b07f02ff453bd975b3ec3
Date:  2023-09-26 13:30:55 +0000

    Debian testing build 2023-09-26T13:30:25UTC

My remote repo:

$ ostree log --repo=remote-repo debian/testing/arm64
commit 97910a54664b7cf6c6cea9124fd19cfc424b2b6832915a83562983cd66c7dcee
Parent:  03ec26bb38463037cef6454dde5dbe13f419c9332cfd693c727131488606bd2f
ContentChecksum:  a89ced80a348b5c42050f26964d6bab5476b094f6371830396412bb6ca07d8ee
Date:  2023-09-26 13:31:31 +0000

    Debian testing build 2023-09-26T13:31:01UTC

commit 03ec26bb38463037cef6454dde5dbe13f419c9332cfd693c727131488606bd2f
ContentChecksum:  c39a996de4a8bbd560ddfc9e14a7d74df01b6ab2351b07f02ff453bd975b3ec3
Date:  2023-09-26 13:30:55 +0000

    Debian testing build 2023-09-26T13:30:25UTC

The booted system has the remote configured and it can pull the new commit:

$ ostree pull origin
5 metadata, 2 content objects fetched; 19 KiB transferred in 18 seconds; 79 bytes content written

But when I try to do an upgrade, OSTree claims 'no update available':

$ ostree admin upgrade

No update available.

But if I specify the commit id to upgrade, it works:

$ ostree admin upgrade --override-commit=97910a54664b7cf6c6cea9124fd19cfc424b2b6832915a83562983cd66c7dcee

...
Copying /etc changes: 0 modified, 0 removed, 0 added
Bootloader updated; bootconfig swap: yes; bootversion: boot.0.1, deployment count change: 1

I have tried to investigate the issue. I see the 'no update available' message comes from here because changed is false.

changed's value is determined here in ostree_sysroot_upgrader_pull_one_dir based on a comparision of the old and new revision (commit id).

What I don't understand is why self->new_revision does not seem to have the value 97... in my case. My understanding based on the code and my experiments is that both from_revision and self->new_revision have the value 03... which leads to the 'no update available' message.

It looks like self->new_revision is only changed when the commit is overriden explicitly. Am I looking at the wrong code?

Can someone tell me how I can make the upgrade without explicitly specifying the latest commit id? I do want to upgrade to the latest commit without any exceptions.

[dbnicholson]

My guess is that the deployment origin file isn't setup correctly and therefore upgrade doesn't know what ref it should be looking for. Can you post the output of ostree admin status? Might also be interesting to run ostree admin upgrade --verbose, but I don't know if there are actually any useful messages that would be added.

[fwilhe]

Hi @dbnicholson, thanks for looking into it. Hope this information helps:

In my already upgraded system:

$ ostree admin status
* gardenlinux 97910a54664b7cf6c6cea9124fd19cfc424b2b6832915a83562983cd66c7dcee.0
    origin refspec: debian/testing/arm64
  gardenlinux 03ec26bb38463037cef6454dde5dbe13f419c9332cfd693c727131488606bd2f.0 (rollback)
    origin refspec: debian/testing/arm64

On my newly built rebuilt image (new commit ids, parent commit 1332dccbf7e40ec2791c68537e56b1fef076eb5de6d7f244b6026ec26c0fad75, second commit f7d058da7c2fd6d302e66e28378ffcf869a4036fb14724457fc7a62255cd7373):

$ ostree admin status
* gardenlinux 1332dccbf7e40ec2791c68537e56b1fef076eb5de6d7f244b6026ec26c0fad75.0
    origin refspec: debian/testing/arm64
$ ostree admin status --verbose
OT: using fuse: 0
OT: Deployment 1332dccbf7e40ec2791c68537e56b1fef076eb5de6d7f244b6026ec26c0fad75.0 unlocked=0
* gardenlinux 1332dccbf7e40ec2791c68537e56b1fef076eb5de6d7f244b6026ec26c0fad75.0
    origin refspec: debian/testing/arm64

$ ostree admin upgrade --verbose
OT: using fuse: 0
OT: Deployment 1332dccbf7e40ec2791c68537e56b1fef076eb5de6d7f244b6026ec26c0fad75.0 unlocked=0

No update available.

deployment origin file isn't setup correctly

this might very well be. I've set up the remote via this command (the remote is acually on localhost for testing purposes):

OSTREE_SYSROOT="$MYROOT/sysroot"
OSTREE_REPO=$OSTREE_SYSROOT/ostree/repo
OSTREE_REF="debian/testing/arm64"
ostree remote --repo=$OSTREE_REPO add --no-gpg-verify --no-sign-verify origin http://localhost:8000 $OSTREE_REF

[dbnicholson]

In my already upgraded system:

$ ostree admin status
* gardenlinux 97910a54664b7cf6c6cea9124fd19cfc424b2b6832915a83562983cd66c7dcee.0
    origin refspec: debian/testing/arm64
  gardenlinux 03ec26bb38463037cef6454dde5dbe13f419c9332cfd693c727131488606bd2f.0 (rollback)
    origin refspec: debian/testing/arm64

This is a local ref. I.e., one under /ostree/repo/refs/heads. You need a remote refspec, which for you would (I believe) be origin:debian/testing/arm64. Without that, there's nothing to pull from.

When you do the original deployment, you want to specify the remote refspec to deploy from. Like ostree admin deploy origin:debian/testing/arm64. You can look at the contents of the deployment origin files in /ostree/deploy/*/deploy/*.origin. For testing you can just fix that file in place and try running ostree admin upgrade again.

[fwilhe]

I think we're on the right track. Thanks :)

What's still confusing me:

How does admin deploy relate to admin upgrade?

Can I give the correct remote ref into the ostree remote add command?

[dbnicholson]

admin upgrade is essentially just:

1. ostree pull $deployment_origin_remote $deployment_origin_ref
2. If there is a newer commit, ostree admin deploy it

ostree remote add just wires up a remote repo by name. Just like git remote add. You can add some configuration so that running a bare ostree pull myremote pulls a specific set of refs, but that's unrelated to what the deployment will use. That's what you're specifying at the end of your remote add command above. What the deployment uses (and therefore, what ostree admin upgrade and friends use) is entirely controlled by the entry in the deployment's origin file.

You can think of a deployment as analogous to a git checkout. First the data needs to be pulled into the repo (ostree pull/git fetch), then the files can be checked out to the disk (ostree admin deploy/git checkout). The combined ostree admin upgrade operation is therefore most equivalent to git pull (i.e., fetch + checkout).

[fwilhe]

Update: Manually editing the *.origin file works, but I wonder why I need to do that. I would expect that I can have the remote_name:branch_name ref in the deploy command and that this is reflected in that origin file, but that does not seem to be the case. ostree admin deploy throws an error when I try to do that.

[dbnicholson]

Can you show the command you're running and the error?