I’m running Fedora 36 with a root partition, a Swap partition and a Boot partition.
I ended up needing more space on my root partition for a couple of reasons and so I wish to delete my swap partition, move my boot partition to the end of the free space created by the deletion, and add the free space to my root partition.
What I don’t want is that I render my system unbootable by the changes. The first question is thus would moving the boot partition without changing its size change its UUID? I’m asking this because, if I remember well, the boot process refers to the boot partition with its UUID.
The second question would be: would running without a swap partition cause problems? I believe that these days Linux can use a temporary swap file instead. I have * Gb of physical RAM and I rarely use it all.
Not sure about the first question - moving may not change the UUID, but resizing may.
The problems you may encounter running without swap are 1) possibly reduced performance and 2) system crash if you run out of working memory.
It may negatively affect performance: at any time, the system can make more memory available for your running processes if it is in the possibility to swap memory used by sleeping processes to disk.
If you run out of memory, the kernel will invoke the OOM killer and start killing processes in order to solve critical memory needs. With swap, the chance of running out of memory is strongly reduced.
Fedora (at least 37) does, for me, not have a swap partition neither a swap file. Instead, it sets up swap space in compressed memory. Probably, it only uses this setup on systems with adequate RAM. I have 16 GB. With only 8 GB or less, I definitely would maintain swap space on disk.
Note that this does not relate to the title of your question “Moving boot partition”. For the benefit of other users, it is better to ask different questions in a dedicated thread.
You probably are going to have boot off some type of live ISO to do that. Check the UUIDs before and after making the partition changes. If they change, make the changes needed before rebooting back into the system.
The UUIDs are in two places. Inside /etc/fstab and in your grub config. The grub config only needs to be changed before booting if the root UUID changes, otherwise you can update it after booting into the system.
You will need to update /etc/fstab even if the UUIDs don’t change if you remove the physical swap partition.
There are several ways to update the grub config when on a live ISO. I would probably do one of these two:
Mount your filesystems, create a chroot of your running system and then modify the grub settings as normal.
Mount /boot, open up /boot/grub2/grub.cfg search and replace the old UUID with the new UUID for the root partition and then make the grub changes after booting into the system.
Either way, make sure you backup any data you care about before making partition changes. Changes of that nature will sometimes result in failure and that can be unrecoverable.
As for removing the swap partition, yes, you can do that. You will lose the ability to hibernate(suspend to disk) the system if that matters to you. Switching to a swap file is also possible but it probably won’t help much as it will also consume space.
As I recall, when a partition is created it gets its own UUID. When a file system is formatted it gets its own UUID.
IME resizing or adjusting the position of an existing partition does not change the UUID.
An educated answer would be easiest if we knew the existing partition layout and then exactly what you wanted or needed to do.
A screenshot of gparted for the disk of interest would show the layout and make it easier to describe exactly what your intent is, then we could make suggestions.
Below you see the layout of my OS drive.
I could move or enlarge that root partition into the free space, and even just relocate it sideways using gparted. It would require that the partition not be mounted, but booting from a live media then using gparted would suffice for that.
Note there are some differences when working with BTRFS file systems, so be sure what you are doing before you leap in.
Yes, this is why I asked for the graphic gparted image and a description of what the OP wants. It is easy to break booting with partition changes.
Best to relocate and not create new with new UUIDs.
Another sneaky place that grub hides a UUID is in the stage 1.5 bootloader. It happens when grub2-install is run (which in turn calls grub2-mkimage). In older versions, grub2-mkimage named the generated stage 1.5 bootloader core.img and saved it under /boot/grub before writing it out to the sectors between the MBR and the first partition. Below is an example of the early config script that grub2 hides in the first sectors of the disk that I found online.
Sorry, if he said his system was UEFI, then I missed that.
I know, at least in the distant past, BIOS grub2 did embed that sort of early config script in the stage 1.5 bootloader on Fedora Linux systems. I even manually extracted it from the core.img file and inspected the contents. But that was at least a decade ago. I cannot say for sure how grub2 works these days.
Yes, if you are running out of memory, the system will at best start killing processes to prevent system freezing, or at worst it would freeze. Swap isn’t usually large (mine is 8GB), maybe you can make more free space available by other means? (Cleaning cache, uninstalling unneeded apps, moving data somewhere else…)
Also swap has other benefits related to performance.
The main problem arose because Dropbox decided to block it’s app from working with a folder on an NTFS partition. I used to keep my Dropbox files, ~20Gb on a shared NTFS partition accessible from Windows and Linux in a Dual boot setup. There was, for a time, a workaround with just having a shortcut on an ext4/btfs partition pointing to the real folder on an NTFS partition. This workaround no longer works so I had to transfer the folder to my root/home partition and now it is almost full. Another approach would be to reduce the Windows partition by @0Gb and increase the root one. However I have never resized a partition from the head end.
You can resize the btrfs from the head end, but you need to boot the liveUSB system. Doing this using the command line is a bit tricky as you need to change the size of the partition as well as the size of the btrfs file system. Using gparted will do the right thing and and it will take care of both.
As usually, it is recommended to have an up-to-date backup of your data. You probably won’t need it, but if you do need it can be a saver to have it.
Benefits or negatives depending. The default zram swap is usually the fastest and adding a disk swap might slow things down a bit. Just depends.
Looking at that gparted output your goal seems simple without corrupting or changing any UUIDs.
delete /dev/nvme0n1p8 swap partition
relocate /dev/nvme0n1p7 /boot to the end of the now free space, keeping the same size.
expand /dev/nvme0n1p6 to fill the now free space trailing the existing partition.
Someone else will need to jump in with how that works to expand a btrfs filesystem with a larger partition.
These three steps should relocate /boot without changing its UUID, and allow expanding the btrfs volume, also without changing the UUID, so should have no effect on booting after completion.
You will only gain about 5.5 GiB space for the btrfs volume so not a big change.
I don’t know if that is true or not, but just to be sure, I’d recommend double-checking that the UUID didn’t change by running the following command before and after you move the partition. (The number at the end of the device path might change after the partition is moved, but that shouldn’t matter, just adjust the below command accordingly.)
$ sudo tune2fs -l /dev/nvme0n1p9
If the UUID does change, you should be able to set it back to its previous value with the following command. (Again, update the number at the end of the device path if necessary.)
It should similarly be possible to verify and reset the UUID of the Brtfs filesystem if you chose to move that instead. But I don’t know the commands for that.
I have expanded, shrunk, and relocated existing partitions several times without causing a change to the UUID. Hopefully it will work the same for the OP
A new partition will of necessity get a new UUID and your commands are definitely appropriate to verify if there were a change and to repair if needed.
It is sometimes a bad idea not to ask about your main problem, i.e., problem X, rather than about problem Y, which is what you think will solve problem X.
What could have worked is to mount --bind e dropbox directory on your ntfs partition to the dropbox directory on your linux system instead of using a sumlink. A mount --bind mounts any directory in the file system to another directory in the file system, in a way deeper in the system such that it is transparant to dropbox. I cannot test, but I would be surprised if that does not work with ntfs.
What you said is true. Maybe it is good to ask in a separate question on how to mount bind a folder on a partition to another in folder in another. I have used mount --bind before, but not in an automatic fstab mount. Furthermore, the NTFS partition is bitlocker encrypted and it is being mounted automatically in fstab.
