Resize/move encrypted partitions in a dual-boot setup

[tryingtopart]

Hello there,

I am aware that similar questions have been asked before but I am a bit unsure about the particulars in my case.

As the title says, I’d like to resize and move around partitions, some of which are encrypted. More specifically I am running a dual-boot setup with Windows and Endeavour. I’d like to shrink the bitlocker encypted windows partition (I can do that from within windows) and subsequently move my linux partition right after it so there is now free space to the right. Subsequently I’d like to grow the linux partition to take up all the remaining space. My exact setup looks like this in GParted:

What worries me is the encryption involved and the dual-boot setup itself and I haven’t seen a case discussed yet, where all of that has to be taken into account.

What I think I could do is:

1. shrink the bitlocker/ntfs-partition (/dev/sda3) in Windows. That should just work I guess.
2. boot into a live system and run gparted there.
3. move /dev/sda5 to the left so it is adjacent to the now shrinked /dev/sda3.
4. resize /dev/sda5 to take up the remaining free space to the right of it
5. reboot and be happy? (maybe resize the actual filesystem on /dev/sda5 or would GParted already take care of this?)

Not so sure about step 5. Will the preboot authentication still work? There is a password prompt for hd0,gp5. Only after that prompt do I see the actual GRUB menu. Will GRUB still work and let me boot both, Windows and Linux or does something need to be adjusted?

Am I missing any crucial steps (besides backing up important data…). I assume I don’t have to reinstall GRUB since I just move the partition which it is installed to, right?

Thank you in advance!

edit: success! summary below
I marked one post as the answer, but really - you should skim through everything for better understanding and useful hints!

So basically what I wrote above worked. But still, let me summarize:

1. Backup everything that is dear to you if you haven’t already!
2. I shrunk my Windows bitlocker partition from inside Windows. That was painless. However I could not use all the remaining free space for shrinking because of “unmovable files”. I was okay with that, but in case you wonder what to do, this should get you started. That can take a little while - be partient. After that I rebooted into Windows just to be sure everything still works - this is unnecessary though.
3. I then booted into a live system. I used the latest Endeavour-ISO for that. Eventhough this isn’t strictly necessary, I backed up the LUKS header of the partition I was going to move/resize. Not sure if this is tremendously helpful in case things go south, but I thought it couldn’t hurt.

