-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fedora-toolbox:39 image is over 5GB due to missing hardlinking #1389
Comments
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?)... |
In particular comparing new 38 and 39 toolboxes: /usr/lib64 grows from 423M to 2.0G |
@raphael-costa I don't think you need to pull the toolbox container daily though? |
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 |
Okay I think this is another case of redhat-imaging/imagefactory#412 unfortunately |
Maybe rather like https://pagure.io/releng/issue/11712 |
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.
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 That said, I could be misunderstanding his explanation entirely, it's beyond my ability. |
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. |
Copied from https://github.com/containers/toolbox Removed the README.md. See: containers/toolbox#1389 See: https://bugzilla.redhat.com/show_bug.cgi?id=2245066 See: https://pagure.io/releng/issue/11735 See: redhat-imaging/imagefactory#412
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 |
This is now fixed in the latest |
Thanks for the reference, @cgwalters , @owtaylor also pointed to it elsewhere. |
Yes, let's close this as per https://bugzilla.redhat.com/show_bug.cgi?id=2245066 and https://pagure.io/releng/issue/11735 |
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)
The text was updated successfully, but these errors were encountered: