containers/toolbox

fedora-toolbox:39 image is over 5GB due to missing hardlinking

raphael-costa opened this issue · 12 comments

raphael-costa commented

Is your feature request related to a problem? Please describe.
Fedora 39 podman image takes 5.59GB of disk space and it gets huge updates every day.
Fedora 38 podman image takes 1.67GB, the image itself receives very few updates but sudo dnf update is very quick anyhow.

Describe the solution you'd like
Whatever mistaken decision was taken here, forget about it, it was a mistake.

Describe alternatives you've considered
At least make the image slimmer.

Additional context
It's already difficult to run Silverblue on cheaper hardware, rpm-ostree takes an eternity and flatpak is extremely space inefficient, we need to pay attention to these things.

EDIT: Clarified that I'm referring to the podman image. I have other docker images loaded and I update them as part of my update script with podman pull (podman image list --sort repository --format "table {{.Repository}}:{{.Tag}}" -n)

juhp commented

This seems true actually 😱 hmm

petersen@localhost-live:~$ podman image list registry.fedoraproject.org/fedora:39
REPOSITORY                         TAG         IMAGE ID      CREATED     SIZE
registry.fedoraproject.org/fedora  39          63ddbc853d12  2 days ago  190 MB
petersen@localhost-live:~$ podman image list registry.fedoraproject.org/fedora-toolbox:38 
REPOSITORY                                 TAG         IMAGE ID      CREATED      SIZE
registry.fedoraproject.org/fedora-toolbox  38          ff39b6cc1e44  10 days ago  1.67 GB
petersen@localhost-live:~$ podman image list registry.fedoraproject.org/fedora-toolbox:39 
REPOSITORY                                 TAG         IMAGE ID      CREATED     SIZE
registry.fedoraproject.org/fedora-toolbox  39          2cbb577df155  2 days ago  5.59 GB

Dunno if that explains why it took soo long to download (like over an hour for me?)...

juhp commented

In particular comparing new 38 and 39 toolboxes:

/usr/lib64 grows from 423M to 2.0G
and in particular: /usr/lib64/dri/ jumps from 43M to 1.6G !

juhp commented

@raphael-costa I don't think you need to pull the toolbox container daily though?

raphael-costa commented 
petersen@localhost-live:~$ podman image list registry.fedoraproject.org/fedora:39
REPOSITORY                         TAG         IMAGE ID      CREATED     SIZE
registry.fedoraproject.org/fedora  39          63ddbc853d12  2 days ago  190 MB

This is pretty cool, it has a functional dnf and packages like vi though it lacks utilities like man. Also it doesn't work with toolbox, I got an error Error: invalid entry point PID of container fedora_test. I don't understand why this can be 379MB in disk space and yet we have an almost 6gig image instead.

juhp commented

Okay I think this is another case of redhat-imaging/imagefactory#412 unfortunately

raphael-costa commented

@raphael-costa I don't think you need to pull the toolbox container daily though?

That would mean adding an exception to my update script, I'm not doing it for toolbox, but rather for sagemath and a couple other essential images that I need for my work.

And I like to keep things updated, I've always updated my computer every day. It's been 15 years now.

Maybe rather like https://pagure.io/releng/issue/11712

I don't think so: "Because this is a tarball bug, it doesn't affect a) installed size", that's not true in this case, you can check with sudo du -sh ~/.local/share/containers/, mine shrank a solid 3GB and I deleted the F39 image and switched to a F38 image.

That said, I could be misunderstanding his explanation entirely, it's beyond my ability.

juhp commented

I opened https://bugzilla.redhat.com/show_bug.cgi?id=2245066 but this might be a releng issue (I mean kickstart or more likely imagefactory), since the 39 image is created as a base image unlike earlier releases' layered images.

cgwalters commented

See also ostreedev/ostree#3060 - I don't think it's involved but just for reference.

However longer term I think we want to do https://coreos.github.io/rpm-ostree/container/#creating-base-images

juhp commented

This is now fixed in the latest fedora-toolbox:39 and fedora-toolbox40 images: this issue can be closed.

debarshiray commented

See also ostreedev/ostree#3060 - I don't think it's involved but just for reference.

Thanks for the reference, @cgwalters , @owtaylor also pointed to it elsewhere.