# Corrupted File Object in Ostree
**URL:** https://universal-blue.discourse.group/t/corrupted-file-object-in-ostree/5119
**Category:** General
**Created:** [November 15, 2024, 3:21pm UTC](https://universal-blue.discourse.group/t/corrupted-file-object-in-ostree/5119 "2024-11-15T15:21:21Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@brianalbertmonroe](https://universal-blue.discourse.group/u/brianalbertmonroe)
#### Post date: [November 15, 2024, 3:21pm UTC](https://universal-blue.discourse.group/t/corrupted-file-object-in-ostree/5119/1 "2024-11-15T15:21:21Z")
I have more or less the same issue as this post:
> [@How to deal with corrupted file objects in ostree?](https://universal-blue.discourse.group/t/how-to-deal-with-corrupted-file-objects-in-ostree/1090):
>
> Hi there, just a few questions to help me understand working with ostree-based systems a little better. While dealing with my issues outlined [here](https://universal-blue.discourse.group/t/rpm-ostree-upgrade-crashes/1001/2), I also investigated whether corrupted files in ostree could be the culprit (it turned out to be something else). I ran sudo ostree fsck -a, which did (and still does) yield some corrupted file objects. Currently I get: In commits 2275a8fe598a30dd3aea07b8cc3b7df5925c6809338ae1fdc20258a58ef37500, 9b978aa048e4371ea6b9cef368ad8ebb4416ee3f4039b829c2444…
The output of `ostree fsck --all` is:
```auto
In commits
0c0dbf56935dd355ed72a042267fd51f85568e8ffcbe8ff71131ab0238e9a1e6, 32cf395b60d84c9fa922cb9f5bc4fd4dc8f379ca8cbae9832d213b8f09d66d77:
fsck content object 86aff83c9d3cd05c1b4f6a153f50c11fef536c791b5788d29519e4c185ac0255:
Corrupted file object;
checksum expected='86aff83c9d3cd05c1b4f6a153f50c11fef536c791b5788d29519e4c185ac0255' actual='bf13d8fe63612425b89f526a906f06359a1a71ac71902caef8a7160558d91187'
In commits
cf829480fac64e80f95cff4eddea9621c461022a0ab2ace5f5742fd8903c18d0, eb2636b6a33cda5ec7e97c55de5b2f1175ca375f74fbfa14a7a68a5e72799961, 0c0dbf56935dd355ed72a042267fd51f85568e8ffcbe8ff71131ab0238e9a1e6:
fsck content object e2b13cdbe0ef6facc26c5938f51bcb18d5fc293d65ab846d19e3ce8c63df38f5:
Corrupted file object;
checksum expected='e2b13cdbe0ef6facc26c5938f51bcb18d5fc293d65ab846d19e3ce8c63df38f5' actual='933b8b10b69525ffe6c613f3a30e71b2a610432b40f29df5f9c60db06900b02b'
In commits
ebd93a2751154935521ed911b3392e5ce7c15ac75876901cdbddefcdc3e30dbf, e96eaacd6bc15644007c52a32ce62f11c093198d2d525d507d86b76c94251167, cb68ea52759ad596780d42e412a830f3361b374fb5afec0d596124fff324df71, 9d76a5969db5eb27579d5ee03d8c43fbcdcd56d646c1c2b7aa893ab5ca7c7b3c:
fsck content object 9536e3d631fe1f638f885ec2fe038ff2f6f0a3be2605404df9197b81c4fea673:
Corrupted file object;
checksum expected='9536e3d631fe1f638f885ec2fe038ff2f6f0a3be2605404df9197b81c4fea673' actual='bf13d8fe63612425b89f526a906f06359a1a71ac71902caef8a7160558d91187'
```
My understanding of ostree is that the layers of the OS are applied one on top of the other. Is there any way I can just foribly re-download those commits and rebuild the whole system? I cannot seem to find any method of doing this anywhere and I’d rather not have to re-install to fix this.
---
### Author:  [@brianalbertmonroe](https://universal-blue.discourse.group/u/brianalbertmonroe)
#### Post date: [November 20, 2024, 3:47am UTC](https://universal-blue.discourse.group/t/corrupted-file-object-in-ostree/5119/2 "2024-11-20T03:47:22Z")
I ended up reinstalling to fix the issue. The clean install had no corrupted objects. However, after upgrading last night to bazzite-deck:stable version 41.20241118.2, I have the same problem again.
What’s worse, whenever I upgrade I can never boot into the new upgrade window, it always gets stuck on the bazzite loading screen. I have to hard reboot the device, reboot into the older image via the grub menu, and try again.
Any idea why this would corrupt on a fresh upgrade right after a fresh re-install?
---
### Author:  [@tulilirockz](https://universal-blue.discourse.group/u/tulilirockz)
#### Post date: [November 20, 2024, 10:17pm UTC](https://universal-blue.discourse.group/t/corrupted-file-object-in-ostree/5119/3 "2024-11-20T22:17:03Z")
Honestly absolutely no idea why the hell that is happening, it probably will fix itself with newer images though. Try updating your system with bootc, maybe it will work a bit better? (`sudo bootc upgrade`). You can also try moving to `:unstable` to see if it fixes the corrupted objects too