GParted disagrees with other partitioning utilities about my drive structure

[somelurker]

GParted disagrees with lsblk, Windows's Disk Management utility, and the Windows Diskpart utility about my partition structure. gnome-disk-utility (AKA UDisks) agrees with GParted though. According to GParted, the structure of one of my drives is as follows:

Partition 1: 1 GiB fat32 efi partition
Partition 2: 236 GiB partition
Unallocated Space: 1.85 MiB
Partition 3: 1.00 GiB ext4 partition

The disagreement is over whether the unallocated space exists. GParted and UDisks says it does. Every other program, including lsblk in Mint, says it doesn't. Why the disparity, and who is correct?

Background information: This drive initially had only 3 partitions: The EFI partition, the 236 GiB Windows partition (encrypted), and the 1 GiB Linux partition. A Windows update carved out some free space from the biggest partition and used it to create a recovery partition. The update also placed 1 MB of unallocated space between the newly created recovery partition and the 1 GiB ext4 partition. So after the update, my drive looked like this:

Partition 1: 1 GiB fat32 efi partition
Partition 2: 235 GiBish partition
Partition 3: Roughly 500 MB recovery partition
Unallocated Space: 1 MB
Partition 3: 1.00 GiB ext4 partition

I didn't like the recovery partition. I don't even know how Windows was able to carve out a piece of an encrypted partition. The carved-out piece was apparently also encrypted using the same key. So I deleted the recovery partition in GParted, creating a roughly 500 MB block of unallocated space to the the right of the biggest partition. Using Windows 10's Disk Management utility, I then extended the biggest partition so that it would take up all the unallocated space. The operation was successful.

However, I am now faced with a situation in which various partitioning utilities disagree about the structure of my drive. Does anyone know the cause, and what I might be able to do to fix the problem?

[Pierre]

that Gparted will most likely .. be correct.


one of the issues involved is this oldie:
- the Sales Dept says that there is 1000Kb in a Mb
- the Technical Dept says that there is 1024 kb in an Mb
and the Metric system then apply that, to all other variations .. like Gb & Tb .. ..
- - you will find this issue .. eveytime, that you mofify any exting drive.

the program Gparted then amplifies, that issue.

[somelurker]

I initially partitioned the drive with GParted though, and the unallocated space wasn't part of the drive structure. Was the failure on the part of Windows for failing to take up all the unallocated space to the right of the Windows partition? I used Windows to extend the biggest partition because using GParted would have required me to decrypt the entire Windows partition, then re-encrypt; a huge mess I don't want to get into every time Windows does a major update.

If you're right, I will just ignore the small amount of space. 1-2 MiB is not a huge loss. I'm more worried about future partition changes causing data loss. If data loss isn't an issue, then I will leave things the way they are. Wiping the drive and reinstalling everything to regain 2 MiB would not be worth the time or the trouble.

[pbear]

Out of curiosity, what is Partition 3 for?

[somelurker]

It's the /boot partition for a Mint installation. The actual installation of Mint is on a different drive. I needed to be able to boot into either Windows or Mint, but due to space limitations I also had to spread them across the two different drives. I believe I tested putting the /boot partition on the second drive with the Mint installation and couldn't get it to boot. The VeraCrypt boot loader is the first program to boot. If I need to get into Mint instead, it passes control to the Mint /boot partition, which in turn is able to access Mint installation on the second drive. I don't remember how exactly the /boot partition knows which partition to decrypt, but I think it has something to do with UUIDs.

Unfortunately, there's very little documentation on how to get VeraCrypt and LUKS to play nice together, let alone on two different drives. I was too busy to tinker with it further, so once I got a working setup, I just kept it like that. If you know a better way, please enlighten me. I went to a lot of trouble to figure out how to get this scheme to work on both UEFI and BIOS. The basic requirements were:

1. Encrypted Windows installation
2. Encrypted Mint installation
3. Ability to boot into either one at will

The encryption is what makes booting so tricky. Dual-booting and even multi-booting Windows + 1 or more Linux installations is generally a piece of cake. There's much less information out there on how to encrypt each installation and still maintain the ability to boot into all of them.

[pbear]

Thanks for the explanation. Surprised it works, actually. I've read several places that Linux won't boot under VeraCrypt (or TrueCrypt). Never tried it, so frankly I'm not following what you did, but sounds clever. BTW, the reason I asked was that I was wondering whether deleting/copying/moving that partition while doing the other stuff would make things easier. Sounds like, probably not worth the risk of breaking it.