bazzite dnf5 unstable builds out of space
all said, i don't think dnf5 is actually doing a full "dnf update" as I above suggested it might be...
when i do a "bazz0" pre-update image... the total image size is another 1.4GB larger than what I had before
50 Replies
@M2 @Kyle Gospo
I'm looking at this from a different angle
I just looked at the Maximize Build Space stop
ublue-os/remove-unwanted-software@v7
it's only cleaning about 3.5 GB of space... and tons of packages are not even installed which it's trying to remove, so i think that may be out of date for Ubuntu 24.04 builders
current start of action:
/dev/root 72G 45G 27G 63% /
after cleanup:
/dev/root 72G 35G 37G 49% /
so, it IS cleaning about 10GB but i still think it's missing a good bit of what it should be doingoh holy shit dude
the answer is obvious
fucking the new ubuntu image from github
they reworked the thing.
there's a huge issue in github with all the changes, people complaining, etc.
AND I have been merging the renovate updates to this action
shit I've been dealing with this with work shit and didn't put 2 and 2 together?
I'm going to check something.
My Achillobator PR runs on a container image. The host may use a different base image, since it would make sense for them to have a slimmer OS. It only needs Docker.
So it will depend on how they implement things
I’m working on fixing our disk space cleanup action now
Isn't there an upstream one that the Ublue action builds from?
yeah, we forked and modified
yeah so, this was supposed to come out in the summer but they kept punting
it's not just a version bump to 24.04 they reworked the stuff they included, etc.
GitHub
Issues · actions/runner-images
GitHub Actions runner images. Contribute to actions/runner-images development by creating an account on GitHub.
it's a rolling upgrade to -latest that started in december and will finish end of this month, though we specify the version like good cloud nerds.
Still though, I would expect cleaning actions to need work
some people are pissed I read some good ones. 😄
Well, the good news is we have a lead to fix it 😄
This makes a lot of sense.
My cosmic Nvidia image keeps requiring me to remove more or more stuff in order to build and i didn't think about the maximize space not working as well anymore
yep, and i recently hit the same kind of concern on my personal image
we can remove the swap file!
sherman on 🔥
i wonder if we want to remove the swapfile
ok, i think this is going to help some
53 GB available lol....
and we could remove the swapfile also, if we wanted, but this does not
If we remove everything except what's required for Docker, will that free up much more space? Or are we almost at that point already?
for comparison, previous version of the cleanup action:
nearly at that point... i'm still not removing:
- CodeQL Action Bundles (~5GB)
- Swapfile (~4GB)
otherwise removing everything already on image
- .NET
- Android
- GHC/Haskell
- pre-cached Docker images
- large Apt packages
- cached tools
but all this stuff is configurable from the action call with inptus
Awesome! The CodeQL action bundles probably can also be removed?
honestly, feels like we could just use the upstream image and set the proper inputs
we aren't doing anything except defaulting the inputs to true at this point
(and adding optional sudo)
The upstream works pretty well IMO
What were we doing before?
before, we removed a few packages which upstream hadn't yet removed
Oh. So upstream has caught up and improved beyond our fork since then?
sgtm, one more repo we can delete, makes sherman happy
yep
DO IT. And let the English see you do it.
i'm running out of time today
async work ftw, document and gooooooooooooooooooooooooooooooooooooooooooooooooo
but i'll test upstream direct once, and then test bazzite as an example
Do we want to keep maintaining our fork, but just sync from upstream periodically? We've used our repo in image templates and I'm sure many other repos also do
we know what the issue is cc @Kyle Gospo
what do the bazzite kids say?
i think we should merge the PR i have anyway, since people are using our action
DO IT
ugh
i have no idea why it's now saying there are conflicts
i'm stepping away. i'm super frustrated.
my recomendation, just use upstream: https://github.com/AdityaGarg8/remove-unwanted-software
we found the root of the issue, it's a win
Nice work you guys
That's huge
I can try to get the action fixed up again now if you haven’t already
I had company over but they left
I moved mine to upstream
but we can fix ours for the other projects using ours
or at the very least mark it as deprecated
github's UI is killing me
i keep creating PR's in the wrong repo
i hate github's "FORK" model
GitHub
feat: merge upstream updates for 24.04 etc by bsherman · Pull Reque...
This pulls the latest updates from upstream action, which should result in better performance
@Kyle Gospo we got a successful build of unstable? 😮
hah, i think the new changes to this nuke
just when setup via the extractions/setup-just action
yes, because it installs to /opt/hostedtoolcache/just/1.38.0/x64/just and that gets nuked by default now... the simple solution is probalby just move such a setup action to AFTER the remove software stepm2 explained once why we don't use the action, I forgot
Just that it wasn't on PATH for root
yeah, and this, it's not a deal breaker at all
yepp. We can work around by doing which just and and linking it to /usr/local
for the PATH issue, yeah
but my point is new version of
ublue-os/remove-unwanted-software now removes everything under /opt/hostedtoolcache which is where extractions/setup-just installs just
so, our best practice is probably what you did with a custom install-just action
but the workaround for using extractions/setup-just is to run it after freeing disk space