I was visiting a friend recently, and they asked me to set their computer up to dual-boot Windows 10, which they needed for gaming. The machine had Linux Mint installed, with the system data on a relatively small solid state disk, and the user files on a partition on a much larger hard disk. Due to some experiments with SteamOS, half of the HDD was unused, or otherwise being used for media storage.
The desired result was to have the OS data for both Mint and Win 10 on the SSD, and then use the ex-SteamOS partition on the HDD as a data partition in Windows. As a result, I got to learn how to do partition resizing.
The SSD contained three partitions: the EFI system partition, the Mint root partition and the Mint swap partition. I booted the box into a Mint install disk, and then took a note of the UUID of the swap partition, so I could recreate it later. I then force-fsck(8)'ed the Mint root partition, and then ran resize2fs(8) on it, to reduce the size to around 40 GB or thereabouts. Next, I opened the partition table in fdisk(8), and deleted the swap partition and root partition. I then recreated the root partition using the same starting offset of the original, and set the size to 41 GB -- note the extra gigabyte of size, which was an intentional safety net. The kernel then needs to be told to re-read the partition table, which is achieved with partx(8)'s -a option. Finally, the Mint root filesystem can be expanded to occupy the entirety of the partition, by running resize2fs(8) for a second time.
I recreated the swap partition after the new, shrunken root partition, and then invoked mkswap(8) with the -U option -- I re-used the UUID of the original swap partition here, so the Mint installation would be none the wiser about the filesystem shrinkage.
The Windows 10 installer then got to play with the remaining free space at the end of the disk. This was the first time I've ever done a Windows 10 installation, and (once a working installer was properly obtained, which is a saga in and of itself) it was pleasantly painless. Reformatting the spare ex-SteamOS partition for use by Windows was also straightfoward too.
While the existing Mint installation was on a GPT partition table, it was still booting in BIOS mode (why this is the case is a mystery lost to the winds of time, from when I cleaned up after the SteamOS experiments over a year ago). Windows 10 will refuse to install in BIOS mode onto a disk with a GPT partition table (which is a reasonably sensible decision), so I had to install Windows in UEFI mode. Switching between the Windows installation and the Mint installation then became a case of mashing firmware options at boot, which isn't a terribly great boot selection interface, so I booted back into the Mint installer and chroot(8)'d into the Mint installation. There, I mounted the EFI system partition at /boot/efi, (re)installed grub in UEFI mode, added the mount to fstab(5) and made an EFI boot entry.
Magic bootloader arcana is magic.
Since I fixed up this installation, my friend's home LAN changed configuration, and suddenly The Internet stopped working on the Mint side of things. As it turns out, Mint manages /etc/resolv.conf dynamically, so that file is normally a symbolic link to another file managed by another application (probably NetworkManager). At the time when I switched the boot modes, I was working in a chroot(8) and I had moved the symbolic link and created a static file in its place for the purposes of installing the grub UEFI packages. I then promptly forgot that this hack was in place, which meant that DNS resolution broke for no apparent reason when my friend got a different router. They were very impressed when I managed to get everything working remotely as if by magic (otherwise known as getting them to run sudo rm /etc/resolv.conf; sudo mv /etc/resolv.conf.bak /etc/resolv.conf).