1

The layout of my current disk is:

enter image description here

I am following the advice from https://unix.stackexchange.com/a/501410/674 to rearrange the partitions on the disk. Are the following steps ok?

  • shrink sda3 (/) to 60G, and leave a 204G unallocated region at the end of the disk (I have done this)
  • move sda4 (/home) to the front of the 93G unallocated space (this step is in progress)
  • move sda3 (/) to the end of the disk, i.e. behind the 204G newly unallocated region, so that the two unallocated regions (93G and 204G) are merged into one 297G unallocated region.
  • extend sda4 (/home) to include the 297G unallocated region

I am now performing the second step in gparted from a live Lubuntu, and gparted warned me that if the partition to be moved contains /boot or is Windows system partition C:, moving the partition most likely fails to boot. I have a bios grub partition, a root partition and a home partition. /boot is in partition sda3 (/). Will I be able to move sda3 (/) to the end of the disk in step 3, without failing to boot? It seems that I will need to reinstall grub according to https://askubuntu.com/questions/299886/partitions-is-it-safe-to-move-partition-containing-boot and https://howtoubuntu.org/how-to-repair-restore-reinstall-grub-2-with-a-ubuntu-live-cd

Update: after following the above steps, the layout of the disk is

enter image description here

I don't need to do anything with grub, and can reboot into Lubuntu on the disk successfully. Why do I not need to do anything with grub, after moving partition sda3 (/) containing /boot? Can it be because the region originally occupied by sda3 (/) is currently unused in sda4 (/home)? How can I verify my Lubuntu was booted from the relocated sda3 (/) not from its original region now free space in sda4 (/home)?

$ cat /boot/grub/grub.cfg |grep boot
   set boot_once=true
  set boot_once=true
  if [ -z "${boot_once}" ]; then
  if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then save_env recordfail; fi; fi
        linux   /boot/vmlinuz-4.15.0-45-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro  quiet splash $vt_handoff
    initrd  /boot/initrd.img-4.15.0-45-generic
            linux   /boot/vmlinuz-4.15.0-45-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro  quiet splash $vt_handoff
        initrd  /boot/initrd.img-4.15.0-45-generic
            linux   /boot/vmlinuz-4.15.0-45-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro recovery nomodeset 
        initrd  /boot/initrd.img-4.15.0-45-generic
            linux   /boot/vmlinuz-4.15.0-44-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro  quiet splash $vt_handoff
        initrd  /boot/initrd.img-4.15.0-44-generic
            linux   /boot/vmlinuz-4.15.0-44-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro recovery nomodeset 
        initrd  /boot/initrd.img-4.15.0-44-generic
            linux   /boot/vmlinuz-4.15.0-43-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro  quiet splash $vt_handoff
        initrd  /boot/initrd.img-4.15.0-43-generic
            linux   /boot/vmlinuz-4.15.0-43-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro recovery nomodeset 
        initrd  /boot/initrd.img-4.15.0-43-generic
            linux   /boot/vmlinuz-4.15.0-42-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro  quiet splash $vt_handoff
        initrd  /boot/initrd.img-4.15.0-42-generic
            linux   /boot/vmlinuz-4.15.0-42-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro recovery nomodeset 
        initrd  /boot/initrd.img-4.15.0-42-generic
            linux   /boot/vmlinuz-4.15.0-39-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro  quiet splash $vt_handoff
        initrd  /boot/initrd.img-4.15.0-39-generic
            linux   /boot/vmlinuz-4.15.0-39-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro recovery nomodeset 
        initrd  /boot/initrd.img-4.15.0-39-generic
            linux   /boot/vmlinuz-4.15.0-38-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro  quiet splash $vt_handoff
        initrd  /boot/initrd.img-4.15.0-38-generic
            linux   /boot/vmlinuz-4.15.0-38-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro recovery nomodeset 
        initrd  /boot/initrd.img-4.15.0-38-generic
            linux   /boot/vmlinuz-4.15.0-36-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro  quiet splash $vt_handoff
        initrd  /boot/initrd.img-4.15.0-36-generic
            linux   /boot/vmlinuz-4.15.0-36-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro recovery nomodeset 
        initrd  /boot/initrd.img-4.15.0-36-generic
            linux   /boot/vmlinuz-4.15.0-33-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro  quiet splash $vt_handoff
        initrd  /boot/initrd.img-4.15.0-33-generic
            linux   /boot/vmlinuz-4.15.0-33-generic root=UUID=d0fed0a4-c82a-414e-8fb2-aa10070bf938 ro recovery nomodeset 
        initrd  /boot/initrd.img-4.15.0-33-generic
    knetbsd /boot/memtest86+.elf
    linux16 /boot/memtest86+.bin console=ttyS0,115200n8

