How to change GPT to MBR?

Solution 1:

Linux should have no problem accessing a second disk, partitioned with GPT, from a BIOS-mode boot on an MBR disk. The fact that you're having problems suggests something else is wrong, such as:

  • User error -- You don't say what you're doing to attempt to access the disk or what type of error message(s) you're seeing, so it's hard to judge if you're doing the right thing or making some mistake in your attempt. I suggest you edit your question to post more details about what you're doing.
  • Partition table damage -- Your partition table might be damaged in some way that's causing Ubuntu to object to it but that Windows takes in stride. You can type sudo sgdisk -v /dev/sdb (or change /dev/sdb to whatever the device file for the disk is) to run a basic partition table sanity check on the disk. This command will not modify the disk in any way; it will just report any problems it finds.
  • Filesystem damage or unsupported filesystem -- The partition table might be fine, but if the filesystem(s) used on the disk are damaged or of a variety that Ubuntu can't understand, you won't be able to read them. One particularly common problem with Windows 8 and later is in the Windows "Fast Startup" feature, which turns shutdown operations into suspend-to-disk operations. The result is that filesystems appear damaged to Ubuntu. The solution is to disable Fast Startup, as described here (among many other places). Note that the Windows Fast Startup feature is entirely separate from a firmware feature that often has a similar name.

If I had to lay a bet, I'd say that Fast Startup is your problem.

All that said, gdisk enables losslessly converting MBR to GPT or vice-versa, albeit with some caveats. See this gdisk documentation page for details. (Note: I'm the author of gdisk.) I mention this only in the interests of providing a direct answer to your question. I do NOT recommend doing this conversion, at least not unless and until you've better diagnosed your problem.


EDIT:

First, your GParted screen shot shows one normal partition (/dev/sda1) and another thing that is marked "не размечено." That translates as "not marked out," according to Google translate; but I suspect it's unallocated space (it would be marked as "unallocated" when run on a system that uses English). If I'm right in my interpretation, that's not a partition at all; it's just empty space. This is perfectly normal, although 129 MiB of free space is a bit much. Perhaps there was a partition there once but it was deleted.

Second, there's a little alert flag next to your /dev/sda1 in the GParted screen shot. These icons vary so much from one release to another that I can't be sure, but I suspect this icon exists to indicate filesystem damage. This is consistent with my hypothesis that your problem is caused by Fast Startup, which makes the filesystem look damaged in Ubuntu. I'm afraid I didn't quite understand what you were saying about Fast Startup in your second reply; we're hitting language barrier issues. All I can do is to reiterate that Fast Startup can and does cause problems, and you MUST disable it on Windows 8 and later if you expect to share filesystems between Windows and Linux. With Fast Startup enabled, you can select "shutdown" in Windows all you want and the system will not shut down in the conventional sense; it will go into a sleep mode in which the filesystem is in an inconsistent safe, and is therefore unsafe or impossible to use from any other OS.

Third, the sgdisk output you posted indicates that the secondary partition table overlaps the one and only partition on the disk. This is often caused by software ("fake") RAID issues. This can happen even on single-disk systems or on disks that have previously been used in RAID setups but that are now used by themselves, because of leftover RAID data. It could also be that the disk was copied from one that was slightly larger than the current one; depending on the copy method, the result could be a problem like what you're seeing. The output of sudo gdisk -l /dev/sda might help clarify what's going on.

I strongly recommend against doing anything that writes changes to the partition table at this point, because it's not clear what the problem is. Making permanent changes in ignorance runs a serious risk of making matters worse, so it's best to proceed with caution until you understand the cause of the problem.