Min-free-space-percent error when doing an update

General
1

Hey, yesterday I did the script flow, after the script everything worked well.
Today ujust update gives me the following:

Pulling manifest: ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-gnome:stable
Importing: ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-gnome:stable (digest: sha256:1fdc9ce0dfa781756e985f02659ccb4c95fdce95ce86e7b6abc548942a315dbd)
ostree chunk layers already present: 51
ostree chunk layers needed: 14 (544.0 MB)
custom layers needed: 4 (2.7 GB)
Fetching ostree chunk sha256:73ce1d7159f5 (25.8 MB)... done
error: Importing: Unencapsulating base: Layer sha256:73ce1d7159f563fb5d6d53daff0f9fc7ba1af86a0717401e5b16e8022d1f3504: Importing objects: Importing object be/896c680b0383a1bb90891ad7901831c3ad3e71bafb5a366074b20e8ab5da5c.file: Processing content object be896c680b0383a1bb90891ad7901831c3ad3e71bafb5a366074b20e8ab5da5c: Importing regfile: min-free-space-percent '3%' would be exceeded, at least 69.3 MB requested
System update failed: 
   0: Command failed: `/usr/bin/rpm-ostree upgrade`
   1: `/usr/bin/rpm-ostree` failed: exit status: 1

Location:
   src/steps/os/linux.rs:273
Retry? (y)es/(N)o/(s)hell/(q)uit
2

Looks like you’re running out of space on your disk, do you have a bunch of old snapshots pinned or something?

3

umm seems like you are right, my distrobox also claimed the same issue. But I’m not sure why as I have 500Gb in use while this drive is 1TB.
As far as pinning I ran ostree admin status which outputed only 2 images (as default?)
So I’m not sure what is wrong :open_mouth: quite shocking to be honest.

4

Paste in a df -h so we can take a look.

5

cool thanks

/dev/nvme0n1p3  428G  427G  408M 100% /sysroot
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs            16G  144M   16G   1% /dev/shm
efivarfs        128K   12K  112K  10% /sys/firmware/efi/efivars
tmpfs           6.3G   11M  6.3G   1% /run
tmpfs            16G  8.1M   16G   1% /tmp
/dev/nvme0n1p3  428G  427G  408M 100% /var
/dev/nvme0n1p3  428G  427G  408M 100% /var/home
/dev/nvme0n1p2  974M  304M  603M  34% /boot
/dev/nvme0n1p1  599M   13M  587M   3% /boot/efi
tmpfs           3.2G  564K  3.2G   1% /run/user/1000

seems like sysroot is somehow much bigger than it needs to be and the drive halved itself into 50% /home 50% sysroot :\ not sure what happened here

Edit: pic of partitions of his drive
image
t

ps: for checking extra images ive been using: ostree admin status

* default d468bc3421f7531e8aea95c8df49125d60c38aed014b16bccf492afc4164d71e.0
    origin: <unknown origin type>
  default 1642cc0e8dd3a095e566a1fb640fef1af398999fd013bf2e3e352c84668ce77d.1 (rollback)
    origin: <unknown origin type>
6

Can you also run the following commands so that we can see what takes up space?

# container storage for your personal user
sudo du -sh ~/.local/share/containers/
# flatpak storage for your personal user
du -sh ~/.var/app
# cache directory. You can probably safely delete it to free up space
du -sh ~/.cache
7

yes sir and thanks for the follow up.
seems like the computer is bricking due to the low space

7.6G	/home/daniel/.local/share/containers/
1.5G	/home/daniel/.var/app
7.7G	/home/daniel/.cache

seems pretty normal here.

8

Thing is that i dont understand how come the root is only 459GB total but the partition for mvme0n1p3 is 999GB (as shown above in the picture)

image
image602×691 28.4 KB

9

update:
seems like after some reflection I’ve realized that some months ago (this is a machine that was off for a while) I’ve made changes in the btrfs partition so I could reinstall the system and keep some files on another partition.
That way I could move everything back and reinstall without losing files.
After research the command : sudo btrfs filesystem resize max / made the sysroot take the whole space it should’ve been taking in the first place!
Screenshot for the result:

image
image602×691 27.9 KB

10

Seems like you have fixed the critical situation. But we still need to figure out what is taking up so much space. I recommend to install the org.gnome.baobab flatpak and to explore your file system.

I also suggest to run the following command to check if there are any logs that fill up the disk: sudo du -sh /var/log. Baobab will not be able to analyze this directory, because only root has access to all the files in there.

11

seems like the logs are only 500Mbs at the moment.
I think the size situation is quite normal, the rest is mostly games that take alot of space.