Skip to content

Inturrupt during download leads to repo corruption

I think this is the second time this has happened already. Here's an snippet from an old version of the README:

Investigate weird repo corruption

  • Missing .dirtree objects
  • Fixed by doing ostree prune (which fails) followed by an ostree pull
  • ostree pull ... --require-deltas breaks the repo, seems like. Therefore updated's Pull does too
  • Theory: if there's deltas from a->b and b->c but you're upgrading a->c and you interrupt the download, it corrupts the repo?
  • When I eventually somehow coerced the repo back into shape, the download proceeded without deltas

While this issue isn't exactly the same, it is similar

Captured commandline of this happening

Here's me starting the pull & inturrupting it

[adrian@adrians-macbook:~]$ updatectl deploy
✓ Resolving remotes
⠏ Downloading content: 27% (6/22 obj)^C

Edit for clarity: I'm almost certain ostree was pulling w/ static deltas. The low object count gives it away (I did this same pull on another machine without deltas, and it took a couple thousand objects). Also, once I recover the repo, it uses deltas.

At this point I made a one-line change to the source of updated, but that is irrelevant for two reasons:

  • The first time I ran into this, I made no such changes
  • The change is purely visual. I just uncommented the line that sends the fine progress report. It was commented out to force updatectl to use coarse progress reporting (6/22 obj) instead of fine reporting (13 Mb/150 Mb)

Now, me restarting the deploy:

[adrian@adrians-macbook:~]$ updatectl deploy
✓ Resolving remotes
✓ Downloading content
✗ Writing OSTree commit
ERROR: Failed to deploy updates: No such metadata object 7999c93f52af135e85895d0185acada16fde663fbfae164b959c5c68fa0eb055.dirtree

Oops that's bad. I tried restarting the deploy a couple of times to see if it would fix itself. It did not. Maybe ostree prune will?

[adrian@adrians-macbook:~]$ doas ostree prune
doas (adrian@adrians-macbook) password: 
error: No such metadata object 7999c93f52af135e85895d0185acada16fde663fbfae164b959c5c68fa0eb055.dirtree

How about fsck?

[adrian@adrians-macbook:~]$ doas ostree fsck -a --delete
doas (adrian@adrians-macbook) password: 
Validating refs...
Validating refs in collections...
Enumerating objects...
Verifying content integrity of 13 commit objects...
error: No such metadata object 7999c93f52af135e85895d0185acada16fde663fbfae164b959c5c68fa0eb055.dirtree
Edited by Adrian Vovk