Is this strategy of resizing partitions containing Manjaro-Windows dual boot correct and safe?

The current state of my partition which contains Manjaro and Windows 10 (on dual boot) is

I want to enlarge the following partitions and leave the rest unchanged:

  • *p3 (Windows)
  • *p5
  • *p6
  • *p7 (more flexible, staying the same is also an option)

So I imagine the final configuration will be:

  1. at the rightmost is *p4 (NTFS) with the same size.
  2. Adjacent to the left is *p7 (linuxswap) with probably the same size (I have 16 Gb RAM, would you suggest the swap to also be this amount?).
  3. Moving to the left, you have *p6 (/home) that is now enlarged to the space that is left.
  4. Moving to the left, you have *p5 (/) that is also enlarged.
  5. To the left you have the enlarged *p3 Windows partition.
  6. The rest is the same as initial.

With this configuration, therefore the left point of *p3 stays unchanged while its right point move to the right. Thus, all partitions to the right of *p3 will shift to the right.

My plan is the following:

  1. Create a Manjaro live USB and boot into it.
  2. Open Gparted and shift the boundaries of *p5, *p6, *p7, and *p4 to the right to exhaust the entire empty space. Doing this will leave an empty space between *p3 and *p5.
  3. Reboot into Windows and use its partition manager and move the right point of *p3 to exhaust the empty space created at the end of the previous step.
  4. Done.

My concerns:

  1. Many articles I managed to find suggest that I should have a backup of my system first. The storage I am resizing now is a newly installed SSD that was cloned from an older one just a few days ago. So, I guess my old SSD already constitutes a good backup.
  2. UUID of partitions can change during resizing and can make Manjaro unbootable. Solution is to edit the /etc/fstab to use the new UUID which can be found, e.g. through parted -l. Ref: How can I extend my Manjaro partition? (from Windows to Manjaro) - Newbie Corner - Manjaro Linux Forum. Is it all there is to dealing with changed UUID?
  3. What about Windows, are there situations where it becomes unbootable after partition resize?

You cannot do this without destroying your data. If you really want to make such extensive changes to your partitions, then I would advise you to back up all your important data, either to a second drive or to an external drive, and to then reinstall everything.

Resizing a partition is not the same thing as resizing a filesystem, and gparted cannot do what you think it can do.

Is it because I also move the left point of the partitions?
As an alternative, I am thinking of recloning it but this time do a partition-to-partition clone (I use clonezilla). I guess for this to work, I need to prepare the target storage partitions configuration. Not sure either if this will work though.

Among other things, yes. But like I said, resizing a partition is not the same thing as resizing the filesystem that’s on it. Partitions are only designated ranges in the partition table.

What are the other things then? If, say, the partition to be enlarged is at the right most hence you only need to move its right point to the right, will this also have the chance of losing some data?

Is there actually an issue in enlarging ext4 and ntfs partitions? AFAIK the theoretical file number limit is the same, whatever the size of the partition. So enlarging partitions using those filesystems shouldn’t make much difference…

Not in that case, but enlarging the partition does not necessarily mean that the filesystem will be enlarged as well. You’ll have to do that separately.

Some filesystems can be enlarged while they are mounted, while others must be unmounted first. If you use ext4, see… :arrow_down:

man resize2fs

It depends on the type of filesystem and how it is physically laid out on the storage volume. I’m not enough of an expert to comment on that, least of all when it comes to ntfs. :man_shrugging:

I am confused, out of a bunch of threads on this topic I found in this forum, I haven’t found any mention of resizing filesystem. What happens when you manage to enlarge partition but filesystem stays the same, does it mean the actual size of the filesystem is not the same as the partition it is on?
And in which situation do you need to increase the filesystem in addition to increasing partition?
I guess I am not understanding correctly what filesystem is.

That is correct.

All of them. :man_shrugging:

A partition is a region of your drive, with its boundaries ─ beginning and end ─ set in the partition table.

A filesystem is an organized construct in which files are stored, along with their attributes and ─ in the event of UNIX operating systems like GNU/Linux ─ their ownership and permissions. The construct allows for files to be organized in directories (“folders”), and for files to be retrieved, opened, closed, moved, renamed, and so on.

