Partition created with Minitool Partition Wizard or Linux not recognized by Windows 7 and vice/versa

Question

I'm having a helluva problem. The tl;dr background is that I'm trying to set up a dual boot system with a shared TrueCrypt/NTFS partition for work files. Computer details:

• HP ZBook 15
• 256G m.2 SATA SanDisk SD6PP4M SSD
• BIOS set to legacy mode
• MBR, not GPT (googling problems like this are often GPT related. This is not).
• SATA mode set to AHCI

The computer started with the following partitions:

• System
• C:
• HP_RECOVERY
• HP_TOOLS

I backed up the latter two, and extended C:

Next, I shrank Windows down to ~80G:

Next, I installed Minitool Partition Wizard since Windows doesn't change partition IDs (that I know of), and I needed /boot and / as type 83 for installing linux. I also needed my shared partition for TrueCrypt/NTFS, so I created the following out of the free space:

• Primary: 100G for TrueCrypt NTFS, formatted as NTFS (temporarily), ID 7
• Logical: 512M for /boot, unformatted, ID 83
• Logical: 50G for /, unformatted, ID 83

I'll shorten the middle of the story, which involved being unable to get EasyBCD to chainload to my logical /boot partition. There was a lot of creating/deleting/formatting of volumes involved from Minitool but nothing else (e.g. no writing to the MBR).

Somewhere along the way, I stopped being able to create logical partitions in Minitool. I could add them to the action queue, click apply, it would say "Operation successful," but the space would show back up as unallocated. Like this:

Actions queued and ready to rock:

After clicking apply (note I've just got a final chunk of unallocated space and no partitions):

Not so fast... Windows disk utility seems to think the operation went fine!

I can even format them:

Now, boot into an Arch linux install USB and see what it thinks:

### sometimes booting to USB reverses the normal /dev/sda for the SDD
### with /dev/sdb. This reboot happened to be one of those times...

# fdisk -l /dev/sdb

Invalid flag 0xefdb of EBR (for partition 5) will be corrected by w(rite).
Disk /dev/sdb: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1e6513b3

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sdb1  *          2048    2101247    2099200     1G  7 HPFS/NTFS/exFAT
/dev/sdb2          2101248  172433407  170332160  81.2G  7 HPFS/NTFS/exFAT
/dev/sdb3        172435393  500103167  327667775 156.3G  f W95 Ext'd (LBA)
/dev/sdb5       3629746069 6108529054 2478782986   1.2T 74 unknown

So, obviously something funky is going on with the extended/logical partitions (error from fdisk and 256G != 1.2T...).

How about letting fdisk do the work?

# fdisk /dev/sdb
### delete partitions 3 and 5
### new primary, default start, +50G, change type from 83 -> 7
### new extended, default start, default end
### new logical, default start, default end
### w to write

# mkfs.ntfs -f /dev/sdb3
# mkdir ./ntfs
# mount /dev/sdb3 ./ntfs
# touch ./ntfs/test.txxt
# umount /dev/sdb3

# mkfs.ext4 /dev/sdb5
# mkdir ./ext4
# mount /dev/sdb5 ./ext4
# touch ./ext4/test.txt
# umount /dev/sdb5

Back in Windows, if I click on D:, I get prompted to format it and told that it's not a recognized format. How about Minitool? Seems just fine and it can even see the contents (right click D: -> Explore)!

Windows disk utility tells a different story:

I've been chasing this for many, many hours. Things I've tried (all unsuccessful):

• Formatting with FAT32 instead of NTFS
• Single primary vs. two primary vs. one primary + logical
• Formatting from Linux vs. from Win disk utility vs. from Minitool
• chkdsk /f c: (flags for check on reboot, reboot, no issues found)
• Press Esc at boot, go to hardware diagnostics, run short test, no issues found
• chkdisk /f d: (if created by Minitool, it finds an $MFT error, fixes it, and then Minitool doesn't recognize it as being formatted any longer)
• Defragging
• Deleting non-Windows partition, re-growing Windows to the full disk, and starting the partition process over from the beginning
• If I try to format the partition in Windows disk utility and mount it in Linux, I get the error "NTFS signature is missing."
• I noticed that if I delete the 3rd partition in Windows disk utility and recreate it in place, the end sectors change slightly (from 382146607 to 382146559). I thought maybe this was the issue so I create the partitions in Windows (additional primary + 2 logicals), paid attention to the start/end sectors of /dev/sda3 and the extended container, and recreated the partition table using the same values. No luck.

So far, I've found no scenario at all where both Windows disk utility and Minitool agree. I did have a successful dual booting system. If I create the partition table with fdisk, it appears that Windows is happy to boot to C:, and Arch Linux is happy to boot to /dev/sda5 (logical for /boot). It's just that the two of them don't seem to recognize a partition as valid at the same time.

A complication to this issue is that the laptop is a work computer that came with McAfee Endpoint Encryption (EEPC). There is no pre-boot authentication, but I believe some parts of the MBR may still be encrypted. The partition table apparently is not, as fdisk didn't prevent me from booting (I made a backup of 512MB of /dev/sda using dd before trying that, btw). I add this, as I did run across some McAfee docs stating that fixmbr should not be used (can't re-find it at the moment).

Does this behavior bring any ideas to mind as to what the issue could be? Given that Minitool used to agree with the disk utility, I think something inadvertently went awry.

I'm trying to decide if this is fixable or if I should just ask to have the drive re-imaged. I just got it about a week ago and haven't restored all my files yet (since I haven't been able to create a shared partition either with or without encryption), so this is the ideal time to bite the bullet and submit a ticket.

My undesired workaround to avoid giving up the laptop for half a day and starting all over would be to get a 64G tiny flash drive and leave it permanently in a port. I'd use it either for the encrypted TrueCrypt/NTFS storage or Arch.

Thanks for any suggestions, and feel free to ask for any additional information.

Answer 1

Encryption tools sometimes store data in places that conflict with boot loaders or that might cause partitioning tools to misbehave. My hunch is that this is what's causing your problems, but I can't be sure of that.

My first suggestion is to consider using virtualization rather than a dual-boot setup. If you can run Linux inside Windows or vice-versa, that will mean that you'll just need to make one OS (and its encryption tools) happy with your setup, not two of them. This also means you won't need to find a cross-platform encryption tool, which may broaden the scope of what you might consider.

My second suggestion is to keep trying other partitioning tools. You might try parted or GParted (both based on libparted) on the Linux side; and there are other third-party partitioning tools on the Windows side. It's conceivable that one of these tools will make everything else happy.

Answer 2

Rod's answer got me wondering if non-system partitions were possibly encrypted. Well, looky looky (McAfee Endpoint Encryption status):

D: and F: are partitions created with Windows, so it appears that they're automatically encrypted. A workaround I'm considering is to format with Ext4 and perhaps if they are non-Windows-native, McAfee will leave them alone.

This definitely explains why I can't mount them in Linux. I'm still a bit confused as to why 3rd party partition tools don't necessarily recognize them. Perhaps there's some auxiliary data/info/partition table used by Windows/McAfee to know what the "real" format of the file systems are. Minitool apparently doesn't have access to that, or isn't doing it properly as it doesn't see them as formatted.

Also, I'm thinking if they're created with Minitool, something isn't updated and thus Windows doesn't see them as formatted, perhaps since it's looking for a drive to decrypt and it isn't encrypted?

Anyway, perhaps I shouldn't speculate on the exact reason why; the main point was to confirm that this is almost certainly encryption related. My former laptop had the same setup, so perhaps Endpoint Encryption was updated or it's policy changed to encrypt non-system partitions. This wasn't previously the case.