Thanks.

2
  • Perhaps look in to how the bios_grub flagged partition is involved in the boot process and how gparted treats this situation. To make your system fail to boot, if it is somehow (unlikely) using a supposed to be blank area to boot from, would be to zero (or TRIM/discard for SSD) the data in that area of the disk. To zero practically all free space on a disk you can use the dd tool with something like dd if=/dev/zero of=~/zero.tmp bs=1M; sync; rm ~/zero.tmp Mar 10, 2019 at 2:25
  • Note: don't run that dd command on an SSD, it will shorten the life of your disk. If using an SSD see the fstrim command man7.org/linux/man-pages/man8/fstrim.8.html Mar 10, 2019 at 2:30

2 Answers 2

1

Shrink sda3 (/) to 60G, and leave 204G unallocated space at the end of the disk: you have completed this step.

Move sda4 (/home) to the front of 93G unallocated space: this step is in progress. Make sure to back up important data before performing this step.

Move sda3 (/) to the end of the disk, i.e. after 204G of new unallocated space, so that the two unallocated areas (93G and 204G) are merged into one 297G unallocated area: before this step, make sure that the sda4 was successfully moved in step 2 without any issues. For this step, since your /boot directory is in sda3 (/), you may need to reinstall the GRUB bootloader to ensure the system will boot. Please ensure you read and understand the links and instructions provided before performing this step.

Extend sda4 (/home) to include 297G of unallocated space: After completing the first three steps, you should be able to add the unallocated space to sda4 using gparted or other disk utilities.

Regarding your question about GRUB booting, normally when you move the partition containing the /boot directory, you need to update the GRUB boot loader to reflect the new location of the partition. However, if your new location is not in use, GRUB may automatically detect the partition change and adapt at boot time. This is probably one of the reasons you don't need to reinstall GRUB after moving sda3 (/).

To verify that your Lubuntu is booting from the relocated sda3 (/), you can check with:

Open a terminal and execute the following command:

lsblk -f

This will display details of your disks and partitions. Check to see if the filesystem UUID of /dev/sda3 matches the UUID in the /boot/grub/grub.cfg file. If it matches, it means Lubuntu is booting from the relocated sda3 (/).

Optional: You can also check the modification date and time of the /boot/grub/grub.cfg file to see if changes have been made since you performed the partition move. If the modification date and time of the file matches the time since you moved the partition, that's also a sign that Lubuntu has booted from the new location.

1

You don't need to reinstall GRUB because its core image is located in /dev/sda1, which is unchanged. The core image normally has the necessary drivers for the partition table and the filesystem type used to contain /boot/grub, so disk block locations don't matter after that point, since GRUB will be able to recognize partitions and filesystems.

The GRUB configuration seems to use filesystem UUIDs to specify the Linux root partition. Since moving your root filesystem on disk did not change its UUID, the kernel can still find its root filesystem just fine.

The GRUB core image has an embedded path prefix that is used to find the GRUB configuration file. In your case, it's probably something like (,gpt3)/boot/grub. (Leaving the disk part unspecified means "the same disk the GRUB core image was loaded from".) Your /boot directory appears to be contained in your Linux root partition, which was specified by the 3rd partition slot before your changes, and is still the 3rd partition slot after the changes, so the path prefix is still going to be valid.

If your partitioning tool had rearranged the partition slots to match the physical ordering of the partitions on disk, then GRUB would have failed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .