mirror of
https://github.com/ostreedev/ostree.git
synced 2025-01-10 05:18:30 +03:00
4982306e67
When we estimate how much space a new bootcsum dir will use, we weren't accounting for the space overhead from files not using the last filesystem block completely. This doesn't matter much if counting a few files, but e.g. on FCOS aarch64, we include lots of small devicetree blobs in the bootfs. That loss can add up to enough for the `fallocate()` check to pass but copying still hitting `ENOSPC` later on. I think a better fix here is to change approach entirely and instead refactor `install_deployment_kernel()` so that we can call just the copying bits of it as part of the early prune logic. We'll get a more accurate assessment and it's not lost work since we won't need to recopy later on. Also this would not require having to keep in sync the estimator and the install bits. That said, this is blocking FCOS releases, so I went with a more tactical fix for now. Fixes: https://github.com/coreos/fedora-coreos-tracker/issues/1637 |
||
|---|---|---|
| .. | ||
| boot | ||
| libostree | ||
| libotcore | ||
| libotutil | ||
| ostree | ||
| rofiles-fuse | ||
| switchroot | ||