Convert GPT Partition to MBR
Solved
lenainjaune Posted messages 726 Registration date Status Contributeur Last intervention -
Hello everyone :D,
What is the right method to convert a Debian partition to Ext4 format from a device with a GPT partition table on a machine with EFI in order to integrate it onto an MBR disk for use on a machine with BIOS?
I have tested many different methods without success.
Eventually, I succeeded by developing my own method (see below) :D but I have an unexplained latency from the kernel at startup and I'm not convinced that there are no other side effects...
---
To set it up successfully, I mirrored the files from the Debian partition on the device using rsync to an Ext4 partition on a disk that uses an MBR partition table. Once done, I attempted to install the GRUB bootloader with grub-install ... without success. As at startup the system got stuck on grub rescue>, I tried the boot-repair-disk tool which globally repaired it (I can provide the log) and made it functional.
Note: in reality, my first attempt resulted in a read-only system, which I was able to correct by updating in /etc/fstab the identifier of the partition to be mounted at startup determined by blkid; also from this same file, I had to disable the memory swap file SWAP which pointed to a non-existent partition since it was not cloned, to recreate it afterwards.
Remark: I have deliberately kept the explanations to a minimum, but I can definitely elaborate on any point.
---
I don't know if I'm clear enough...
On the other hand, I have other questions about the difference between GPT and MBR.
If someone can spare a bit of their time to help me, that would be really cool :D!
With brotherhood,
lnj
I have questions about all your answers. (Woody Allen)
Knowledge and ideas belong to everyone (noosphere)!
4 réponses
On the other hand, I'm not sure if you read my question just before, which was addressed to you :D
So I suppose the question you are referring to is "Even for the /boot folder and grub?" #12
Short answer
In fact, we need to distinguish two things:
- what we configure ourselves (and where we don't care about MBR or GPT)
- what GRUB does on its own in the background, which will impact the final file /boot/grub/grub.cfg and in which we can see variations depending on whether we use GPT or MBR.
The consideration of GPT or MBR is specific to the partition table (defined at the beginning of the disk, and responsible for defining each partition hosted by the disk - size, position, file system). Thus, this information resides in the header of the hard drive and outside of its data partitions.
Detailed answer
If we open /boot/grub/grub.cfg, we see that when using GPT, there are lines "insmod part_gpt" which load the GRUB module (it's not related to a kernel module, we're before the kernel is loaded when we're in grub). This module allows GRUB to read GPT partitions.
So the question we can ask is how GRUB did it. As indicated at the beginning of /boot/grub/grub.cfg, this file is generated by the command:
sudo update-grub
This command is implicitly called every time you install or uninstall a new kernel (and therefore, particularly, when you installed Linux or during certain updates).
If we look at the content of /usr/sbin/update-grub (you can find the path of the executable with sudo which update-grub), we see that this script calls grub-mkconfig. The latter is based on:
- GRUB configuration file skeletons (see /etc/grub.d/);
- the configuration file /etc/default/grub (the only place where we're supposed to intervene);
- possible extensions in /etc/default/grub.d defined in /etc/default/grub.d/.
In this case, /boot/grub/grub.cfg clearly states that many "insmod part_gpt" are due to the skeletons defined in /etc/grub.d/. So that's where we're going to dig. We open an arbitrary one and at the beginning we find the instruction:
# Include the GRUB helper library for grub-mkconfig. . /usr/share/grub/grub-mkconfig_lib
It is this auxiliary script that generates the inmod part_gpt instructions that ultimately appear in /boot/grub/grub.cfg. Indeed, if we open /usr/share/grub/grub-mkconfig_lib, we see:
partmap="`"${grub_probe}" --device $@ --target=partmap`" for module in ${partmap} ; do case "${module}" in netbsd | openbsd) echo "insmod part_bsd";; *) echo "insmod part_${module}";; esac done This code snippet shows that grub-probe (i.e. /usr/sbin/grub-probe) determines which modules are necessary for the proper functioning of GRUB (in particular, part_gpt for GPT disks) are necessary.
If the question now is how GRUB makes the distinction, it is quite simply the same way as fdisk & co, by looking at how the partition table of your hard disks is defined.
If you want to go even further and see how it is implemented, you would need to look at the code that generated the executable /usr/sbin/grub-probe and as it is a binary, you need to look at its source code (or that of a disk partitioning tool) or the relevant specifications, which are presented on the Wikipedia page on GPT. It particularly shows that the information indicating "GPT or not" is outside of the partitions (which is quite normal, since these considerations are specific to the partition table responsible for defining the partitions.)
Good luck
Well, I managed to convert a disk partition from a GPT partition table to MBR
=> solved! Celebration :D !
For what purpose? To be able to isolate a problematic Debian system on a physical machine for p2v testing it in a virtual machine (here with Qemu/KVM/libvirt).
I am sharing my native method here, which does not use the tool boot-repair-disk and which is certainly not the academic or desirable way, but that works in my case.
Consequently, I cannot guarantee that it will work in another case and/or on another machine and/or with another operating system and/or another virtualization architecture.
---
Conditions of my test:
- NVM Express support GPT partition table 120GB on EFI machine
- system to isolate Debian 12, 12/20GB free
- Qemu/KVM v5.2.0 and libvirtd v7.0.0
For the latency problem mentioned at the beginning, see the resolved thread: Kernel latency at startup
SUPPORT_SOURCE_GPT=/dev/nvme0n1 SUPPORT_VIRTUEL_SOURCE_GPT=/dev/nbd0 SUPPORT_VIRTUEL_FINALE_MBR=/dev/nbd1 IMAGE_SOURCE_GPT=image_source_gpt.qcow2 IMAGE_FINALE_MBR=image_final_mbr.qcow2 PARTITION_ISOLEE_VIRTUELLE_SOURCE_GPT=\ $( echo ${SUPPORT_VIRTUEL_SOURCE_GPT}p5 ) # Note: to know the partition number see details # of the images # Attention: NVME and NBD supports are identified by # numbers that are not partition numbers # (e.g. /dev/sda5 would correspond to /dev/nbd0p5) # Cloning the NVME support into an image file (p2v) dd if=$SUPPORT_SOURCE_GPT of=$IMAGE_SOURCE_GPT \ bs=64K conv=noerror,sync status=progress #> 128019136512 bytes (128 GB, 119 GiB) copied, 1123 s, 114 MB/s #> 1953669+1 records read #> 1953670+0 records written #> 128035717120 bytes (128 GB, 119 GiB) copied, 1124.81 s, 114 MB/s # Test if the NBD module is active lsmod | grep -c nbd #> 1 # => active # Activate NBD module if not active modprobe nbd max_part=8 # Load the source image into a virtual support qemu-nbd -f raw \ -c $SUPPORT_VIRTUEL_SOURCE_GPT $IMAGE_SOURCE_GPT # Create the final image (>= size of isolated partition files) qemu-img create -f qcow2 $IMAGE_FINALE_MBR 15G #> Formatting 'image_source_gpt.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib #> size=16106127360 lazy_refcounts=off refcount_bits=16 # Load the final image into a virtual support qemu-nbd -c $SUPPORT_VIRTUEL_FINALE_MBR $IMAGE_FINALE_MBR # Format the final image parted -a cylinder $SUPPORT_VIRTUEL_FINALE_MBR \ -s "mklabel msdos" parted $SUPPORT_VIRTUEL_FINALE_MBR \ -s "mkpart primary ext4 1 100%" lsblk -lpf \ --output NAME,TYPE,FSTYPE,SIZE \ $SUPPORT_VIRTUEL_FINALE_MBR \ | grep " part " #> /dev/nbd1p1 part 15G partition_virtuelle_finale_mbr=$( lsblk -lp $SUPPORT_VIRTUEL_FINALE_MBR \ | awk '/ part / { print $1 }' ) mkfs.ext4 -F $partition_virtuelle_finale_mbr #> mke2fs 1.46.2 (28-Feb-2021) #> Device block rejection: completed #> ... #> Backup superblocks stored on blocks: #> 32768, 98304, ... #> ... # Image detail lsblk -f \ --output NAME,TYPE,FSTYPE,SIZE,PARTLABEL \ $SUPPORT_VIRTUEL_SOURCE_GPT $SUPPORT_VIRTUEL_FINALE_MBR #> NAME TYPE FSTYPE SIZE PARTLABEL #> nbd0 disk 119.2G #> ├─nbd0p1 part vfat 100M EFI system partition #> ├─nbd0p2 part 16M Microsoft reserved partition #> ├─nbd0p3 part ntfs 69.8G Basic data partition #> ├─nbd0p4 part ntfs 536M #> ├─nbd0p5 part ext4 18.6G DEBIAN #> ├─nbd0p6 part swap 977M #> └─nbd0p7 part ext4 29.3G BACKUP #> nbd1 disk 15G #> └─nbd1p1 part ext4 15G # Synchronizing source support files -> final support mkdir -p mnt/{gpt,mbr} mount $PARTITION_ISOLEE_VIRTUELLE_SOURCE_GPT mnt/gpt/ mount $partition_virtuelle_finale_mbr mnt/mbr/ rsync -aP mnt/gpt/ mnt/mbr/ # => here the synchronization was completed in 8 minutes # References to the source disk UUID and SWAP file? # Note: UUID = Universally Unique IDdentifier uuid_gpt=$( blkid -s UUID -o value \ $PARTITION_ISOLEE_VIRTUELLE_SOURCE_GPT ) uuid_mbr=$( blkid -s UUID -o value $partition_virtuelle_finale_mbr ) uuid_swap=$( awk \ ' BEGIN { FS = "(=| +)" } ; '\ ' /^[^#].+ swap / { print $2 } '\ mnt/mbr/etc/fstab ) grep -rlE "$uuid_gpt|$uuid_swap" mnt/mbr/ \ | grep -Ev "/var/|\.log" #> mnt/mbr/etc/initramfs-tools/conf.d/resume #> mnt/mbr/etc/fstab #> mnt/mbr/boot/grub/x86_64-efi/grub.efi #> mnt/mbr/boot/grub/x86_64-efi/load.cfg #> mnt/mbr/boot/grub/x86_64-efi/core.efi #> mnt/mbr/boot/grub/grub.cfg # => resume (sleep), fstab (auto mounts), GRUB (booting) # Disable the sleep file sed -i 's/^\( *[^#]\)/# \1/' \ mnt/mbr/etc/initramfs-tools/conf.d/resume # Update the automatic mounts file fstab_gpt=$( sed -e 's/^\( *[^#]\)/# \1/' mnt/mbr/etc/fstab ) fstab_mbr=$( grep "$uuid_gpt" mnt/mbr/etc/fstab \ | sed "s/$uuid_gpt/$uuid_mbr/g" ) echo -e "$fstab_gpt\n\n# MBR Disk\n$fstab_mbr" \ > mnt/mbr/etc/fstab # Make the MBR support bootable grub-install --boot-directory mnt/mbr/boot \ $SUPPORT_VIRTUEL_FINALE_MBR #> Installation for the i386-pc platform. #> Installation completed, without error. # Update the hosts resolution file hosts_avant=$( sed -e 's/^\( *[^#]\)/# \1/' mnt/mbr/etc/hosts ) hostname_mbr=$( cat mnt/mbr/etc/hostname ) echo -e "$hosts_avant\n\n127.0.1.1\t$hostname_mbr" \ > mnt/mbr/etc/hosts # Modify the final system for f in /proc /sys ; do mount -B $f mnt/mbr$f ; done mount --rbind /dev mnt/mbr/dev/ chroot mnt/mbr/ # # Enter the chroot environment # # Disable SWAP loading at startup # (see CCM thread "Kernel latency at startup") # update-initramfs -u #> update-initramfs: Generating /boot/initrd.img-6.1.0-23-amd64 # # Update GRUB ... # ...without other local devices # https://unix.stackexchange.com/questions/634150/hide-devices-in-chrooted-environment/634655#634655 # chmod a-x /usr/bin/os-prober update-grub chmod a+x /usr/bin/os-prober exit # # Exit the chroot environment # for f in /proc /sys /dev ; do umount -lf mnt/mbr$f ; done # # At the startup of my VM, I got an error: # "unable to allocate pty: No such device" # https://askubuntu.com/questions/1449413/sudo-unable-to-allocate-pty-no-such-device/1503585#1503585 mount none -t devpts /dev/pts # Unmounting and unloading supports umount -l mnt/mbr umount -l mnt/gpt rmdir -p mnt/{gpt,mbr} qemu-nbd -d $SUPPORT_VIRTUEL_SOURCE_GPT #> /dev/nbd0 disconnected qemu-nbd -d $SUPPORT_VIRTUEL_FINALE_MBR #> /dev/nbd1 disconnected # Deactivate NBD module if not automatically activated rmmod nbd Hoping this can help others :D
With adelfity,
lnj
I have questions for all your answers. (Woody Allen)
Knowledge and ideas belong to everyone (noosphere) !
Hello,
On the other hand, I have other questions about the difference between GPT and MBR.
The GPT model addresses several limitations inherent to the MBR model, as explained here. That's why when you have the choice, GPT is always the better option. GPT is supported by Windows >= 7 and reasonably recent Linux.
The only case where GPT cannot be used (and therefore, where MBR is enforced) is for operating systems that are so old that they do not support GPT (Windows <= XP). More details here.
Even though I don't think it's a good idea, under Linux, you can use gdisk to convert from GPT to MBR, as explained here. Make sure to redeploy grub once the conversion is done, as explained here.
Good luck
Hello Mamiemando :D
In fact, I need to convert to MBR because I have to do a p2v from an EFI machine onto a medium that allows dual-boot Windows/Debian, with Windows requiring GPT, I believe (at least it is that way as it stands). Specifically, I need to virtualize Debian.
Also, until recently, libvirt virtualization did not support snapshots on GPT, and I need that (it’s changing since libvirt v10.1.0 and Virtual Machine Manager v4.1.0, but in an urgency, I'm not going to start reinstalling for that).
On Linux, you can use gdisk to convert from GPT to MBR, as explained here. Be sure to reinstall grub once the conversion is complete, as explained here.
I have already tested this method which executes without error BUT I end up with a disk that has a single partition taking up all the space. Well, technically I know that the data is still there, but it is not accessible, the MBR/EBR tables have broken their access.
Also, dual-boot support in GPT is partitioned into 7 partitions (4 for Windows 10, 1 for Debian, 1 for local backups, and the last one for Linux SWAP) => since MBR limits to 4 primary partitions, gdisk needs to know by itself which partitions to convert to primary and which ones to extended. I have also read that some systems (only Windows?) cannot boot from anything other than a primary partition.
Also
Hello,
On the other hand, I have other questions about the difference between GPT and MBR.
One of the questions I have and for which I can't find an answer is the difference at the system level (i.e., files), what differentiates a Debian installation on a machine with EFI from one with MBR?
I'm thinking that if I understand the difference, it might prevent me from having to use boot-repair-disk and possibly avoid the aforementioned side effects.
[...] it’s the difference at the system level (therefore files), what differentiates a Debian installation on a machine with EFI from one with MBR?
There is none, it’s at the partition table level that it plays out, neither at the level of the file systems themselves, nor regarding their content. As explained earlier, this will impact what you can do (e.g. maximum size of a partition). For an installed system, you will see minor differences in the results returned by tools like fdisk or gdisk and in the way your devices are indexed, but otherwise you won’t notice any.
it would save me from using boot-repair-disk and possibly not encountering the said side effects.
Regarding boot-repair, it is only useful for installing or reinstalling grub and is limited to that role. Therefore, it is an independent consideration from GPT or MBR. There are no side effects. Either grub is properly installed, or it is poorly installed :-)
Hello
this is the difference at the system level (that is to say, the files),
Yes, that's all you need to say, because the file system is "below" EFI or MBR, which are written on or inside this file system that is a "layer" over the hardware before the organization in MBR or EFI of the files and their location on disks through tables.
Between EFI and MBR, even the maximum size that the organization can handle differs, thus the EFI location table differs from that for MBR.
EFI also exempts itself from this limitation of 4 primary partitions.
Windows was initially created relying on the existence of the main MBR partition, (it sometimes uses it to prohibit access to the disks on which it is installed but that's another story; perhaps that’s why it sometimes refuses to install; Microsoft could lose a bit of control over its licenses, and it’s this control that sometimes ensures the promised security).
Note:
-Windows and Linux do not place the boot system in the same location, one can have both for a single disk in dual boot: the grub repair tool acts in its partition; the Windows repair tool in its own.
-It seems that grub knows how to repair itself and allows modifying a line afterwards to call Windows, which is a plus for the manager to modify its installations afterwards on the disk that has booted the system without shutting down the computer under Linux, more easily.
-The total 64-bit (disappearance of the 32-bit) is related, or EFI is imposed when it is present.
-I end up with a disk with a single partition,
EFI virtualizes partitions or disks, it manages the entirety of the disk and is capable of moving partitions or even creating them in several small pieces in different locations. Thus, everything is visible, it is indeed one large space for it.
In a VM, it is worse, everything is virtual and treated as a whole large space. [Let’s think of RAID, which is somewhat similar. There’s what we see, and there’s the physical, and we don't see the physical].
Ahah thanks :-) but I have no merit, I just read the code :D
In any case, for the help you provide me and others ... ;D
---
So I've made good progress and I'm about to give feedback on my method.
I managed to convert a partition from a GPT disk to MBR without using a repair tool :D
However, I still have the side effect mentioned earlier, namely about 30 seconds where nothing happens. The white cursor is blinking on a black background. Right after that come all the uninterrupted writings before reaching the welcoming screen (= greeter)
[rant=start]Recently, I decided to use French words more, not out of national identity (I feel like a citizen of Earth, period), but out of annoyance with the massive use of English/American for everything and anything ;D[rant=end]
So I did an audit on the activity after booting and I found that what takes time is the kernel. But I don't know how to dig deeper.
$ sudo systemd-analyze plot > analyse.svg
Without zooming in, we see a long gray bar at the top for 33s ...
... which is related to the kernel :
Could you help me understand what happens during these 33 seconds?
I have questions for all your answers. (Woody Allen)
Knowledge and ideas belong to everyone (noosphere)!
Difficult to say. Moreover, I think it would be worth starting a new discussion since it's unrelated to the initial question. I’m trying to answer quickly, but if you need more information, please start a new discussion.
- If the kernel is abnormally slow (compared to usual, on this machine), it's likely that one of its features has a problem and eventually times out.
- Try checking if the logs (/var/log) reveal anything, especially /var/log/boot.log or /var/log/kern.log if they exist. Any errors may help determine not only the cause but also how those who faced this issue managed to resolve it.
- This could be due to a bug. Sometimes some encounter issues with specific versions (see this discussion). Testing with other kernels (even older ones) would help see if this is what’s happening here.
- If the problem persists, you should "profile" the kernel (see for example this discussion). Unfortunately, this is cumbersome to implement, as whatever the method, you need to recompile the kernel (so instead of just deploying a pre-compiled one with a linux-image package, you'd need to recompile it as explained here).
Good luck
Indeed, even though the problem is completely related to this thread, it has its place in a new space.
I have therefore created this new thread: Kernel Latency at Startup ... to say that the problem is solved and to present my approach :D !
Furthermore, I don't know how to mark it as "resolved" since I am the one who resolved it!
My method for converting the GPT partition to MBR will follow ... in this thread ;D
Thanks, mamiemando! You will always amaze me with your knowledge :D!
Yes, so as I sync the content of my GPT partition to an MBR partition, grub.cfg being dedicated to GPT, during MBR boot the command will be executed and thus won't allow booting ... probably the "why" the system doesn't boot and forces me to repair with a tool like boot-repair-disk.
It's starting to become clearer ...
If the problem is solely due to this command, I'll have a good laugh at having wasted all this time ...
I'm doing tests and will provide feedback :D
Haha thanks :-) but I have no credit; I just read the code :D
Indeed, in your case, you need to redeploy GRUB. To do this, run from the Linux installed on your hard drive:
If your Linux is not bootable, you can get by with a tool boot-repair or a live CD that will allow you to do a chroot (to simulate a normal startup), and from there, redeploy GRUB. If you're not familiar with this kind of manipulation, I recommend using boot-repair which will guide you. And if you still can't manage, don't hesitate to ask for more details ;-)
Good luck