1 Like

I never needed an extra step when resizing partitions. gparted probably handled that automatically though…


It’s good practice to unmount partitions before managing them anyway…

4 Likes

Increasing this Bitlocker partition with Linux tools is difficult, better ask in Windoze forum.

Changing the size of the Linux partitions is pretty simply and less risky but first you need to think about what size you exactly want to achieve for each partition as this affects the strategy to modify your partiton setup. But remember: When you move the start sector of your / partition then you must restore the boot loader afterwards.

I agree with @maycne.sonahoz, if GParted is used and the (unmounted) filesystem is ext4, it is extended as well when the partition is increased in size, I never had any issues. :man_shrugging:

3 Likes

I know this can potentially be an issue, that’s why I intended to do the WIndows partition through Windows, as written in the original post.

Multiple voices on this, I guess I will have to try by myself to see how it actually goes. But the most important thing is, does less risky means the chance of losing data after going through the series of activities I proposed in the original post is low?
Looking at several threads on similar topic, most of it deal with moving the right boundary. In my case I am also moving the left boundary which I am concerned with whether this will make data loss more probable.

How do you restore the boot loader? Previously when I changed my SSD, BIOS decided to re-enable Secure Boot without informing me. This makes booting skip Grub and I couldn’t boot into Manjaro without disabling the Secure Boot through BIOS setting. Do you mean the same thing?

Before proceeding with further questions I would recommend to focus on providing relevant information, first:

No, I was not talking about Secure Boot which must be switched off, certainly. I was talking about the position of the / partition, i.e. the sector number. When this is changed for the / partition grub won’t work, therefore it must be restored. Never tried to use a search engine to find answers? :stuck_out_tongue_winking_eye:

https://wiki.manjaro.org/index.php?title=GRUB/Restore_the_GRUB_Bootloader

1 Like

The GUI illustration of your disk might be misleading you. The left- or right-handedness of the partition in the illustration doesn’t necessarily translate to any specific orientation on the actual disk. What is a more important consideration than what you are calling the left or right boundary is whether the partition is shrinking or expanding. As a general rule of thumb, shrinking a partition is riskier (from either “side”) and expanding a partition is more or less harmless.

Honestly, the elaborate piecemeal adjustments you are preparing for seem way more complicated and prone to disaster than just reformatting the whole disk with the final partition sizes you have decided on and restoring from the backup. Especially with Windows partitions involved. I think you can spare yourself a lot of grief if you just scrap the disk and start over with the setup you want since you have a relatively fresh backup.

2 Likes

The final sizes that I want are:

  • *p5 - 60 Gb
  • *p6 - 671 Gb
  • *p3 - the remaining space
    The others remain the same.

Per that definition of “shrinking” and “expanding”, I will therefore be shrinking one side and expanding the other. So there is indeed an element of risk here.

This is one alternative I am considering but I have little information how to do it. If I get your message correctly, you are suggesting that I should reformat my new SSD that is currently already holding data and then partition it to the desired arrangement. Up to this point, I think it’s just formatting the SSD and then use KDE partition manager to create the partitions. Then comes the cloning process from old (smaller) to this (bigger) new SSD. I used clonezilla with beginner setting and disk-to-disk option when cloning to what I am currently using now. Should I use partition-to-partition this time instead? And in this case, I will be cloning from one partition to another with bigger size, does it entail another concern or difficulty?

And by the way, I am getting this “what you are intending to do is prone to data loss” kind of warning in this thread, which I have anticipated. But could someone please tell me is this data loss due to human error (clicking wrong button etc) or the computer’s behavior itself that is not entirely predictable on this kind of job?

Honestly the thing that really makes me hesitate is the Windows partitions.

My PC has an SSD that currently has four different Linux distros on it. I install different ones to check them out, move stuff around, resize partitions, whatever and it’s generally fine. With btrfs you can even resize the filesystem and change the partition size (even shrinking it down) while the disk is mounted and you are booted into the OS. It seems a little like open heart surgery, but it works. Even when you break something in Linux you can often figure out how to fix it or at least what your next step should be with some digging around.

