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:
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
/ 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)
Escat boot, go to hardware diagnostics, run short test, no issues found
chkdisk /f d:(if created by Minitool, it finds an
$MFTerror, fixes it, and then Minitool doesn't recognize it as being formatted any longer)
- 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/sda3and 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
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.