Home / ubuntu / Questions / 926623
Accepted
Aero Windwalker
Asked: 2017-06-18 20:31:25 +0800 CST

How to mount Windows (NTFS) system MBR when using USB to boot?

  • 772

I had an older computer with Windows XP system set up as such:

c:\
d:\
e:\
f:\
?:\ backup disk

I wanted to install Windows 10 to this computer and I removed c:\ (because it didn't let me format it, I didn't know Windows 10 cannot be installed to a MBR system) and now it is 50GB of unalloc space.

What I am trying to do with Ubuntu is to backup my data in d:\, e:\, f:\, but after I boot into the system I see only /dev/sda1 and /dev/sda2, and the latter is the backup disk in FAT 32 (LBA) format. With sudo fdisk -l I can see /dev/sda1 is in unknown format. And if I use:

sudo ntfs-3g /dev/sda1 /mnt/windows OR sudo mount -t ntfs-3g /dev/sda1 /mnt

The terminal will return NTFS signature is missing error...

(Same goes for /dev/sda, meaning mounting the entire disk)

If I use sudo gdisk -l /dev/sda it will say exact type match not found for type code 1F00.

With sudo lsblk -f I get:

loop0 squashfs /rofs
sda
 sda1
 sda2 vfat sys_bak 3e28-1cab

With sudo lsblk -m I get:

loop0 1.5G root
sda 931.5G root
 sda1 877.8G root
 sda2 4.9G root

With sudo parted -ls I get:

Model: ATA WDC WDXXX(scsi)
Disk /dev/sda: 1000GB
Selector size (logical/physical): 512B/4096B

Partition Table: msdos
Disk Flags:

Number Start End Size Type File System Flags
1 52.4GB 995GB 943GB primary null null null
2 995GB 1000GB 52440MB primary fat32 null boot, lba

With df -h I get nothing related to /dev/sda

boot

1 Answers

  1. Best Answer

    Windows 10 can be installed in BIOS/CSM/legacy mode. The trick is controlling the boot mode. Even with the CSM enabled in the firmware, with most computers there's no guarantee that the system will actually boot in BIOS mode; it might boot in EFI mode, depending on the algorithms used by the firmware to decide how to boot and the actions taken by the user at boot time. See this page of mine for more on this topic. This issue is largely moot, though....

    Based on your parted output, it appears that your partition table is badly damaged. My suspicion is that your disk originally used the Windows Logical Disk Manager (LDM), aka "dynamic disks." This system is similar to Ubuntu's Logical Volume Manager (LVM), but the two systems are incompatible with one another. In both cases, regular partitions are combined together into what's known (in the LVM case) as a volume group (VG), and the VG is in turn broken down again into logical volumes (LVs). This may sound pointless, but it adds flexibility. Windows seems to do it mainly to gain the ability to store more than four volumes (LVs) on an MBR disk, which is limited to four primary partitions. The older solution to this problem, which Ubuntu still commonly employs, is to use logical partitions -- which are different from LVs, despite the similar names! Logical partitions show up as partitions stored inside an extended partition is partitioning tools like GParted and fdisk. These tools can't cope with an LDM configuration, though; they show the underlying MBR partitions, not the LVs they ultimately house.

    In your question, you note that the disk had four or five "drives" (partitions) in Windows -- you specify C:, D:, E:, F:, and "?:" ("backup disk"). If by that last one you mean a fifth partition with a drive letter you don't remember, then chances are Windows would have used LDM to set them up. There's a good chance that GParted would lead you to believe, incorrectly, that the first LDM partition was C:. Thus, you deleted the first LDM partition, not C:; and with the first LDM partition gone, everything in the LDM was compromised. By chance, your /dev/sda2 appears to be FAT32, so it might hold an intact FAT32 filesystem.

    My recommendation for recovery is:

    1. If possible, do a low-level backup of the entire disk. For instance, sudo dd if=/dev/sda of=/path/to/lots/of/space/sda.img bs=4096. This command backs up /dev/sda to sda.img on some other device. (You'd have to mount it somewhere and specify the path to that device as part of the of= option.) The point of this step is that the rest of the procedure could make matters worse, so you'll be able to restore everything to a bad (but better) state if that happens.
    2. Using fdisk or parted, delete the partitions on /dev/sda.
    3. Using TestDisk, search for filesystems on the disk and restore them.

    With any luck, TestDisk will be able to create a new partition table that will give you access to your filesystems. It will do so without using LDM, and the result might not be bootable; but at least there's a good chance that you'll be able to recover your data, delete the real C:, and then install Windows 10 or Ubuntu to the disk.

    Returning to the question of boot mode, it sounds like your computer booted the Windows 10 installer in EFI mode. As such, you might want to tell TestDisk to use GPT for its restored partitions. I'm not sure exactly how to do this offhand, though. If you can't figure it out, don't worry too much about it; an alternative is to restore partitions as MBR and then do an MBR-to-GPT conversion with gdisk. Either way, the point is to have a GPT disk with empty space on it so that Windows can install in EFI mode. The alternative is to get to the point where you've got an MBR disk and figure out how to boot the Windows installer in BIOS mode. This may cause another MBR-to-LDM conversion, though, which might cause future problems should you decide to dual-boot with Linux.

    If you decide to do an all-out conversion to Ubuntu, rather than install Windows 10, be aware that using NTFS on an Ubuntu-only computer is unwise. The trouble is that there are no good NTFS maintenance tools for Ubuntu. Thus, when (not if) an NTFS volume needs repair, you'll have to jump through extra hoops. If you go for an Ubuntu-only installation, you should back up your NTFS data partitions, convert them to Linux-native forms, and restore your data to them.

    • 0