Windows is much easier to break. The forums are rife with folks who made some small change to a partition or installed something next to Windows and all of a sudden Windows won’t boot anymore. The fact that one of the partitions is encrypted with BitLocker adds another level of complication. It’s not impossible, but it might get tricky is all.

If you want to keep the stuff you have already set up, the standard way to do it would be to:

  1. Resize the file system. A safe practice is to resize it to about 20% smaller than the partition size, because of the GB/GiB conversion.
  2. Resize the partition.
  3. Expand the filesystem to take up the full partition again.

And then do that for each partition to resize.

The reason I suggested starting over is because I got the impression that you had just set up this disk but changed your mind with how you want it set up. It might be easier, that’s all.

You can stick with Clonezilla for sure. It is a very robust and user-friendly program. Installing by partition I think is a safe bet. I would read through the docs and make sure you are comfortable with the procedure, but honestly it should only be marginally more complicated than the “beginner setting disk-to-disk” option you used last time.

1 Like

I think your plan is OK.

Shrinking/expanding ext4 partition with GParted will not change the UUID.
Expanding ntfs partition with Windows disk manager is also safe, if it is allowed. I’m not sure about the bitlocker part.

Just avoid power loss while progressing.
Shrink/expand one partition, reboot and verify. Then shrink/expand next partition, reboot and verify, till the last one.

Good luck.

2 Likes

I see, so I should move the rightmost partition in windows too. I am not sure how it got there. When I installed Manjaro, the two Windows partitions on the left were already there.

If possible, use Windows software to resize/move ntfs partition, such as Disk Genius.
It has a free version can do partition resize/move.
https://www.diskgenius.com/editions.php

Or Best Professional Partition Manager | MiniTool Partition Wizard Pro
Or How to Move Windows 10 Recovery Partition without Data Loss?

I haven’t move Windows Recovery Partition with GParted before, so I am not sure if there will be problem.

1 Like

It’s actually pretty simple:

The answer is here:

That partition is also part of the pre-existing Windows installation.
You installed Windows (?)
and gave it not the entire disk, but only a part of it.

Then, afterwards, you used the remaining space,
again, not all of it,
to install Linux.

If you look you’ll see that p4 (Windows_RE_tools)
is also “in front of” the Linux partitions.

So, now you have /boot/efi
and then the Windows partitions, the main one is encrypted (Bitlocker)
and then the three Linux partitions
followed by unused space.

To increase any Windows partition,
in your case p3 (the Bitlocker encrypted Windows partition)
you have to move all the Linux partitions out of the way.

This can be done with gparted or KDE Partition Manager.
Cave!
I have only ever used the former, never the latter.

While the risk of moving (and resizing) the Linux partitions may be small, it is still there.
And, since it involves your / partition, the bootloader (Grub) will need to be adjusted/restored
so it then knows where to find the relocated root partition.

Once the Linux partitions are moved out of the way
(and the system will boot afterwards)
you can turn your attention to the Windows partitions.

Use Windows itself to deal with them!

I do not know whether it will be a problem to move p4 (Windows_RE_tools).
This is the recovery system - you probably do not want to lose it.
I don’t think it is essential but I have very limited Windows experience and this is from a long time ago, too.

The process of moving partitions requires all the data to be moved, which can take a very long time
(that has been my experience).

What I’d do, in order, is this:

  • backup my Linux data - and the Windows data as well, while I’m at it
  • lose the Linux partitions - or move them
    (moving and resizing them will take a long time and still need some work afterwards to make the system bootable again - reinstallation is quicker)
  • adjust the Windows partitions to their desired size (from within Windows)
  • then proceed to deal with Linux …

Be prepared to face an unbootable system - familiarize yourself with how to boot using external tools
like a Linux live medium and/or a Windows rescue environment
to boot your systems -
and what to do to restore Grub so it’ll boot both Windows and Linux again.

Option one is far more likely - you have to understand the process involved, the sequence of events that need to happen in order.
The computer is very predictable and reliable - it will do exactly what you tell it to do, even if it is the wrong thing.