A few days ago, I decided to shrink the footprint of the Windows system on my laptop and reallocate the freed-up disk space to Ubuntu, which I use alongside it. Since I primarily rely on Ubuntu for programming and web browsing, I’ve rarely booted into the OEM-shipped Windows since purchasing the laptop. Windows occupies a significant portion of my SSD, and reclaiming that space allows for better use rather than letting it sit idle.

#gk:immersive
(before)
| --- Windows C: (256 GB) --- | --- Ubuntu / (256 GB) --- |
(after)
| --- Windows C: (120 GB) --- | --- Ubuntu / (392 GB) --- |

As planned in the diagram above, 136 GB space would be reclaimed from the Windows C: partition and merged into Ubuntu’s root partition. While I’ve had experience resizing disk partitions before, this operation was a bit more risky–it required shifting the starting point of the Linux root partition. Since Linux depends on specific boot information stored in the /boot/efi directory, failing to update this information properly during the move could render the entire system unbootable.

To avoid any catastrophic consequences, I did some research in advance and followed a detailed guide I found on AskUbuntu. It turns out the tweak involves two key steps. The first is resizing the partitions using GParted, just like I’ve done before with standard data partitions. Since GParted needs full access to the disk, it must be run from a separate USB device, allowing all internal partitions to be unmounted during the operation. Fortunately, this step is quite straightforward thanks to GParted’s intuitive GUI, which lets me make the necessary adjustments with just a few clicks.

Each disk partition is assigned a unique identifier called UUID – something like b424102c-a5a6-489f-b0bd-0ea0fc3be7c3. This UUID can change when a partition is moved or resized, which means the system’s bootloader configuration must be updated accordingly. The next step, then, is to rebuild the GRUB configuration to reflect the new UUID of the root partition. Before running grub-install, however, I needed to recreate the Ubuntu system’s directory hierarchy by mounting the necessary partitions and then using chroot to launch an interactive shell within that environment.

(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

However, when I followed the guide, the chroot command failed with an error stating that /bin/bash could not be found. Upon inspecting the corresponding directory at /tmp/mydir/bin, I discovered that it was a broken 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 and not yet mounted. With the directory /usr mounted, the chroot command works as desired.

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

The spawned interactive shell allows command to run as it were in my Ubuntu system. Type grub-install /dev/nvme0n1 to write in the new serial number of root partition. It’s worth noting that the argument /dev/nvme0n1 passed to grub-install is the name of the hard disk device to write instead of some partition name like /dev/nvme0n1p1.

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

Oops, the command failed and something still going wrong. After some time of inspection, I find the culprit to be that the directory /boot/efi is empty, which by default should be a bind mount to partition /dev/nvme0n1p1 but not mounted properly. This can be solved with 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.

By now the boot information is eventually updated. I reboot my laptop and everything works as-is.

The key takeaway from this tweaking process is that certain special directories – like /usr or /boot/efi – reside on separate partitions outside the root / on my laptop. When repairing GRUB or dealing with similar boot issues, it’s crucial to correctly mount all relevant partitions to reconstruct the full filesystem hierarchy. Failing to do so can lead to errors like broken symbolic links or missing binaries during chroot.

Author: hsfzxjy.
Link: .
License: CC BY-NC-ND 4.0.
All rights reserved by the author.
Commercial use of this post in any form is NOT permitted.
Non-commercial use of this post should be attributed with this block of text.