Is it safe to move unallocated space over boot partition in dual boot

Question

I am trying to move unused space from my windows installation (/dev/nvme0n1p3) to my manjaro root partition (/dev/nvme0n1p8) using GParted. GParted image of my system's partitions. To move the unallocated space there it must move past the manjaro boot partition. When trying to do so I get this warning informing me that moving the boot partition might render the system unable to boot. In my research I found information regarding moving past the swap-partition, but not much regarding the boot partition. My question is if this is a somewhat safe or stupid thing to do. Is it perhaps better to instead do a full manjaro re-installation some time in the future and then include the unallocated space instead?

Answer 1

The qualified answers is: It depends. Unallocated does not always mean unused. I do not know of current trends and technologies, but in the past, there have been various 'disk management' extensions by various disk vendors to enable otherwise limited BIOS's and OS's to access additional sizes or vendor-specific features of hardware/disks.

Likewise, some software tools may use such spaces for other purposes; In the days of DOS, I've seen short programs store backup partition tables and critical system data backups in otherwise unallocation storage space--without marking the space as allocated to ensure it's safety and integrity.

If I understand the original question correctly, you simply removed a dual-boot Windows (tm) installed partition, and want to reclaim it for use by the Linux installation. If this is correct, you should not move partitions--just create a new partition, and adjust the information the boot loader you are using so it can still find and boot your installed OS's. Most OS's don't care if they are in the first, third, 26th, or whatever partition entry, as long as they can find the entry which describes what physical (or logical) sectors the partition occupies. From there, they often contain controls which allow you to specify "if, how, when, and where" to load other partition(s) in to the file system information in the OS kernel (core), regardless of their physical location on the disk. You simply need to tell the OS how to identify the partition, and where to "mount" it.

Typically have my hard drives put the boot partition (a small partition to contain the boot loader and it's associated data--(U)EFI already does this by nature (And is not required to be the first partition; it can be anywhere as long as the partition table tells it where on the disk it resides), while BIOS has always used the first drive sector for the MBR. I often follow this with a general or user data partition--NOT an installed OS partition as I often see most people do (See my note, below, on why). Then from the end of the disk, I start installing each bootable partition for each OS, leaving gaps in case I need to "grow" the user/data or the installed OS partitions for changes.

Note why I put the boot and user data first instead of last: The boot partition contains critical boot and disk drive data structures; so if I need to recover from a failure, I know it's always going to be first, so I can find it, and then see where the other partitions/data are from that data. Likewise, most failures I've encountered occur near the end of the disk--User data is the most critical data to me, because it varies the most. The OS files do not change much; I do not usually need to recover "cmd.exe" from a Windows (tm) installation because nearly every Windows installer CD has a copy of the file already that it will use if you have to re-install the OS. But only your user data partition would have your "Current Resume.docx", which if lost, you could likely never recover from an alternate source (excluding backup copies). These are really just backup/restore/disaster recovery, redundancy, and safety strategies that I use to protect myself.

Edit to add: IF you want to EXTEND your Linux root partition to use the now freed earlier partition--Don't do that. At least not that way. If you installed LVM(2) on Linux, simply create an additional pv (physical volume) to add to your volume group(s), which you can then extend your lv (logical volume) to use it. LVM itself doesn't care about the physical placement of the pv's on the drive, it already has logic built-in to handle "out of order" partitions/volumes. If you are not using LVM, you can still create another partition normally, then edit your mount points to mount the new partition where you want it in the Linux filesystem. (Some paths are sacred to Linux, such as "/etc", which does not fare well if not part of the root volume. For others, you can mount "/home" separately, and if find you have need, create and mount a "/home2" on another partition for adding new users, and/or moving specific users between home paths as needed and appropriate for your system.)