sudo cryptsetup luksHeaderBackup /dev/sda5 --header-backup-file /path/to/backupfile`

Be sure to adjust sda5 to whatever partition you are going to mess with.

4. After that, I installed gparted inside the live system. In case you mounted your partition, unmount it now. In order to move my partition to the left, I needed to lock/close it! That couldn’t be done with the partition unlocked. Then I let gparted do its job. Once again, this can take a while.

5. gparted finished successfully. There was a notice that read like this:

Maximize closed LUKS encryption skipped because it will automatically fill the partition when opened

6. You can skip to step 7. I rebooted into my locally installed Linux and everything worked! However the available free space on the filesystem didn’t change, eventhough the partition was grown properly. => back to the live system and gparted

7. Now unlock the freshly moved/grown partition, rightclick and choose “check”. This will ensure that all the newly freed space is indeed available. This is, what gparted did in my case:

grow encryption volume to fill the partition  00:00:00    ( SUCCESS )
cryptsetup -v resize 'sda5_crypt'  00:00:00    ( SUCCESS ) 
grow file system to fill the partition  00:00:07    ( SUCCESS )

resize2fs -p '/dev/mapper/sda5_crypt'  00:00:07    ( SUCCESS )
Resizing the filesystem on /dev/mapper/sda5_crypt to 28835328 (4k) blocks.

8. Reboot into your Linux installation and enjoy your free space. I booted into Windows aswell - everything works. Thanks for all the help!

Some minor clarification about some of the stuff in the posts below: I said “something” gets loaded from the ESP (efi system partition) and so on. @dalto clarified that this something is grub. I was wondering how grub is supposed to know which parition to unlock - so in case you are wondering about the same thing: turns out that this information is “baked” into the efi-binary in /boot/efi/EFI/Boot/bootx64.efi, where /EFI/… is just the contents of your efi system partition mounted to /boot/efi. I stumbled across this here.

So thanks again everybody for your help.

[thefrog]

you really need to consider the time and effort you want to put into this.

first you cannot just

@tryingtopart

move /dev/sda5 to the left so it is adjacent to the now shrinked /dev/sda3.

without removing /dev/sda4 (microsoft diagnostic disk)

is that something you wish to do?

as far as the encryption stuff hopefully @pebcak will run across this and offer a suggestion.

[tryingtopart]

Well, my intention was to leave everything untouched except for the two partitions I’d like to resize. The layout you see comes from installing Windows and subsequently Endeavour to the same disk and as of today it still works flawlessly.

Can you explain why /dev/sda4 would have to be removed in order to move/grow a partition before it? To be clear: I want /dev/sda5 to take up the space that gets freed by shrinking /dev/sda3. No need for /dev/sda5 to be the very last partition on the disk.

From your remark it sounds as if this whole operation was a bit more complex than I thought. Good thing I asked then I guess. I was hoping for this to be done in 10 minutes. But lets see.

[thefrog]

the partiton is not layed out the way it shows in the picture the partition is layed out in numerical order there is no way you can add space from /sda5 to /sda3 simply bypassing /sda4

[tryingtopart]

I might be missunderstanding something but the way the partitions are shown in gparted does indeed seem to be the way they are laid out on disk. This is what fdisk has to say:

As you can see, /sda4 uses the last sectors on the disk.

[pebcak]

@tryingtopart

the way the partitions are shown in gparted does indeed seem to be the way they are laid out on disk

Yes, this should be the case.

Also, the steps you outlined in the op should work in principle. Although, if you want to skip the “hassle” of moving around sda5, a process that may run the risk of data corruption/loss, you might want to consider to create a Linux compatible filesystem on the space you will carve out from your Windows install and mount it into your Linux install as an extra data partition.

However, if you opt for moving sda5 to the left, please make sure to make a backup of your personal data and perhaps your config files/folders under your home directory. If things go wrong, you could always reinstall the system and restore your data.

@tryingtopart

• boot into a live system and run gparted there.
• move /dev/sda5 to the left so it is adjacent to the now shrinked /dev/sda3.

You would need to decrypt sd5 first. It should be possible using Gparted for doing it so. Right click on the partition and choose Decrypt.

@tryingtopart

maybe resize the actual filesystem on /dev/sda5 or would GParted already take care of this?

This should be done by Gparted automatically for the filesystem to fill out the newly enlarged partition.

If you want to really make sure, you could do a right click on the partition and run a filesystem check.

[tryingtopart]

@pebcak

Also, the steps you outlined in the op should work in principle.

Great! Yes, I will probably try my luck (with backups - I promise!). Apart from a faulty drive and user error, are there any other reasons you are particularly concerned about when moving the partition?

Last question for now: You didn’t specifically pick up on my concerns regarding grub and the preboot authentication, so I assume you expect that to “just work” after resizing/moving? This was what I was most worried about.

Thanks for your explanation so far! I hope to get around to try this in the next few days. If everything goes right, I will report back.

[pebcak]

My main concern with moving the partition is the probability, however small, of data corruption if something interferes with the process for it to not finish successfully like sudden power cut or battery running out for example.

@tryingtopart

Last question for now: You didn’t specifically pick up on my concerns regarding grub and the preboot authentication, so I assume you expect that to “just work” after resizing/moving? This was what I was most worried about.

I have to admit that I don’t use myself an encrypted system partition so, admittedly, I am not best suited to address your concern in this regard. My assumption is that things should work as expected.

However, if you are not in a hurry, please do wait for other forum members to chime in and provide more insight. Perhaps @dalto, @2000 or others could shed more light.

[tryingtopart]

Alright. Perfectly valid points. Thanks.

No hurries here, I can wait a bit.

[dalto]

As long as the UUIDs don’t change, that stuff should “just work”.

However, if any of those changes trigger new UUIDs, you will have some work to do in a chroot.

[pebcak]

Normally, at least using Gparted, the UUID of the moved/resized partition remains the same.
Actually using PARTUUID is perhaps even more robust way of specifying entries in /etc/fstab as it is resilient to formatting too.

Changing name & label of the root partition possible?

I have a vague recollection that I read somewhere that PARTUUID is identifier for the partition itself and not the filesystem which is identified by UUID. When the partition is formatted, the filesystem will get a new UUID but the PARTUUID remains the same. Take this with a grain of salt PS. I am gonna test it on a partition and report back. Update: Looks like my memory still serves me right sometimes Before formatting (ext4): $ sudo blkid /dev/sda6 /dev/sda6: UUID="a9b…

[tryingtopart]

Hm - /etc/fstab contains entries that are not supposed to change anyways except maybe for the ext4-filesystem. So this should be a none-issue then in this case I guess?

I do not plan to touch the EFI partition in particular. But I was worried that whatever refers to “hd0,gpt5” at boot does not find what it expects to find after moving/resizing. Sorry for this vague description but am not enitrely clear on how this whole crypto-setup works.

This is slightly off-topic but just to be clear: my understanding is that “something” gets loaded from the EFI-partition during boot (not sure what the correct terminology here is).

This “something” unlocks partition 5, where grub seems to be installed in my case. This is the point where I was most afraid of stuff breaking. Grub then loads and offers me to boot into the linux system, which resides on the same partition or to boot windows. Probably by “calling” another something on the EFI-partition to handle the bitlocker stuff and in turn finally boot windows.

[dalto]

@tryingtopart

This is slightly off-topic but just to be clear: my understanding is that “something” gets loaded from the EFI-partition during boot

If you are using grub, it is grub that gets loaded. It gives you a prompt to unlock the partition then uses it’s own filesystem drivers to unlock and access the data. After that, it gets access to the grub.cfg from the encrypted partition, reads it and displays the menu.

[tryingtopart]

Happy to report success! Everything worked flawlessly! I edited my first post with a small writeup. Thanks everyone for your help!

[pebcak]

Great to hear that everything worked out the way you wanted!
And also thanks for the writeup!