I need to update my Fedora installation. The root partition has about 10% of 50GB space left. I have a dual boot installation, Win 10 (it’s only there because it came with the computer and it’s legal) is taking up half of my disk space, but I don’t even use it…
I would need tips and trick on how to remove the Windows partition and merge that space with the root partition… I read about it, but i’d really appreciate some step-by-step instructions, I’d really like to keep my existing Fedora installation(and update to the latest version) and not start from scrap.
I can post screenshots and any information if needed…
Several bits of information are needed before proceeding.
Please post them all as preformatted text using copy & paste with the </> button as much as feasible. lsblk -f df -h inxi -Fzxx
Once we can see the details then suggestions on how to proceed may be forthcoming.
I am assuming you want to upgrade your fedora system to the latest version as well as removing the windows installation. If that assumption is correct then the guidance below should assist in doing so.
First you should disable snapd and remove the 23 snap images to free up existing space.
I see that your root file system is at 98% so freeing up space should be your first step.
You also seem to have an excessive amount of space used in /boot/efi with 296M used there. My system only uses
$ df -h /boot/efi
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p1 335M 20M 316M 6% /boot/efi
Disable snapd with sudo systemctl disable snapd (note that I am not familiar with snap so I am guessing at the service name to disable that.) if it is not snapd.service then you will have to identify the proper service name to disable it.
remove all the snap images with sudo rm -r /var/lib/snapd/*
After snap has been managed then do a full and complete update of the system before proceeding. sudo dnf upgrade --refresh
Now it is time to deal with windows.
remove the windows efi data with sudo rm -r /boot/efi/Microsoft
which should remove that directory and all its content so the microsoft boot loader is no longer seen by grub.
Use gparted and remove the windows partitions. Those partitions to be removed are nvme0n1p2, p3, p4, & p5. Do not remove p1, p6, or p7 since all those are your fedora installation.
Create a new partition in the space that previously was allocated to windows. Do not format it as a file system. Then exit from gparted.
Using LVM create a new PV using the newly defined partition, then add it to the existing VG (fedora_office001). At this point you now should have free space within the VG that can be used as needed.
All the above is preparation for the upgrade of the fedora 38 system to fedora 41.
To perform the upgrade to fedora 41 (you may stop 40 if you prefer – it has only about 3 months of support remaining before it is declared EOL) do the following.
sudo dnf system-upgrade download --releasever=40 to download all the necessary rpms for the upgrade.
After step 1 completes successfully then do the actual upgrade with sudo dnf system-upgrade reboot
reboot again after the upgrade completes and test that it is as expected. Ensure f40 is fully upgraded with sudo dnf upgrade --refresh
If there are any problems noted fix them here before moving on.
The last step would be up upgrade to f41 which is done by repeating steps 1-3 just above but use --releasever=41
Just a note of caution.
I have experienced some users who fail to observe an error and blindly continue which can exacerbate any noted problems. All problems should be corrected and the step involved be completed successfully before moving to the next step.
An additional note.
You probably do not need to use a physical swap. Fedora uses zram in RAM for swap and I see you do have /dev/zram0 used in that manner.
Unless you are using a severely loaded system where zram is not adequate, or if you are intending to hibernate the system instead of a full shutdown, then a physical swap space is usually not required. You may consider disabling swap on fedora_office001-swap and removing that LV as well as removing its entry from /etc/fstab.
The command free should show how much swap is actually used and assist in this decision. The inxi command seems to show that no swap was in use at that time.
You may have old snaps installed. Run snap list --all | grep disabled. This will be a list of old snaps you no longer need. To remove an old snap run snap remove --revision "revision" "name" . For example to remove the old skype version run snap remove --revision 380 skype.
The the snaps will be automatically updated, but the old version will remain until you manually remove them.
I did remove the snap images, it seems I have deleted Skype & Whatsapp in the process but that doesn’t really matter.
/boot/efi still uses a lot of space though, any ideas how to free that space, what to do?
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p1 356M 297M 60M 84% /boot/efi
I did the update with sudo dnf upgrade --refresh. (I am aware that it is a necessary step before upgrading?)
Can I proceed to removing the windows efi data with sudo rm -r /boot/efi/Microsoft?
So you shouldn’t do that. However, the snapd service is socket activated so it will just start again when running the snap command.
The only proper way to maintain snap packages is through the snap command, and just removing files related to some snap package could leave behind bits and pieces that could cause problems.
According to your df output above you originally had 49G for / and 40G for /home
The inxi output shows that nvme0n1 is 238GiB.
Assuming that the output of sudo vgscan operates as it does for me you must have scads of free extents in that VG. You can use the lvextend command to enlarge the LVs to whatever size you deem appropriate.
Use the man page for each command you wish to use to learn how they work and the options available. (man lvextend)
to extend the LV for 45% of the free space and the same for
/dev/fedora_office001/root
Correct me if I’m wrong please, I have the full disk image(with the Windows partition) backed up, but I’d really like to spare myself with getting that back and don’t want to waste time restoring that image. As for partitions, it’s a bit of a grey area for me, that’s why I’m asking for help, I’m also extremly grateful for all your contribution.
Assuming that I understand correctly, partitions should be unmounted before making any changes, right? Can I do that in KDE Partition Manager and then run the commands in the terminal or what is the right way of doing that?
Normally I specify the actual size I want for each LV lvextend -L +50G -r fedora_office001/root should expand the LV & the file system it contains by adding 50 GB in a single step. To verify that it would be successful add the -t option to do a dry run and test the command before committing it.
EXAMPLE $ sudo lvextend -L +10G -r -t fedora_root/root
NOTE the -r option which resizes the file system. Without it you have to manually expand the file system after the LV is resized.
You certainly may use the -l +45% if you prefer
With LVM you can enlarge your LVs & file systems while the system is operating. Simply boot to the system, then use the lvextend command to expand the volumes.
I only copy-pasted the relevant output of the inxi command. As you can see, I also upgraded to Fedora 41 too, but it does not upgrade the kernel… Any ideas? (Should I start a separate topic on that, please let me know.)
This would appear to be part of your issue and is still on-topic for this thread.
I would guess that somehow you have managed to alter the default /boot/efi/EFI/fedora/grub.cfg file so it is not acting as a pointer but is actually controlling grub.
This can be determined by using sudo cat /boot/efi/EFI/fedora/grub.cfg.
If it looks something like the below then it would be OK but if it is different and much longer then it is not default.
The function of that pointer file is to redirect grub to the actual grub.cfg file located at /boot/grub2/grub.cfg. If it has been altered then the system never updates it during kernel updates as it remains static once installed and thus newer kernels never get booted.
Any time a user uses the grub2-mkconfig command the output must be directed to /boot/grub2/grub.cfg or to one of the grub cfg links in /etc (/etc/grub2.cfg or /etc/grub2-efi.cfg).
That file under /boot/efi was altered from the actual grub.cfg file to a pointer file several releases back (at least as far back as f34) and does not get altered by system updates since that time.
