I do not have enough root memory to install version 38. I would prefer not to reinstall from scratch. I have read about multiple methods of increasing root memory. What does fedora project recommend?
I am not certain exactly what you are asking here. do not have enough root memory can infer inadequate RAM or it could possibly be inferred to mean inadequate disk space. Which is it?
If one were to post the output of the command df as preformatted text using the </> button on the toolbar it may give us some idea. The output of sudo fdisk -l would assist as well.
Once we know the details we can make informed suggestions.
When I try to use dnf to upgrade any package, I get the message of 0 bytes available. I to upgrade to version 38 using the option to store the downloaded files, I get the same messages. I have tried to move temporarily create space by moves some folders from /opt and /usr/local (applications not currently being used) to /home/ā¦ but that did not help. I deleted the cache for dnf and that did not help. The following is the result of df command.
[dgayler@localhost ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 4096 0 4096 0% /dev
tmpfs 7995432 147820 7847612 2% /dev/shm
tmpfs 3198176 2192 3195984 1% /run
/dev/mapper/fedora_localhostālive-root 71670904 70595312 0 100% /
tmpfs 7995436 47388 7948048 1% /tmp
/dev/loop0 128 128 0 100% /var/lib/snapd/snap/bare/5
/dev/loop1 249728 249728 0 100% /var/lib/snapd/snap/code/119
/dev/loop2 107136 107136 0 100% /var/lib/snapd/snap/brackets/138
/dev/loop3 298880 298880 0 100% /var/lib/snapd/snap/code/124
/dev/loop6 56960 56960 0 100% /var/lib/snapd/snap/core18/2697
/dev/loop5 119680 119680 0 100% /var/lib/snapd/snap/core/14946
/dev/loop4 119680 119680 0 100% /var/lib/snapd/snap/core/14784
/dev/loop8 64896 64896 0 100% /var/lib/snapd/snap/core20/1852
/dev/loop7 56960 56960 0 100% /var/lib/snapd/snap/core18/2721
/dev/loop9 83328 83328 0 100% /var/lib/snapd/snap/gtk-common-themes/1534
/dev/loop10 93952 93952 0 100% /var/lib/snapd/snap/gtk-common-themes/1535
/dev/loop12 296832 296832 0 100% /var/lib/snapd/snap/kde-frameworks-5-core18/35
/dev/loop11 267008 267008 0 100% /var/lib/snapd/snap/kde-frameworks-5-core18/32
/dev/loop13 128 128 0 100% /var/lib/snapd/snap/openboard/14
/dev/loop14 36736 36736 0 100% /var/lib/snapd/snap/swi-prolog/55
/dev/loop15 37120 37120 0 100% /var/lib/snapd/snap/swi-prolog/71
/dev/nvme0n1p2 996780 276296 651672 30% /boot
/dev/mapper/fedora_localhostālive-home 901928012 265876028 590162860 32% /home
/dev/nvme0n1p1 204580 73520 131060 36% /boot/efi
tmpfs 1599084 180 1598904 1% /run/user/1000
[dgayler@localhost ~]$
You seem to be running snap and the root file system is 100% full, possibly at least partly as a result of the large number of snap files you are keeping. You also seem to only have about 70 GB for the root file system. A temporary fix may be to disable snap and delete all those snap files, but a more permanent fix would be to have more space available for the root file system. Migrating everything to another larger hard drive (SSD or HDD) could be the answer (or just add a second drive to allow expanding space)
The output of sudo fdisk -l may provide more options.
Which brings me back to the question I was originally trying to ask. I would like to move some of the disk space from home to root to increase from 70GB. 70GB was the default size when I originally installed. Are there SAFE techniques to move disk space from home to root?
Yes, there are safe ways to do that, but we need the info from fdisk as requested twice (now 3 times) to be able to make those suggestions.
It would appear the system was installed with LVM so the size of the LV may be adjusted, but only if we know how it is at present can suggestions be made.
Please provide the output of sudo vgscan and sudo lvscan as well.
[dgayler@localhost ~]$ sudo fdisk -l
[sudo] password for dgayler:
Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: KXG60ZNV1T02 NVMe TOSHIBA 1024GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B7477F0C-7EBC-4AD2-818B-EE76AE220C0E
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 411647 409600 200M EFI System
/dev/nvme0n1p2 411648 2508799 2097152 1G Linux filesystem
/dev/nvme0n1p3 2508800 2000408575 1997899776 952.7G Linux LVM
Disk /dev/mapper/fedora_localhost--live-root: 70 GiB, 75161927680 bytes, 146800640 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/fedora_localhost--live-swap: 7.72 GiB, 8287944704 bytes, 16187392 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/zram0: 8 GiB, 8589934592 bytes, 2097152 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/mapper/fedora_localhost--live-home: 874.95 GiB, 939473764352 bytes, 1834909696 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop0: 4 KiB, 4096 bytes, 8 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop1: 104.55 MiB, 109625344 bytes, 214112 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop2: 243.79 MiB, 255635456 bytes, 499288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop3: 291.84 MiB, 306020352 bytes, 597696 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop4: 116.79 MiB, 122458112 bytes, 239176 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop5: 116.76 MiB, 122433536 bytes, 239128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop6: 55.61 MiB, 58310656 bytes, 113888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop7: 55.61 MiB, 58314752 bytes, 113896 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop8: 63.32 MiB, 66392064 bytes, 129672 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop9: 81.26 MiB, 85209088 bytes, 166424 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop10: 91.69 MiB, 96141312 bytes, 187776 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop11: 260.71 MiB, 273375232 bytes, 533936 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop12: 289.78 MiB, 303853568 bytes, 593464 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop13: 8 KiB, 8192 bytes, 16 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop14: 35.84 MiB, 37584896 bytes, 73408 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop15: 36.24 MiB, 38002688 bytes, 74224 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
[dgayler@localhost ~]$
[dgayler@localhost ~]$ sudo vgscan
Found volume group "fedora_localhost-live" using metadata type lvm2
[dgayler@localhost ~]$ sudo lvscan
ACTIVE '/dev/fedora_localhost-live/swap' [<7.72 GiB] inherit
ACTIVE '/dev/fedora_localhost-live/home' [874.95 GiB] inherit
ACTIVE '/dev/fedora_localhost-live/root' [70.00 GiB] inherit
I took the liberty of editing your post and adding the preformatted text tags as previously suggested so the post is easier to read.
Thank you for that info.
Since it is confirmed that you are using LVM for the file systems now it is quite possible to make suggestions on how to proceed.
-
With fedora it is not normally required that one have a physical swap partition. Fedora uses zram for virtual swap and your system shows 8 GB of zram swap so I would suggest that you eliminate the swap partition (LV) to free up that 8 GB of drive space. It also is not normally recommended that a physical swap be used on any SSD because of the potential large amount of writes in that space which could shorten the life of the SSD.
-
Your df output shows only 32% of the space allocated for /home as used so it would be easy to shrink that LV then add the newly freed up space to the root LV.
My suggestions, (with commands) are:
-
first remove the swap partition from /etc/fstab so it does not cause failure with the next system boot. Edit /etc/fstab using
sudo nano /etc/fstaband locate the line that contains the swap file. Put a#sign at the beginning of that line and save it. -
now boot into the live media so the /home LV is not in use.
-
open a terminal in the live media screen then use
suto gain root privileges. -
Now one may use the LV commands to alter the logical volumes. I recommend that with each command you use the
-toption to test what is being done, then if satisfied with the output repeat it without the-tto actually perform the action.
a.sudo lvremove -t /dev/fedora_localhost-live/swap
then
sudo lvremove /dev/fedora_localhost-live/swapto actually remove it.
b.sudo lvreduce -r -L 800g -t /dev/fedora_localhost-live/homewhich will reduce the existing /home partition to a new smaller size of 800 GB and free up space to use in the root LV. (repeat without the -t option)
c. Now to expand the root LV.
sudo vgdisplayto actually see the details of the VG. It should now show some number of free extents near the bottom asFree PE. You can expand the root LV to fill that space withsudo lvextend -t -r -l NNNN /dev/fedora_localhost-live/rootwhere you replace the NNNN with the actual number of extents you wish to use from the number seen as free when you ran the vgdisplay command. (repeat without the -t option)
Once this is all completed one should be able to reboot back into the installed OS and there should be nearly 100GB of free space in the root file system.
If there are any errors reported in the above do not continue but solve the error before going on.
1 Like
You can run snap list --all |grep disabled to see which snap packages are disabled and no longer needed. Then snap remove --revision R N tot remove it where N is the name of the snap package and R is the revision number.
In addidion, the directories /var/tmp, /var/spool, /var/cache and /var/log can accumulate a lot of space-waiting files, which you might want to get rid of.
If you run sudo du -ah /var/{tmp,cache,log,spool} | sort -h you cat a list of these files sorted by size from low to high.
1 Like
Thank you for all your help!!
Does that mean everything is now fixed? or just pending?
If fixed then please mark the post with the solution so others may find it.
just pending - high priority item must be finished first
I finally finished my āprojectā and just tried following these instructions. When I tried sudo lvreduce -r -L 800 GB -t /dev/fedora_localhost-live/home, i received that the message that this command could not be executed with the given argument.
I think that should be
sudo lvreduce -r -L 800g -t fedora_localhost-live/home. It seems I erred in the way I structured that, and have corrected the typo.
Note that the file system must not be mounted when doing the reduce, it will warn you about that as well.
$ sudo lvreduce -r -t -L 5.9t /dev/fedora_raid1/home
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Rounding size to boundary between physical extents: 5.90 TiB.
Do you want to unmount "/home" ? [Y|n] y
Size of logical volume fedora_raid1/home changed from 6.00 TiB (1572864 extents) to 5.90 TiB (1546650 extents).
Logical volume fedora_raid1/home successfully resized.
When I tried the units as you did it also erred. Lower case or upper case G|g with no space between the number and the units.
I hate to show my ignorance here but I followed the directions and I seem to have ālostā some disk space.
[dgayler@localhost ~]$ sudo lvscan
ACTIVE ā/dev/fedora_localhost-live/swapā [<7.72 GiB] inherit
ACTIVE ā/dev/fedora_localhost-live/homeā [800.00 GiB] inherit
ACTIVE ā/dev/fedora_localhost-live/rootā [74.95 GiB] inherit
I used the number of extents listed as FREE PE (19188). Was there another entry which would give me the "additional extents?
Sorry for being a pest.
The command vgdisplay shows the details of the volume group. If it displays a count on the line Free PE then there is space available for use.
When using the command lvextend it is possible to tell the system to use all available space with a structure like
sudo lvextend -t -r -l+100%free /dev/fedora_localhost-live/root
This tells it to use all available extents without the user needing to be exact in the count. Of course one would need to remove the -t option to actually make the change.
Using the man pages for each command is informative, as is a bit of research online searching for LVM management information.
When all done the command df should reveal free space in the file system that was previously at 100%.
Thanks. I am assuming that this needs to be done when booting using the ālive versionā - usb in my case. I will try it in the morning.
No, extending a running LV file system is very much supported. Shrinking one when active is not supported.
[dgayler@localhost Desktop]$ sudo lvextend -r -l100%free /dev/fedora_localhost-live/root
New size given (17920 extents) not larger than existing size (19188 extents)
[dgayler@localhost Desktop]$ sudo vgdisplay
ā Volume group ā
VG Name fedora_localhost-live
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 6
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 952.67 GiB
PE Size 4.00 MiB
Total PE 243884
Alloc PE / Size 225964 / 882.67 GiB
Free PE / Size 17920 / 70.00 GiB
VG UUID 1pV8Dy-OGqX-uMOH-NhoZ-DpeY-Or1a-AUYToy
I added + and it works. Sorry to bother you.