Partitions. is it safe to move partition containing /boot?

Question

I am running dualboot (Windows 7 and Ubuntu 12.04) and I would like to make more space for my Ubuntu partition. I am doing it from a live cd through gparted.

I was about to resize my windows partition to get unallocated space and resized my ubuntu to fill it. But then i got this:

"Moving a partition might cause your operating system to fail to boot.

You have queued an operation to move the start sector of partition /dev/sda3. Failure to boot is most likely to occur if you move the GNU/Linux partition containing /boot, or if you move the Windows system partition C:. You can learn how to repair the boot configuration in the GParted FAQ. http://gparted.org/faq.php

Moving a partition might take a very long time to apply."

I got scared and didn't dare to do it, but I still want more space on my ubuntu partition. What should I do ?

Thank you so much in advance

Markus

Answer 1

It cannot be said enough, make a backup and confirm it actually has the required data in it before making a system change like this.

That said, I find that if I move the starting block location of the boot drive (eg from sector 63 to 2048) I have to reinstall grub before the system will boot. For info on how see the ubuntu page How to Repair, Restore, or Reinstall Grub 2 with a Ubuntu Live CD or USB.

Answer 2

I slightly modified the position and size of my / partition using GParted from an Ubuntu 15.04 Live USB key. I had previously bit-for-bit copied it from a magnetic HDD to this SSD and wanted to align the partitions.

At the start I had Grub installed both on the disk itself and on another disk. After moving/resizing the partition I used the instructions linked to from the GParted FAQ that you referenced.

For partition /dev/sdc2 on my Grub 2-based Ubuntu machine with no LVM/RAID this was:

sudo -i
mkdir /tmp/mydir
mount /dev/sda5 /tmp/mydir
mount --bind /dev /tmp/mydir/dev
mount --bind /proc /tmp/mydir/proc
mount --bind /sys /tmp/mydir/sys
chroot /tmp/mydir
grub-install /dev/sdc
exit
reboot

Be sure to replace both the partition and disk with the correct ones for you, and check the actual linked instructions if you have a dissimilar setup.

This may not have been necesssary because the other disk I had Grub installed to was still able to boot the system.

Answer 3

Update for 2022.

Yes, it’s fine.

I just did this exact operation on a partition containing an installation of Ubuntu 22.04, using the Ubuntu 22.04 Live image.

Answer 4

If you move the partition that contains /boot (usually where Ubuntu is installed), Grub will not be able to load and will go into a recovery line mode when booting up your computer.

I myself haven't moved my Partition to give me more room because of that scary message.

For this next step, make sure you have a Ubuntu live CD/USB on you to boot from.

Make sure to backup all your important files, then use your GParted live CD to move the partition you want to move.

Then reboot your computer, boot into your Ubuntu live CD/USB, and with a Terminal, run sudo update-grub. If that doesn't run, try sudo apt-get install --reinstall grub && sudo grub-install. Then sudo update-grub.

Hopefully this works.

Answer 5

It is highly recommended to backup any important files before doing resize/move operations.

The Gparted message merely warns you about the risk of losing data when resizing. It does not mean you will loose your data but its possible.

I use Gparted and other partitioning software to change size of my partitions (Ubuntu, XP Vista, and 7 just as an example) almost on a daily basis, and never encountered any problem.

It is highly recommended to backup any important files before doing resize/move operations.

Answer 6

Backup any important files.

In Windows run defrag and chkdsk / f.

Start with a live-cd with gparted and reduce the partition.

Reboot with Windows. If everything works correctly.

Start with a live-cd and using gparted increases Ubuntu partition.

Open a terminal, get the UUID of the partition, chroot, edit the / etc / fstab file, correct the UUID, reinstall Grub, running:

sudo su
fdisk -l
blkid /dev/sdax 
#/dev/sdax = linux partition - mount as /
mount /dev/sdax /mnt
mount --bind /dev /mnt/dev 
mount --bind /dev/pts /mnt/dev/pts
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt
nano /etc/fstab
#Change the UUID if this changed to /dev/sdax mount as /
#Save the file (Control+O). Close Nano (Control+X)
grub-mkconfig -o /boot/grub/grub.cfg
grub-install --root-directory=/mnt /dev/sda
grub-install --recheck /dev/sda
umount /mnt
reboot

Answer 7

In addition to the above very detailed advice, most of it excellent, I will add the following:

1) Aside from backing up all data which may be jeopardized, I create at least two redundant backups of boot, one by directly copying the entire partition to a new partition using a partition utility such as partition magic or gpart, both of which as I recall may have this feature in some versions. I supplement that with a backup on a flashdrive or another computer. Be aware that there are hidden files which you may or may not have captured and unless you set your file manager to show hidden files you won't know.

2) What I personally always do when in this situation is to leave my boot partition untouched and resize/move only data partitions and root. That way, I don't need to worry about updating or reinstalling grub. I don't know that you have asserted any good reason to mess with /boot.

3) Aside from the above instructions I would add that if you are lucky you might easily update grub if you can boot into Ubuntu recovery mode. You can get there via the second option, the boot Ubuntu advanced option. That will present you with an old fashioned menu with fdisk and other choices. Choose the grub option and if you are lucky it will automatically update itself for you.

Note: If you don't know how to get into the grub menu, you will find on some Intel machines that you can find an option "Boot from an EFI file" in the boot manager. You should be able to wrestle yourself into the boot manager by experimenting with hitting Fkeys on bootup and surfing through the resulting menus.

Answer 8

I successfully increased my /boot size by decreasing the / partition since they are next to each other using live-USB GParted. No need of updating grub.

Dual OS Windows 11 ZorinOS 16 (Ubuntu focal)