Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop

On Mon, 11/10/2025 7:27 PM, Java Jive wrote:
> On 2025-10-31 12:56, Java Jive wrote:
>>
>> As per subject, as I now have on the same PC some OSs  -  Ubuntu24, Windows7/10  -  installed on an MBR disk and Windows 11 installed on a GPT/UEFI disk, I'd like if possible to find a way of booting any of them, and MBR/GPT USB sticks, without constantly having to change the BIOS settings on the PC.
>>
>> Research into whether this is possible seems to produce mixed results, mostly not, but a few suggesting it's possible, but I haven't yet found anything with clear and understandable instructions on how to achieve it.
>>
>> My own gut feeling is that it should be possible, but, while I have a good understanding of how a PC boots an MBR disk, I have less understanding how one boots a GPT/UEFI disk.
>>
>> Has anyone here been able to achieve this?  Does anyone know of good reliable sources of information about this?
> 
> Thanks for the earlier responses, I have now some success to report ...
> 
> You may recall the disk layout I was trying to achieve success with:
> 
> Disk 1:  256GB (nominal) SSD - MBR partitioning
>     P1:  Win  7 Pro, NTFS
>     P2:  Win 10 Pro, NTFS
>     P3:  Win  7 32-Bit Pro, NTFS
>             (for old scanner with only 32-bit drivers)
>     P4:  Ubuntu 24, ext4
> 
> Disk 2:  2TB (nominal) HD - MBR partitioning
>     P1:  Windows Data, NTFS
>     P2:  Linux Data, ext4
> 
> Disk 3:  128GB (nominal) MiniSSD - GPT partitioning
>     P1:  128MB UEFI Boot, FAT32
>     P2:  Win 11 Pro, NTFS
> 
> Before I started this work, when booted via MBR and Disk 1, Grub gave access to all the OSs except W11P, while when booted via UEFI/GPT and Disk 3, only W11P could be booted, whereas obviously I wanted to have just one method of booting every OS.
> 
> Therefore the question was, should I try to find a way of booting W11P via UEFI from the legacy Grub installation on D1, which would have required some sort of forward compatibility of the legacy MBR installation, or should I attempt to load all the other OSs via UEFI via a new Grub installation on D3, which would require backward compatibility?  I felt the chances of forward compatibility were less than the chances of backward compatibility, so, despite the extra work involved, and certainly it was a great deal of work, I chose the latter.
> 
> However, as it has turned out, I've only been able to achieve partial backward compatibility in that all the 64-bit OSs can now be booted from D3, but not the 32-bit OS, I've not been able to find a way of booting Win 7 Pro 32-Bit from UEFI.  Further, I have not been able to find a way of booting *ANY* 32-Bit OS, not even a UEFI boot Win 8 Pro 32-Bit installation USB, when using UEFI on that particular PC (so probably none of the others either, because they're all identical or nearly so), so I suspect that this is a firmware limitation with this range of PCs.
> 
> FTR, this is how I got the other 64-Bit OSs to boot from Grub on the GPT disk, even though they themselves are on an MBR disk ...
> 
> 1)  I renamed MS' D3P1:/Boot folder to 'boot', ie all lower case.
> 
> 2)  I copied the previous MBR grub installation from D1P4:/boot/grub to D3P1:/boot/grub.
> 
> 3)  Similarly, I copied the UEFI grub installation from an Ubuntu 24 installation USB over the previously copied files in D3P1:/boot/grub.
> 
> 4)  In the PC's firmware, I set up a new boot option named 'Grub' to boot ...
>     D3P1:/EFI/Boot/grubx64.efi
> 
> As as result I was now able to boot into Grub displaying the previous menu from the MBR disk (because in step 2 I'd copied the grub.cfg across with everything else and taken steps to prevent it being lost in step 3), but of course most of the options didn't work.
> 
> However, the existing Ubuntu 24 installation was able to boot from this new Grub menu, the only discernible difference being that an additional initial message is displayed briefly, it reads ...
> 
> EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
> 
> ... and thereafter the boot proceeds apparently as normal.
> 
> 5) Next, I thought it should be possible somehow to boot via UEFI into Ubuntu and simply run 'update-grub' to complete the setup, as per this advice ...
> 
> https://askubuntu.com/questions/831216/how-can-i-reinstall-grub-to-the-efi-partition
> 
> ... but this proved a complete waste of time.  First I tried doing it from the existing Ubuntu 24 installation; when booted via UEFI, the EFI system is available, but when doing a chroot to perform update-grub, the EFI subsystem and its associated variables were lost.  So next I tried booting via EFI from an Ubuntu 24 installation USB, but the same thing happened.  Finally, after much machination I installed a separate UEFI Ubuntu 24 on a spare disk and booted from that, and finally succeeded in getting the EFI subsystem available within the chroot, but update-grub didn't find the other OSs on the MBR disk anyway, although it did now complete without error and so create a working entry for the W11P installation on the GPT disk, which reads (beware unintended line-wrap):
> 
> 5a) menuentry 'Windows Boot Manager (on /dev/sdc1)' --class windows --class os $menuentry_id_option 'osprober-efi-1043-DB71' {
>     savedefault
>     insmod part_gpt
>     insmod fat
>     set root='hd2,gpt1'
>     if [ x$feature_platform_search_hint = xy ]; then
>       search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt1 --hint-efi=hd2,gpt1 --hint-baremetal=ahci2,gpt1 1043-DB71
>     else
>       search --no-floppy --fs-uuid --set=root 1043-DB71
>     fi
>     chainloader /EFI/Microsoft/Boot/bootmgfw.efi
> }
> 
> But for the others I had to wing it, using little clues from various researches online, none of which gave a complete template or revealed a crucial extra step to get Windows 7 & 10 to boot, which is that you need to load the module 'ntfscomp'  -  I guess comp is short for 'compatible' or some related word.  Also, you can't use drivemap but anyway don't need to, and you have to change the 'chainloader' command, like so ...
> 
> 6)  Change a current MBR menu item of this form ...
> 
> menuentry "Windows ... {
>     ...
>     insmod ntfs
>     ...
>     drivemap ...
>     chainloader +1
> }
> 
> ... to a GPT equivalent of this form ...
> 
> menuentry "Windows ... {
>     ...
>     insmod ntfs
>     insmod ntfscomp
>     ...
>     chainloader /Windows/Boot/EFI/bootmgfw.efi
> }
> 
> 7)  The next thing to be done is to create the BCD files within the relevant Windows installation(s).  This can be done by booting into a PE environment, most probably from an installation media and then choosing Repair ... Command Console.
> 
> 7a) First check the drive letters associated with the various partitions on the various disks, and adjust the one you want to work with to be C:
> 
>     DISKPART
>     LIST VOL
> 
> If a different volume than the one you want to work with is C:, first temporarily assign it a different letter, say T:, then assign the volume you want to work with, here assumed to be 2, to C: ...
> 
>     SELECT VOL 1
>     ASSIGN LETTER=T:
>     SELECT VOL 2
>     ASSIGN LETTER=C:
>     EXIT
> 
> 7b) Then, back in the console, give the following command ...
> 
>     BCDBoot C:\Windows /s C: /f ALL
> 
> ... the 'ALL' parameter of which instructs BCDBoot to copy new BCD files into both ...
> 
>     C:\Boot\
> 
> ... and (you might have to create the following parent directory chains before running the above command) ...
> 
>     C:\EFI\Microsoft\Boot\
>     C:\EFI\Microsoft\Recovery\
> 
> Repeat 7a and 7b for any other Windows installations.
> 
> When complete, though I'm not sure that it's actually necessary, on the principle of being better safe than sorry I use DISKPART to reassign the drive letters back to what originally they were.
> 
> Then reboot, and it all works.
> 
> It's annoying about the 32-Bit problem, though of course I can still boot it via MBR  -  I need to use that for one particular old scanner for which I cannot get 64-bit drivers; it's useful to keep it going because it's quite suited to old gritty material which might scratch the glass of the new one, and also it's the only one I have with an Automatic Document Feeder.
> 
> Perhaps next I might try seeing if I can boot W11P from the original MBR menu, which would achieve the desired state of only needing one boot menu.
> 

> But for the others I had to wing it, using little clues from various researches online,
> none of which gave a complete template or revealed a crucial extra step to get
> Windows 7 & 10 to boot, which is that you need to load the module 'ntfscomp'

  "ntfscomp - GRUB is able to support the compression commonly used in NTFS with this module"

That could be Old Compression (an ATTRIB applied to a file), versus New Compression
(a custom Reparse Point invented by Microsoft to annoy Linux users).

Regarding scanners, there is the commercial scanner driver package for old scanners.
That could allow you to access the old scanner from a 64-bit OS, for a price.
(hamrick.com VueScan). The main concern for old scanner users, is whether all
the capabilities of the scanner are available, when a novel driver is used.

   Paul