I am looking to convert an existing dual boot TW/W10 installation which is working well with MBR but which I want to convert. There is already an efi partition installed by windoze so it should not be an issue but what do I do to retain my data. I might at the same time change /home partition from xfs to ext4 for compatibility reasons.
Any advice help would be appreciated.
Budge
I maybe wrong, but when you have an MBR partitioned disk, you probably have MBR booting… I am not sure who put an EFI partition (with contents?) there, but that seems a useless thing then to me.
I am not sure if GPT disks are compatibel with MBR booting, thus you may have to switch to EFI booting also.
It is also unclear if your hardware supports EFI booting. Did you check?
When the hardware is capable, take into account that only one type of booting can be used, thus you have also to “convert” (re-install?) your Windows.
Also, I would never do several conversions that are not realy bound together in one go. Thus the /home action (for compatiblity reasons? compatible with what?) would for me be a separate thing. Except when you decide to do it all over again and install Windows and openSUSE fresh.
For me the whole question is realy, why do you want to do this? You need more partitions then supported by MBR partitioning? Or what is the problem?
I have an external drive with MBR partitioning, and I have added an EFI partition. That’s so I can boot it on a UEFI system. It is currently set to be bootable on both UEFI and BIOS/MBR systems.
I did consider repartitioning to GPT for this. And I still might. This was originally an internal drive of a computer that is now dead, so I took the easiest path.
I am not sure if GPT disks are compatibel with MBR booting, thus you may have to switch to EFI booting also.
Yes, they are. There is still an MBR (or PMBR – protective MBR) that allows the disk to be used as if it were using MBR/DOS partitioning. It boots fine with linux, but Windows probably won’t like it. I think there’s a way of using hybrid partitioning that can work with Windows.
A general comment to the OP. If you plan of changing “/home” from “xfs” to “ext4”, then you need to backup, reformat and then restore. As long as you are doing that, you might as well backup all Windows data, too, and then reinstall Windows for UEFI booting.
“Yes” for Linux, “No” for Windows.
To OP: “backup + full reinstallation + restoring user’s data” is the best way IMHO.
It’s possible to convert 64 bit Windows 10 from legacy to EFI boot keeping data. Google for mbr2gpt.
Show what you have and tell what you plan to do:
erlangen:~ # **fdisk -l**
Disk /dev/sda: 3.65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EZRX-22S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 27C8C52A-8091-403C-ADF1-E9C791667D40
Device Start End Sectors Size Type
/dev/sda1 67119104 134223871 67104768 32G Linux filesystem
/dev/sda2 16384 67119103 67102720 32G Linux filesystem
/dev/sda3 7757789184 7814037134 56247951 26.8G Linux filesystem
/dev/sda4 134223872 7757789183 7623565312 3.6T Linux filesystem
Partition table entries are not in disk order.
Disk /dev/sdb: 465.78 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 850
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: gpt
Disk identifier: 90C1973B-4A41-4E96-85BA-B7358EA77CCC
Device Start End Sectors Size Type
/dev/sdb1 2048 208895 206848 101M EFI System
/dev/sdb2 208896 63119359 62910464 30G Linux filesystem
/dev/sdb3 63119360 126033919 62914560 30G Linux filesystem
/dev/sdb4 126033920 638033919 512000000 244.1G Linux filesystem
/dev/sdb5 852088832 976773119 124684288 59.5G Linux filesystem
/dev/sdb6 793495552 852088831 58593280 28G Linux filesystem
/dev/sdb7 638033920 700948479 62914560 30G Linux filesystem
/dev/sdb8 700948480 734502911 33554432 16G Linux swap
/dev/sdb9 734502912 793495551 58992640 28.1G Linux filesystem
Partition table entries are not in disk order.
Disk /dev/nvme0n1: 476.96 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: Samsung SSD 950 PRO 512GB
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: gpt
Disk identifier: A84F222E-0177-499B-A7EA-BDA6F31E2196
Device Start End Sectors Size Type
/dev/nvme0n1p1 206848 67102719 66895872 31.9G Linux filesystem
/dev/nvme0n1p2 67102720 134207487 67104768 32G Linux filesystem
/dev/nvme0n1p3 134207488 1000214527 866007040 413G Linux filesystem
/dev/nvme0n1p4 2048 206847 204800 100M EFI System
Partition table entries are not in disk order.
erlangen:~ #
erlangen:~ # **lsblk -f**
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1 ext4 Manjaro fad3604b-5a61-4653-8c14-518d850400ba
├─sda2 ext4 Leap-15.1 57bdbf64-b309-477c-b94c-8987e0c8032a
├─sda3 ext4 42f23f3c-9ff6-46f6-a9d9-6894062c37d7
└─sda4 ext4 Home-HDD f5177cae-4082-44ed-9471-b99030f06866 2T 44% /home-HDD
sdb
├─sdb1 vfat 4A24-B10D 92.8M 8% /boot/efi
├─sdb2 ext4 ArchLinux 690b51d7-7034-4585-b362-615f8056be45
├─sdb3 ext4 SLED 492c5d5e-5d9b-4a99-9d34-e1f9cee09fe9
├─sdb4 ext4 Home-SSD f4c5463f-f43d-420a-a0ea-4456cfbc54fa
├─sdb5 btrfs Tumbleweed 204f7d0f-979a-41e1-a483-a597d0357e0b 41.7G 28% /
├─sdb6 ext4 Ubuntu 9a3eec78-dd20-44c0-a38a-f705b3bbbc66
├─sdb7 ext4 Manjaro-SSD bf6ba7c9-9068-4a9b-b210-84b6d105df5c
├─sdb8 swap af61291c-64ee-4c0a-85dd-275ca2ef89db [SWAP]
└─sdb9 btrfs TW-20200416 0223afc3-6440-4fb9-86fd-cae6d5f24dad 23G 18% /mnt
nvme0n1
├─nvme0n1p1 ext4 Fedora 6fe43319-8566-4a09-9d2d-fcf8c104671f
├─nvme0n1p2 ext4 Tumbleweed 8b190950-c141-4351-9198-7a9592b4fb34
├─nvme0n1p3 ext4 Home 704621ef-9b45-4e96-ba7f-1becd3924f08 156.3G 61% /home
└─nvme0n1p4 vfat 6DEC-64F9
erlangen:~ #
Mixing BIOS/MBR and GPT/UEFI in the same PC can work. In similar vein to karlmistelberger:
# fdisk -l /dev/sda /dev/sdb /dev/nvme0n1
Disk /dev/sda: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: ST1000DM003-1CH1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xc22068fb
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 518143 516096 252M 6 FAT16
/dev/sda2 518144 5433343 4915200 2.4G 17 Hidden HPFS/NTFS
/dev/sda3 * 5433344 6252543 819200 400M 83 Linux
/dev/sda4 6252544 1953523711 1947271168 928.5G 5 Extended
/dev/sda5 6252576 6254591 2016 1008K 1 FAT12
/dev/sda6 6254624 6770687 516064 252M 6 FAT16
/dev/sda7 6770720 23564287 16793568 8G 82 Linux swap / Solaris
/dev/sda8 23564320 42739711 19175392 9.1G fd Linux raid autodetect
/dev/sda9 42739744 79603711 36863968 17.6G fd Linux raid autodetect
/dev/sda10 79603744 116467711 36863968 17.6G fd Linux raid autodetect
/dev/sda11 116467744 153331711 36863968 17.6G fd Linux raid autodetect
/dev/sda12 153331744 190195711 36863968 17.6G fd Linux raid autodetect
/dev/sda13 190195744 198387711 8191968 3.9G fd Linux raid autodetect
/dev/sda14 198387744 202483711 4095968 2G fd Linux raid autodetect
/dev/sda15 202483744 509683711 307199968 146.5G fd Linux raid autodetect
/dev/sda16 509683744 990963711 481279968 229.5G fd Linux raid autodetect
/dev/sda17 990963744 1953523711 962559968 459G fd Linux raid autodetect
Disk /dev/sdb: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: ST1000DM003-1CH1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xdf5ee123
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 518143 516096 252M 6 FAT16
/dev/sdb2 518144 5433343 4915200 2.4G 17 Hidden HPFS/NTFS
/dev/sdb3 * 5433344 6252543 819200 400M 83 Linux
/dev/sdb4 6252544 1953523711 1947271168 928.5G 5 Extended
/dev/sdb5 6252576 6254591 2016 1008K 1 FAT12
/dev/sdb6 6254624 6770687 516064 252M 6 FAT16
/dev/sdb7 6770720 23564287 16793568 8G 82 Linux swap / Solaris
/dev/sdb8 23564320 42739711 19175392 9.1G fd Linux raid autodetect
/dev/sdb9 42739744 79603711 36863968 17.6G fd Linux raid autodetect
/dev/sdb10 79603744 116467711 36863968 17.6G fd Linux raid autodetect
/dev/sdb11 116467744 153331711 36863968 17.6G fd Linux raid autodetect
/dev/sdb12 153331744 190195711 36863968 17.6G fd Linux raid autodetect
/dev/sdb13 190195744 198387711 8191968 3.9G fd Linux raid autodetect
/dev/sdb14 198387744 202483711 4095968 2G fd Linux raid autodetect
/dev/sdb15 202483744 509683711 307199968 146.5G fd Linux raid autodetect
/dev/sdb16 509683744 990963711 481279968 229.5G fd Linux raid autodetect
/dev/sdb17 990963744 1953523711 962559968 459G fd Linux raid autodetect
Disk /dev/nvme0n1: 111.81 GiB, 120034123776 bytes, 234441648 sectors
Disk model: MKNSSDPL120GB-D8
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: gpt
Disk identifier: 5E153119-128A-4DF5-81AC-5B6AFB848982
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 657407 655360 320M EFI System
/dev/nvme0n1p2 657408 3682303 3024896 1.5G Linux swap
/dev/nvme0n1p3 3682304 4501503 819200 400M Linux filesystem
/dev/nvme0n1p4 4501504 12693503 8192000 3.9G Linux filesystem
/dev/nvme0n1p5 12693504 25800703 13107200 6.3G Linux filesystem
/dev/nvme0n1p6 25800704 51605503 25804800 12.3G Linux filesystem
/dev/nvme0n1p7 51605504 67989503 16384000 7.8G Linux filesystem
/dev/nvme0n1p8 67989504 84373503 16384000 7.8G Linux filesystem
/dev/nvme0n1p9 84373504 100757503 16384000 7.8G Linux filesystem
/dev/nvme0n1p10 100757504 117141503 16384000 7.8G Linux filesystem
/dev/nvme0n1p11 117141504 133525503 16384000 7.8G Linux filesystem
/dev/nvme0n1p12 133525504 149909503 16384000 7.8G Linux filesystem
/dev/nvme0n1p13 149909504 166293503 16384000 7.8G Linux filesystem
/dev/nvme0n1p14 166293504 182677503 16384000 7.8G Linux filesystem
/dev/nvme0n1p15 182677504 199061503 16384000 7.8G Linux filesystem
/dev/nvme0n1p16 199061504 215445503 16384000 7.8G Linux filesystem
# lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1 vfat 1R1DOSBOOT 110A-1517
├─sda2 hpfs 1TT-P02 1233-2400
├─sda3 ext2 realboot1r1 b06ea19f-4871-4cfa-bfea-e572014ed258
├─sda4
├─sda5 vfat 1R1-DUMMY 15A9-6400
├─sda6 vfat 1R1DOSDATA 16B4-A400
├─sda7 swap 1r1swapper 71d2712f-aa40-4645-adb5-cef2742fc5f2
├─sda8 linux_raid_member srv10:md-tmp 4c61a0df-ccc3-b9aa-bac1-1bb0f06e62e6
│ └─md0 ext4 1md08tmp 6c97e113-1f41-463e-953b-7a8b1bfc0886
├─sda9 linux_raid_member srv10:mdroot1 d0ef38d5-1a18-ccdd-3fc4-1f945b274f89
│ └─md1 ext4 1md09root1 775affb1-91d4-4dfe-a695-7f0c0face3b9
├─sda10 linux_raid_member srv10:mdroot2 c37e5de4-f454-e44b-afe2-6e50d920a464
│ └─md2 ext4 1md10root2 814edd75-78e4-49d8-a6c6-679b4940b19e
├─sda11 linux_raid_member srv10:mdroot3 b094eaa5-ab63-fb5c-f6bc-aadfaecea6f4
│ └─md3 ext4 1md11root3 ab936b4e-dada-48de-9a45-ae6d2b47c5a6
├─sda12 linux_raid_member srv10:mdroot4 55772ab3-06e0-5ee3-7157-54c1487eb292
│ └─md4 ext4 1md12root4 8e61b64f-708e-409e-bcaf-99621b1b0d9a
├─sda13 linux_raid_member srv10:md-srv 99d94eec-d5c9-46e8-4e45-fddb9a0eebaf
│ └─md5 ext4 1md13srv 36c2d6f1-a114-482a-8617-5cad3afda0c2
├─sda14 linux_raid_member srv10:md-usrl 919df05c-6eb9-ee7c-9b2e-7c317cd17bef
│ └─md6 ext4 1md14usrl d39e9aec-3fa0-4148-a8ec-d3e4efbfe42a
├─sda15 linux_raid_member srv10:md-home 99e63933-08e7-51a8-696e-aad01fad1e7e
│ └─md7 ext4 1md15home 2e3de98b-ed32-4224-8761-a954d2e0ae27
├─sda16 linux_raid_member srv10:md-pub f825559b-7ce3-3628-4132-a23f94e7e48a
│ └─md8 ext4 1md16pub c492da5a-30b9-4335-98b3-b5ca996fee79
└─sda17 linux_raid_member srv10:md-isos 637f3edb-481a-886a-6003-6ac3eccef62f
└─md9 ext4 1md17isos beb5f47e-7db2-47c8-8da4-2cf5ac49422f
sdb
├─sdb1 vfat 1R2DOSBOOT 210A-1517
├─sdb2 hpfs 1TT-P02 2233-2400
├─sdb3 ext2 realboot1r2 3d6faecb-77e1-4866-b9af-29b4fdd5eb78
├─sdb4
├─sdb5 vfat 1R2-DUMMY 25A9-6400
├─sdb6 vfat 1R2DOSDATA 26B4-A400
├─sdb7 swap 1r2swapper 9dbb8c3a-bb2c-49a7-8cdf-85b4dcfd40d1
├─sdb8 linux_raid_member srv10:md-tmp 4c61a0df-ccc3-b9aa-bac1-1bb0f06e62e6
│ └─md0 ext4 1md08tmp 6c97e113-1f41-463e-953b-7a8b1bfc0886
├─sdb9 linux_raid_member srv10:mdroot1 d0ef38d5-1a18-ccdd-3fc4-1f945b274f89
│ └─md1 ext4 1md09root1 775affb1-91d4-4dfe-a695-7f0c0face3b9
├─sdb10 linux_raid_member srv10:mdroot2 c37e5de4-f454-e44b-afe2-6e50d920a464
│ └─md2 ext4 1md10root2 814edd75-78e4-49d8-a6c6-679b4940b19e
├─sdb11 linux_raid_member srv10:mdroot3 b094eaa5-ab63-fb5c-f6bc-aadfaecea6f4
│ └─md3 ext4 1md11root3 ab936b4e-dada-48de-9a45-ae6d2b47c5a6
├─sdb12 linux_raid_member srv10:mdroot4 55772ab3-06e0-5ee3-7157-54c1487eb292
│ └─md4 ext4 1md12root4 8e61b64f-708e-409e-bcaf-99621b1b0d9a
├─sdb13 linux_raid_member srv10:md-srv 99d94eec-d5c9-46e8-4e45-fddb9a0eebaf
│ └─md5 ext4 1md13srv 36c2d6f1-a114-482a-8617-5cad3afda0c2
├─sdb14 linux_raid_member srv10:md-usrl 919df05c-6eb9-ee7c-9b2e-7c317cd17bed
│ └─md6 ext4 1md14usrl d39e9aec-3fa0-4148-a8ec-d3e4efbfe42a
├─sdb15 linux_raid_member srv10:md-home 99e63933-08e7-51a8-696e-aad01fad1e7e
│ └─md7 ext4 1md15home 2e3de98b-ed32-4224-8761-a954d2e0ae27
├─sdb16 linux_raid_member srv10:md-pub f825559b-7ce3-3628-4132-a23f94e7e48a
│ └─md8 ext4 1md16pub c492da5a-30b9-4335-98b3-b5ca996fee79
└─sdb17 linux_raid_member srv10:md-isos 637f3edb-481a-886a-6003-6ac3eccef62f
└─md9 ext4 1md17isos beb5f47e-7db2-47c8-8da4-2cf5ac49422f
sr0
nvme0n1
├─nvme0n1p1 vfat PI3P01ESP 20A0-1003 298.4M 7% /boot/efi
├─nvme0n1p2 swap pi3p02swap b870efcb-073c-4b72-9e8b-59cc7ee89135 [SWAP]
├─nvme0n1p3 ext2 pi3p03res 26b718d5-68a0-4e97-bc97-fd227bfba9c1 143M 63% /disks/res
├─nvme0n1p4 ext4 pi3p04usrlcl d2f725ff-edbf-420d-a4e3-c6f540e9dc66 2.5G 34% /usr/local
├─nvme0n1p5 ext4 pi3p05home b6bbcea2-4741-4b94-9017-7f46273ea730 5.5G 9% /home
├─nvme0n1p6 ext4 pi3p06pub 0941d25f-4cce-41d4-af9f-033ad02019cb 6.1G 49% /pub
├─nvme0n1p7 ext4 pi3p07stw 00600ad5-1528-4a3b-9316-28e0176ed29d 1.3G 78% /
├─nvme0n1p8 ext4 pi3p08s150 6cc3dcad-4931-4c6b-8d59-ceaeb8a35cd0 1G 82% /disks/s150
├─nvme0n1p9 ext4 pi3p09s151 a185c6d5-89b3-4faf-8067-ff2ea9148c11 1.3G 78% /disks/s151
├─nvme0n1p10 ext4 pi3p10deb11 a6ea354a-93d6-4efa-88cd-e08feb4afa66 4.2G 40% /disks/deb11
├─nvme0n1p11 ext4 pi3p11s152 c4a4124f-faf1-4656-9a58-32ed3f838a4a 3.6G 49% /disks/s152
├─nvme0n1p12 ext4 pi3p12Ufocal 8de12c07-a9ce-45e5-aa65-d00e61070c29 2.7G 59% /disks/ubu20
├─nvme0n1p13 ext4 pi3p13deb10 11a70069-54ed-4d03-a34a-1648d46c3c1d 4G 43% /disks/deb10
├─nvme0n1p14 ext4 pi3p14Ubionic 3f2e7468-aea8-4c11-994b-19d5f5ccb03f 1.2G 79% /disks/ubu18
├─nvme0n1p15
└─nvme0n1p16
For Windows:
- CSM BIOS + MBR
or
- EFI + GPT
It is better to use GPT with a new installations.
Having read the help here which is much appreciated I have concluded that I shall offload my Tumbleweed partitions onto another computer whether by copying or using a tool such as gparted. This will leave me with a simple Windoze installation which I can then convert to GPT.
One supplementry question, if I do the MBR>GPT conversion does the UEFI partition get created at the same time by the conversion tool? My BIOS already works with either MBR or UEFI so I do not think I shall have BIOS issues.
I shall post the results from fdisk -l and lsblk -f when I am at the machine and seek confirmation that all is as it should be before I start.
On further reflection I agree this is the best way forward.
Forgive the simple question but if I am backing up from all the various file systems onto a backup and then wish to restore onto slightly different file systems, for example changing MBR to DPT and xfs to ext4, what is the right way to proceed and how will the restored system know what to look for?
I will not clearly be doing a low level clone as I would with gparted but what backup application should I use?
With Dual Boot do I have to be in the appropriate OS to create the backups if not using low level tool.
Just concerned as there are so many options and idiots guide would be appreciated by this idiot!
Will send disk info later as I am at different machine now.
Regards
When I understand you correctly, then you want to transfer your files to new file systems (and I would do likewise). That can not be done with “cloning”. You must copy your files and then copy them back later. You could do so e.g. by gathering all in a file system with tar. Unpacking them on the new file system will then ggive them all back.
Hi Henk,
Understood but I therefore assume I must be in the appropriate OS in order to copy. I have two concerns:-
Windoze is full of hidden rubbish and restrictions and I will have to research which tool to use for that OS.
I am more sanguine about Tumbleweed but am not sure how I backup and restore the OS and boot details so that when I have restored everything it will work. Home directory no problem.
One step at a time and I am still waiting for some new hardware.
Thanks for the reassurance.
Regards,
Budge
That is OK then. I was afraid that you would overwrite your new filesystem with a clone of the old one. Whne you understand that, it is OK.
I can not say anything useful about Windows. And that makes life a lot more relaxed. 
In essence all that is really important is your data. In Linux that is is normally in /home. For programs just go to Yast and install the programs you need. In Windows you must also consider purchased programs( you don’t want to buy again 
) So you need the installer used for each and the data you have accumulated.
If copying raw files be careful copying to MS file systems since they don’t support Linux attributes. You can tar the data which can persevere ownership info and also reduce storage.
Going slowly. Thought I would make a partition on another laptop using live boot of gparted as my tool of choice in order to receive backup files from other systems.
Not any more it seems. Tried to boot USB of gparted and bumped into opensuse secure boot. Now this is what should happen but what I didn’t check is how do you boot a live USB of anything now we have UEFI and secure boot?
Of course I shall now look it up but thought I had better ask as I am on the relevant (secured) machine now.
Budge
It should work with openSUSE, Fedora, Ubuntu and several other distros. But for some distros, you need to turn off secure-boot before you can boot live media.
Both openSUSE and Fedora may prompt you on first boot, to agree to using their certificate. I don’t think Ubuntu is currently doing that.
It is clear that my new installation of Tumbleweed dual booted with windoze on GPT drive all works fine but I now cannot boot a live distro or anything else. How many I turn off the secure boot when booted to my TW system? Surely I do not need to go to the dark side to do this?
Budge.
Turning off secure-boot should be a BIOS setting.
Hmm, there’s a possibility that you have a different problem, but are explaining it poorly.
You could try editing “/etc/default/grub” (as root), and look for the line:
GRUB_USE_LINUXEFI="true"
and change that “true” to “false”.
After that, you need to update the grub menu with:
grub2-mkconfig -o /boot/grub2/grub.cfg