[SOLVED] Error when upgrading system: rpm package could not be verified

Project Discussion
1

When trying to upgrade my silverblue 32:

> # rpm-ostree upgrade
> ....
> Importing packages... done
> error: importing RPMs: /var/cache/rpm-ostree/repomd/updates-32-x86_64/packages/qt5-srpm-macros-5.14.2-3.fc32.noarch.rpm could not be verified
> # ls -al /var/cache/rpm-ostree/repomd/updates-32-x86_64/packages/
> -rw-r--r--. 1 root root    0 Jul 12 21:40 qt5-srpm-macros-5.14.2-3.fc32.noarch.rpm
> -rw-r--r--. 1 root root    0 Jul 12 21:40 rdma-core-30.0-1.fc32.x86_64.rpm
> -rw-r--r--. 1 root root    0 Jul 12 21:40 seahorse-3.36.2-1.fc32.x86_64.rpm
...

How can I deal with this error? What are packages listed in /var/cache/rpm-ostree/repomd/updates-32-x86_64/packages ?

Thank you for help

2

Try rpm-ostree cleanup -m then retry the upgrade. Your metadata could be out of whack.

3

it seems better but I have anew error now:

 # rpm-ostree upgrade
 error: importing RPMs: Importing package 'thunderbird': Importing archive: Writing content object: min-free-space-percent '3%' would be exceeded, at least 130.2 MB requested

# df
Filesystem                                  1K-blocks      Used Available Use% Mounted on
devtmpfs                                      3903496         0   3903496   0% /dev
tmpfs                                         3938312    738312   3200000  19% /dev/shm
tmpfs                                         3938312     10288   3928024   1% /run
/dev/mapper/fedora_desktop--a2nbe2u--2-root 146728960 141698196   5030764  97% /sysroot
tmpfs                                         3938312       104   3938208   1% /tmp
/dev/mapper/fedora_desktop--a2nbe2u--2-home   5232640   4374984    857656  84% /var/home
/dev/loop0                                      56320     56320         0 100% /var/lib/snapd/snap/core18/1754
/dev/loop2                                     160512    160512         0 100% /var/lib/snapd/snap/gnome-3-28-1804/110
/dev/loop1                                      96256     96256         0 100% /var/lib/snapd/snap/core/9066
/dev/loop4                                      63616     63616         0 100% /var/lib/snapd/snap/gtk-common-themes/1506
/dev/loop3                                     164096    164096         0 100% /var/lib/snapd/snap/gnome-3-28-1804/116
/dev/loop5                                     102272    102272         0 100% /var/lib/snapd/snap/ipfs-desktop/17
/dev/loop6                                      93952     93952         0 100% /var/lib/snapd/snap/ipfs-desktop/7
/dev/nvme0n1p6                                 999320    154900    775608  17% /boot
/dev/loop7                                      56064     56064         0 100% /var/lib/snapd/snap/core18/1650
/dev/loop9                                     117120    117120         0 100% /var/lib/snapd/snap/zulip/23
/dev/loop8                                     115968    115968         0 100% /var/lib/snapd/snap/zulip/22
/dev/loop10                                     46080     46080         0 100% /var/lib/snapd/snap/gtk-common-themes/1440
/dev/nvme0n1p5                                 499432      9032    490400   2% /boot/efi
/dev/loop11                                     91264     91264         0 100% /var/lib/snapd/snap/core/8268
tmpfs                                          787660        92    787568   1% /run/user/1000

I am not sure where I shall find some more free space.
Furthermore, may you quickly explain what your command do?

Thank you

4

The command cleans up the metadata about your specific commit on your system. So it makes the remotes ref’s (repo references) correct, and makes sure the data reflects your layering state.

Disk usage … are you using LVM? Your sysroot is pretty full. Maybe try sudo ostree prune to see if it can clean your tree a bit and get back some room.

[edit] this link is about this very issue Sysroot low on disk space issue - #4 by jgarciao and there is a good few suggestions at the bottom, specifically

# flatpak cleanup
flatpak uninstall --unused

#docker/podman cleanup
docker system prune -a
podman system prune -a

#Retain only the logs from last 2 days
journalctl --vacuum-time=2d
1 Like
5

trying to do some cleaning, I found a big directory:

# pwd
/sysroot/home/gabx/.local/share/containers
# du -h --max-depth=1 | sort -hr
41G	./storage
41G	.
84K	./cache
# ls -al storage/vfs/dir
drwx------. 37 gabx gabx 4.0K May 16 16:41 ./
drwx------.  3 gabx gabx   17 Dec  4  2018 ../
drwxr-xr-x. 17 gabx gabx  251 May 16 16:31 0c52ce3d656ab291187e9f90fcd847cdcd2d244f24cc04cf6b31f2016cbcfd85/
dr-xr-xr-x. 19 gabx gabx  254 Nov 29  2019 0f9a74ec05578deb3103199c4702ef0f516b5c66f0cca22af2002fc8e73fdb7b/
drwxr-xr-x.  4 gabx root   29 Dec  4  2018 108b1c56d076789d94323e2bcaa7eb926485f8fc841d6c08335f39412d94b71c/
.....

As you can see the /sysroot/home/gabx/.local/share/containers/storage/vfs/dir is a huge dir with lots of sub dir with names being a suite of letters and numbers. I don’t have any images orcontainers atm, so I wonder if I can clean this whole directory or not.

Btw I marked the topic as solved as the low space is not directly tied to my original issue.
Thank you for help

6

That dir can be deleted, if you don’t use containers you can delete the containers directory entirely. It looks like there is a container made in May of this year. If you used toolbox at any time those could be what you see. If you try listing containers with toolbox or podman, the ID’s are the long numbers at the end, but when you list them you only see the first 8 or so digits I think.
toolbox-list for toolbox containers
podman ps -a for podman to list any container on the system

7

now:

# df -h
...
/dev/mapper/fedora_desktop--a2nbe2u--2-root  140G   61G   79G  44% /sysroot
....
8

Well that’s better. At least you should be able to update properly now.
Also after doing rpm-ostree cleanup -m to clear out the cache and flush any pending transactions or incomplete ones. Then try rpm-ostree refresh-md to refresh your repo metadata.