Delete Qualcomm DTBs to free up space on aarch64 #1464
Comments
|
Note that this is basically a new occurence of #1247 which will affect our production streams if we don't act. |
|
Potential solutions here for our short term problem:
|
|
For more information, here's a comparison of the different sizes between the very first aarch64 image we built and the latest one. On 34.20210821.3.0: On 38.20230408.1.0: So the kernel only increased by 3M, the initrd by 4M, and the dtb directory by 15M. It'd be nice to be able to trim some of those devicetrees though it's theoretically possible that some users have installed FCOS on some of these boards. |
Depending on the firmwares, if they're SystemReady devices you could in theory remove all of the DTBs. For example in traditional Fedora if the dtb symlink isn't there it will use the DT provided by the firmware, but of course there's some devices that won't boot in that case. What size is /boot? the recommended default from anaconda should be OK. |
|
Looking at the directory of a recent F-38: I would say if you removed qcom you'd get your 14Mb back an be unlikely to have a complaint. apple/amd/cavium/apm could probably go as well but you don't gain much. YMMV |
|
Draft coreos-status email: https://hackmd.io/bq_3hYQHRKapbIZW-UpVtw |
…ch64 This will save us some space while we work on longer term solutions for limited space in the /boot partition. Fixes coreos/fedora-coreos-tracker#1464
|
with coreos/fedora-coreos-config#2367 we now have something like: |
…ch64 This will save us some space while we work on longer term solutions for limited space in the /boot partition. Fixes coreos/fedora-coreos-tracker#1464 (cherry picked from commit 1375c9f)
…ch64 This will save us some space while we work on longer term solutions for limited space in the /boot partition. Fixes coreos/fedora-coreos-tracker#1464 (cherry picked from commit 1375c9f)
|
We discussed this in the community meeting today. |
|
The update with removed qcom files went out in our |
jlebon
changed the title
aarch64
|
The fix for this went into |
dustymabe
added
the
status/pending-testing-release
|
Note we decided not to send out an email for this issue in the end. We believe there are few users (likely none) on these platforms. Nonetheless, I've opened #1467 to track the reversal of this change and serve as a landing point for anyone trying to get FCOS to work on the now broken devices. |
|
The fix for this went into |
dustymabe
added
status/pending-stable-release
|
The fix for this went into |
dustymabe
removed
the
status/pending-stable-release
…ch64 This will save us some space while we work on longer term solutions for limited space in the /boot partition. Fixes coreos/fedora-coreos-tracker#1464
Now that we have autopruning ability we can re-add the qcom dtbs on aarch64 that were dropped in coreos/fedora-coreos-tracker#1464 Fixes coreos/fedora-coreos-tracker#1467
Now that we have autopruning ability we can re-add the qcom dtbs on aarch64 that were dropped in coreos/fedora-coreos-tracker#1464 Fixes coreos/fedora-coreos-tracker#1467
Now that we have autopruning ability we can re-add the qcom dtbs on aarch64 that were dropped in coreos/fedora-coreos-tracker#1464 Fixes coreos/fedora-coreos-tracker#1467
Now that we have autopruning ability we can re-add the qcom dtbs on aarch64 that were dropped in coreos/fedora-coreos-tracker#1464 Fixes coreos/fedora-coreos-tracker#1467
…ch64 This will save us some space while we work on longer term solutions for limited space in the /boot partition. Fixes coreos/fedora-coreos-tracker#1464
Now that we have autopruning ability we can re-add the qcom dtbs on aarch64 that were dropped in coreos/fedora-coreos-tracker#1464 Fixes coreos/fedora-coreos-tracker#1467
…ch64 This will save us some space while we work on longer term solutions for limited space in the /boot partition. Fixes coreos/fedora-coreos-tracker#1464
Now that we have autopruning ability we can re-add the qcom dtbs on aarch64 that were dropped in coreos/fedora-coreos-tracker#1464 Fixes coreos/fedora-coreos-tracker#1467
With our recently implemented extended upgrade testing we are now running a matrix of extended upgrade tests when we do production builds.
With the (unreleased)
38.20230408.1.0nextbuild we are now hitting a problem where we are running out of space on upgrade:Full logs for the upgrade test (
38.20230322.1.0->38.20230408.1.0) are here:The
nextstream is now sitting at two releases with kernel-6.2 and this would be the third:38.20230322.1.0->38.20230402.1.0->38.20230408.1.0Noteworthy is the fact that with 6.2 the kernel changed formatting of the kernel to EFI_ZBOOT.
The usage in /boot/ is only slightly larger but apparently it's enough to get us to a threshold where we run out of space when trying to fit 3 sets of kernel/initramfs at the same time (temporarily on upgrade).
For illustration here is the usage of a non 6.2 kernel deployment and a 6.2 kernel deployment on the same system (this is a
testingstream based system):If I boot
38.20230408.1.0clean I see:The text was updated successfully, but these errors were encountered: