Hi all: I have two old systems (with old nVidia graphics), recently upgraded from f38 to f39 and both at present using nouveau. One was OK-ish, the other had screen-recognition and HDMI-audio issues, and I thought it might be worth trying the more-mainstream f40.
Now the main problem is with the previously OK (single-boot) box, which reports after the download and dnf-testing that
"At least 446 MB more space (is) needed on the / filesystem".
Google (fedoraforum) has a suggestion of trimming the journalctl log, but neither that nor any other space-clearing actions that I have tried has made any difference. KDiskFree shows multi-GB space on all except current /boot and a hopefully inactive remnant of another, much older/boot with a different mount point. Both of those have sizes around 450 MB and free space around 150 MB. TTBOMK only the current 6.8.7 f39 kernel and its rescue version are installed.
Suggestions? Thanks.
John P
John Pilkington composed on 2024-04-30 18:58 (UTC+0100):
Hi all: I have two old systems (with old nVidia graphics), recently upgraded from f38 to f39 and both at present using nouveau. One was OK-ish, the other had screen-recognition and HDMI-audio issues, and I thought it might be worth trying the more-mainstream f40.
Now the main problem is with the previously OK (single-boot) box, which reports after the download and dnf-testing that
"At least 446 MB more space (is) needed on the / filesystem".
Google (fedoraforum) has a suggestion of trimming the journalctl log, but neither that nor any other space-clearing actions that I have tried has made any difference. KDiskFree shows multi-GB space on all except current /boot and a hopefully inactive remnant of another, much older/boot with a different mount point. Both of those have sizes around 450 MB and free space around 150 MB. TTBOMK only the current 6.8.7 f39 kernel and its rescue version are installed.
Suggestions? Thanks.
This is easy enough to fix. I've needed to do this many times.
First, if more than one kernel remains installed, remove all but the latest working one.
If freespace hasn't risen sufficiently following kernel removals, add the kernel to /etc/dnf/dnf.conf locks group so that a new kernel won't be part of the initial upgrade. Then try the system upgrade again.
If that didn't make freespace adequate, navigate to the system-upgrade packages cache.
Find the largest few rpms contained there.
Determine that they are related to X and/or DE or other non-crucial subsystem rather than any crucial basesystem components. Fonts, themes, wallpapers and icons are such candidates.
Force install one with rpm, then delete the rpm.
Check freespace. If not yet adequate, force install another.
When freespace becomes adequate, resume the system upgrade process.
On 2024-04-30 10:58 AM, John Pilkington wrote:
(fedoraforum) has a suggestion of trimming the journalctl log, but neither that nor any other space-clearing actions that I have tried has made any difference.
Have you made snapshots of your system volume, or installed any applications that might create snapshots (something like timeshift or snapper)?
If your filesystem has snapshots, deleting files will not free up space until you also remove the snapshots that contain those files.
On 01/05/2024 00:54, Gordon Messmer wrote:
On 2024-04-30 10:58 AM, John Pilkington wrote:
(fedoraforum) has a suggestion of trimming the journalctl log, but neither that nor any other space-clearing actions that I have tried has made any difference.
Have you made snapshots of your system volume, or installed any applications that might create snapshots (something like timeshift or snapper)?
If your filesystem has snapshots, deleting files will not free up space until you also remove the snapshots that contain those files.
Thank you for this, and to Felix for his instructions too.
I'm not aware of any snapshots, and suspect that Felix has a quicker way of finding the relevant 'freespace' than waiting for dnf's version to appear. Perhaps it's shown during the 'rpm --force' installs? I have around 3400 packages.
I decided to try fixing the issues on the already upgraded f40 box first...
Thanks again,
John
John Pilkington composed on 2024-05-01 09:31 (UTC+0100):
I'm not aware of any snapshots, and suspect that Felix has a quicker way of finding the relevant 'freespace' than waiting for dnf's version to appear. Perhaps it's shown during the 'rpm --force' installs? I have around 3400 packages.
Math is required. Unless your packages cache is elsewhere than on an extX / filesystem, do:
df /
Did it yet increase by as much as the amount of additional freespace required that dnf system-upgrade first reported? If no, upgrade and remove another large rpm from the filesystem, and check again. Repeat until the number has become large enough. This only works as intended with a real remove, not with some file manager that moves to trash instead of actually removing. I use only mc or fcl or various cmdline utils for file management, never Dolphin or Thunar or any other GUI file manager.
Also, if you added kernel* to dnf.conf skip list, you can remove it from the cache. DNF pretends everything in the skip list does not exist. The 5 raw 6.8.7 or 6.8.5 rpms are well upwards of 100MB. When time comes that upgrade has otherwise completed, kernel* must be removed from the skip list to allow dnf to upgrade to the current kernel.
On 01/05/2024 15:51, Felix Miata wrote:
John Pilkington composed on 2024-05-01 09:31 (UTC+0100):
I'm not aware of any snapshots, and suspect that Felix has a quicker way of finding the relevant 'freespace' than waiting for dnf's version to appear. Perhaps it's shown during the 'rpm --force' installs? I have around 3400 packages.
Math is required. Unless your packages cache is elsewhere than on an extX / filesystem, do:
df /
Did it yet increase by as much as the amount of additional freespace required that dnf system-upgrade first reported? If no, upgrade and remove another large rpm from the filesystem, and check again. Repeat until the number has become large enough. This only works as intended with a real remove, not with some file manager that moves to trash instead of actually removing. I use only mc or fcl or various cmdline utils for file management, never Dolphin or Thunar or any other GUI file manager.
Also, if you added kernel* to dnf.conf skip list, you can remove it from the cache. DNF pretends everything in the skip list does not exist. The 5 raw 6.8.7 or 6.8.5 rpms are well upwards of 100MB. When time comes that upgrade has otherwise completed, kernel* must be removed from the skip list to allow dnf to upgrade to the current kernel.
Thank you for this, and for earlier posts that I found elsewhere. The system is now updated to f40 and seems to be running well. I didn't have to use rpm installs from the cache in /var/lib/dnf/system-update.
I think the effective change was to add
"exclude kernel* linux-firmware* java* libreoffice* "
to /etc/dnf/dnf.conf, before repeating everything from the preliminary
"sudo dnf upgrade--refresh" and applying "--allowerasing --skip-broken" in the download.
I suppose a "sudo dnf clean all" had helped too: 88 files removed. After the download KDiskFree reported 3.9 GB free in /, and dnf said that was the total package size. "df / " said 4093160 blocks. After the reboot I removed the excludes, ran dnf upgrade again, and installed locally built MythTV rpms.
That's an account of what I did. I'm afraid it comes with no guarantees.
John P
On Thu, May 2, 2024 at 11:47 AM John Pilkington johnpilk222@gmail.com wrote:
On 01/05/2024 15:51, Felix Miata wrote:
John Pilkington composed on 2024-05-01 09:31 (UTC+0100):
I'm not aware of any snapshots, and suspect that Felix has a quicker way of finding the relevant 'freespace' than waiting for dnf's version to appear. Perhaps it's shown during the 'rpm --force' installs? I have around 3400 packages.
Math is required. Unless your packages cache is elsewhere than on an
extX /
filesystem, do:
df /Did it yet increase by as much as the amount of additional freespace
required that
dnf system-upgrade first reported? If no, upgrade and remove another
large rpm
from the filesystem, and check again. Repeat until the number has become
large
enough. This only works as intended with a real remove, not with some
file manager
that moves to trash instead of actually removing. I use only mc or fcl
or various
cmdline utils for file management, never Dolphin or Thunar or any other
GUI file
manager.
Also, if you added kernel* to dnf.conf skip list, you can remove it from
the
cache. DNF pretends everything in the skip list does not exist. The 5
raw 6.8.7 or
6.8.5 rpms are well upwards of 100MB. When time comes that upgrade has
otherwise
completed, kernel* must be removed from the skip list to allow dnf to
upgrade to
the current kernel.
Thank you for this, and for earlier posts that I found elsewhere. The system is now updated to f40 and seems to be running well. I didn't have to use rpm installs from the cache in /var/lib/dnf/system-update.
I think the effective change was to add
"exclude kernel* linux-firmware* java* libreoffice* "
to /etc/dnf/dnf.conf, before repeating everything from the preliminary
"sudo dnf upgrade--refresh" and applying "--allowerasing --skip-broken" in the download.
I suppose a "sudo dnf clean all" had helped too: 88 files removed. After the download KDiskFree reported 3.9 GB free in /, and dnf said that was the total package size. "df / " said 4093160 blocks. After the reboot I removed the excludes, ran dnf upgrade again, and installed locally built MythTV rpms.
That's an account of what I did. I'm afraid it comes with no guarantees.
For completeness, there are several post-upgrade tasks you could perform to ensure the system is tidy. See < https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/#se...
.
Jeff
On 5/2/24 11:46 AM, John Pilkington wrote:
I suppose a "sudo dnf clean all" had helped too: 88 files removed. After the download KDiskFree reported 3.9 GB free in /, and dnf said that was the total package size. "df / " said 4093160 blocks. After the reboot I removed the excludes, ran dnf upgrade again, and installed locally built MythTV rpms.
sounds like /var is par of the root file system. To test, "cd /var ; df -k ." to see if it is. If so, usually /var/cache, /var/tmp and /var/log is a good place to find a lot of unneeded stuff to clean out. To find the biggest offenders, cd to one of those directories (/var/cache for example) and then use the command "sudo du -sh *" to get a listing of each file/directory in the current directory and their sizes. You'd have to investigate further to see what can be safely removed.
Charlie
Charles Dennett composed on 2024-05-02 13:08 (UTC-0400):
...To find the biggest offenders, cd to one of those directories (/var/cache for example) and then use the command "sudo du -sh *" to get a listing of each file/directory in the current directory and their sizes. You'd have to investigate further to see what can be safely removed.
Or simply
ncdu
On 5/2/24 1:28 PM, Felix Miata wrote:
Charles Dennett composed on 2024-05-02 13:08 (UTC-0400):
...To find the biggest offenders, cd to one of those directories (/var/cache for example) and then use the command "sudo du -sh *" to get a listing of each file/directory in the current directory and their sizes. You'd have to investigate further to see what can be safely removed.
Or simply
ncdu
Ah. Thanks for that. After all these years I was unaware of that. I've added the package to my system and will add it to my bag of tricks.
Charlie
On 2024-05-02 13:56, Charles Dennett wrote:
On 5/2/24 1:28 PM, Felix Miata wrote:
Charles Dennett composed on 2024-05-02 13:08 (UTC-0400):
...To find the biggest offenders, cd to one of those directories (/var/cache for example) and then use the command "sudo du -sh *" to get a listing of each file/directory in the current directory and their sizes. You'd have to investigate further to see what can be safely removed.
Or simply
ncdu
Ah. Thanks for that. After all these years I was unaware of that. I've added the package to my system and will add it to my bag of tricks.
Me 2 :-)
Cheers Frank
-
Charles Dennett -
Felix Miata -
Frank Bures -
Gordon Messmer -
Jeffrey Walton -
John Pilkington