There’s a dual-boot setting configured on my laptop. On the day it was bought, I reserved half of the disk space and installed Ubuntu on it alongside with the Windows shipped by the OEM, since Linux is my most accustomed OS. In two years the Windows was barely launched for less than five times, and the disk space it occupied was more like kind of waste. Therefore, some days ago I made the decision to shrink the footprint of Windows and enlarge the size of Ubuntu’s root partition.

I have the experience to enlarge and move a data partition before, but never for a root partition. It was told that the whole system might become unbootable if EFI information is not updated accordingly. As precaution I did some research and found a solution on AskUbuntu. I followed the guidance and started the gearing.

To accomplish the tweaking, a GParted system is required on a bootable USB device. With the GUI application of GParted I shrink the size of Windows partition, which reclaims 150GB additional disk space. The Ubuntu root partition is then moved and enlarged to fully consume that 150GB space.

The next step is to update the information in EFI partition to ensure it contains the new serial number of my root partition. Follwing the guidance, I need to first mount relevant partitions to form the root directory of my Ubuntu system and use chroot to start a shell in it

(gparted)$ mkdir /tmp/mydir
(gparted)$ mount /dev/nvme0n1p5 /tmp/mydir
(gparted)$ mount --bind /dev /tmp/mydir/dev
(gparted)$ mount --bind /proc /tmp/mydir/proc
(gparted)$ mount --bind /sys /tmp/mydir/sys
(gparted)$ chroot /tmp/mydir
chroot: failed to run command ‘/bin/bash’: No such file or directory

The chroot however complains that /bin/bash could not be found. I check the corresponding directory /tmp/mydir/bin and realize it is a dead symbolic link

(gparted)$ ls /tmp/mydir/bin -al
lrwxrwxrwx 1 root root 7 May 28 2020 /tmp/mydir/bin -> usr/bin

It appears that /bin is a symlink to usr/bin but my /usr directory resides on the other partition, which is not mounted. By mounting /usr, the chroot command works successfully.

(gparted)$ mount /dev/sda7 /tmp/mydir/usr
(gparted)$ chroot /tmp/mydir

Now we can run grub-install to inform grub that we have a new serial number for the root partition.

(ubuntu)$ grub-install /dev/nvme0n1
Installing for x86_64-efi platform.
grub-install: error: cannot find EFI directory.

Unfortunately there’s another problem. After some time of inspection, I find the culprit to be that the directory /boot/efi is empty, which falls in partition /dev/nvme0n1p1 and is not mounted. The solution appears to be another mount command

(ubuntu)$ mount /dev/nvme0n1p1 /boot/efi
(ubuntu)$ grub-install /dev/nvme0n1
Installing for x86_64-efi platform.
Installation finished. No error reported.

The EFI information is finally updated. I reboot my laptop and everything works as-is.

So the lesson for this tweaking is that some special directories like /usr or /boot/efi does not reside within the same partition as the root directory / on my laptop. If you are fixing the grub and come across some similar errors, make sure that all concerning partitions are correctly mounted.