Diskpart assign letter to partition that is not associated with a volume (windows 10)

Question

I used to have 3 volumes on my disk before something happened to the MBR that messed up my boot.

Now i'm trying to rebuild the boot environment to save all my data but it seems it is all lost. I can see the data through the command promt (from windows 10 DVD)

I am trying to do bcdboot c:\Windows /m {guid} but it is not working

I have also run:

bootrec /fixmbr (success / no error)
bootrec /fixboot (success / no error)
bootrec /rebuildbcd (failes with error "The requested system device cannot be found") 

I can find a lot of information on how you assign a drive-letter to a volume, but not how to assign a drive letter to a partition or make a partition associated with a volume.

When selecting the partition through diskpart i 'detail' part tells me: "There is no volume associated with this partition." so i am thinking there must be a way to asscociate it with a volume. but how?

Info: 

list disk : 1 entry 465GB 0 B free

list part : 3 entry 
part 1 reserved 128MB offset 1024kb <- this used to be my boot-partition
part 2 System   465GB offset 129MB
Part 3 Recovery 450MB offset 465GB

list vol : 3 entry
Vol # LTR
Vol 0 D   UDF DVD-ROM 3894 MB healthy  <- (this is where my 128MB boot part used to be)
VOL 1 C   NTFS Partition 465GB healthy Hidden
VOL 2 E   NTFS Partition 450MB healthy hidden

How do i proceed to recover the boot?

Answer 1

I ran into the same issue after using gparted and ntfsclone. diskpart> list partition shows all my partitions, but they don't listed in diskpart> list volume and not associated with an letter.

Find out which partition X you need to associate with an letter:

diskpart> list partition
diskpart> select partition X
diskpart> detail partiton  # I found that partition was hidden

If your disk has GPT table, set partition type GUID as Microsoft basic data partition (corresponding gdisk partition type is 0700):

diskpart> set id=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

If your disk in MBR (07 = Windows NT NTFS; 17 = Hidden; 27 = OEM Recovery):

diskpart> set id=07 override

Now you can try diskpart> list partition again. bcdboot c:\Windows worked for me just fine.

Answer 2

Goodness sake, be careful!

It sounds like not "all is lost", but it also sounds like you only vaguely know what you're doing, and are proceeding. That is a recipe for "all is lost".

To elaborate, it sounds like you're able to access the vast majority of your data, but you're having troubles booting, which is a much simpler fix overall. But if you're not careful, you could easily lose the vast majority of your data.

First, it will help to make sure you know some basic terminology. The MBR is the first sector on a disk. The "MBR"-style of laying out partitions can handle drives up to 2 TB, and it looks like you're dealing with a drive smaller than that, so you might indeed be using an MBR and not the newer GPT format.

The two main jobs of an MBR are to have some initial boot code (instructions that the computer follows), and having 64 bytes of information to store details for up to 4 partitions (each partition table entry is 16 bytes).

Those 64 bytes of information can be pretty important. If you get some of these details wrong, operating systems may not properly understand some details about your partitions. And since operating systems typically write to disks, such misunderstandings can result in writing incorrect details that damage your ability to access data. So, being careful here is pretty critical.

A "partition" is basically a set of boundaries. You specify the starting sector, and either the ending sector or the size. Either way, you get a starting boundary and an ending boundary.

A "volume", sometimes called a "filesystem", stores your actual data. A volume needs to exist within the boundaries of the partition.

Now what typically happens is that an operating system looks at a partition, and assumes that a volume starts right at the beginning of the partition. Also, the partition specifies a "type", which is meant to be a strong clue about which style of volume is being used.

If the operating system can't find the volume, there are multiple possible reasons. One is that the partition's starting sector is wrong, and so the start of the volume isn't being properly found. Another possibility is that an improper "type" is being used, so the operating system doesn't know how to interact with the volume it is using. Another possibility is that the volume is damaged, and so the operating system is unable to find a volume that matches some details that the operating system checks for.

On my system, which is using GPT and that might cause some slight but significant differences, the "System" drive is the small drive (under a gigabyte), and my important data is stored on the large partition which shows up as a "Primary" type. The "System" type is not assigned a drive letter (although that isn't too hard, or problematic, to change... I would recommend assigning it a high drive letter, like S:, rather than C: or slightly higher. I also recommend avoiding X: since I think the Windows boot disk likes to use that.)

Since your System volume isn't even showing up, to me that suggests that it is damaged. You might need to restore that, providing a fresh copy of the boot files. This might not be something as easy to fix as using BCDEdit, which basically just tries to make slight changes. Your best bet may be to simply re-install the operating system (even to the same drive), which should accomplish a couple of things: placing a fresh (and not-updated) copy of Windows on your hard drive (which may be able to just overwrite, possibly even in-place, your current installation) and adjusting the ability to boot.

There might be an easier/simple way, but I recommend preparing for the possibility that there isn't.

However, I strongly advise you to get a full backup first. If at all possible, I even advise you to not just back up a few files that seem important, but to get a "forensic"/"bit-for-bit" image of the entire drive (onto another drive that is at least as large). That way, you can be comfortable that you're not going to lose your important data while you try to make any changes, and that you can revert in case any attempts go awry.

Having looked over your conversation with GuitarPicker, I am not as worried about your DVD drive showing up as it does. I think that just happens as a result of your boot partition not being detected; if your boot partition were detected, the DVD would automatically be assigned a higher drive letter without a problem. Using SET ID may indeed be helpful (and to find an existing ID, also known as a type, you can SELECT a partition and then say DETAIL PARTITION). But you did say, "I tried again to delete the boot partition with diskpart and recreated it". The problem here is that when you deleted the boot partition, you effectively told the computer to stop keeping track of any data on that partition, such as the critical data used to boot. Then, even if you did create a new partition and volume that are classified as the correct "type" for a boot partition, you still lack that bit of data that is used to boot the operating system. The typical way of getting that data onto a boot drive is called "installing the operating system".

While there might be some way to just transplant such boot data from another computer, some of the data may need to be placed in specific sectors on the volume (a picky detail which is not usually a concern except when dealing with boot files), and so this might or might not be quite as easy as just trying to do a basic copy. In other words, such a transplant has potential for troubles that make this approach not recommended for novices.

Note: I did read your comment about going from Win7 to Win10. You might be okay to just install Win10 over your existing drive, and if you're lucky then maybe your existing licensing might even get preserved, in which case you might not even need to fuss with going through the Windows 7 installation. But, for goodness sake, to make sure you don't introduce yourself to any worlds of new hurt, don't even think of trying that before making your backup. I know that such a task may be an annoyance (especially of money needs to be spent), but I'm re-stressing that issue because sometimes backups are even more worthwhile to make than average, and this is one of those times. So, I strongly advise you to do the wise thing, which is to make that investment in time/energy/supplies before any further mucking.

Answer 3

The partition types seem to be out of whack. Before proceeding, get a good backup with a bit-for-bit backup program like the CloneZilla boot disk, and then try editing the MBR. You didn't specify what type of partition your 128 MB was supposed to be, but you can try setting it manually. If you know what the partition type is supposed to be, you can use DISKPART's SET ID command to set the hexadecimal partition type manually. Wikipedia has a list of partition types. Common ones are 07 for NTFS, 0C for most FAT32, 06 for FAT.

You may be better off starting with TestDisk, which is made for recovering partition tables. It can automatically detect many types of MBR problems. You still may have to follow through with bcdboot and bootrec, but it should get you to a workable starting point.