Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.microsoft.windows > #2955 > unrolled thread

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

Back to article view | Back to alt.comp.microsoft.windows

Contents

  Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Java Jive <java@evij.com.invalid> - 2025-10-31 12:56 +0000
    Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop "Carlos E.R." <robin_listas@es.invalid> - 2025-10-31 14:26 +0100
    Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Windows Elf <windows.elf@outlook.com.invalid> - 2025-10-31 14:57 +0000
    Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Paul <nospam@needed.invalid> - 2025-10-31 12:04 -0400
    Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Theo <theom+news@chiark.greenend.org.uk> - 2025-10-31 16:06 +0000
    Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Java Jive <java@evij.com.invalid> - 2025-11-02 14:12 +0000
      Beware 32-Bit Ghost v11.5 on GPT Disk (was: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop) Java Jive <java@evij.com.invalid> - 2025-11-04 14:40 +0000
        Re: Beware 32-Bit Ghost v11.5 on GPT Disk (was: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop) Windows Elf <windows.elf@outlook.com.invalid> - 2025-11-04 16:46 +0000
          Re: Beware 32-Bit Ghost v11.5 on GPT Disk Paul <nospam@needed.invalid> - 2025-11-04 15:18 -0500
        Re: Beware 32-Bit Ghost v11.5 on GPT Disk Java Jive <java@evij.com.invalid> - 2025-11-10 18:03 +0000
          Re: Beware 32-Bit Ghost v11.5 on GPT Disk Paul <nospam@needed.invalid> - 2025-11-10 14:20 -0500
    Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Java Jive <java@evij.com.invalid> - 2025-11-11 00:27 +0000
      Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Paul <nospam@needed.invalid> - 2025-11-10 22:45 -0500
        Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Java Jive <java@evij.com.invalid> - 2025-11-11 13:19 +0000
          Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Paul <nospam@needed.invalid> - 2025-11-11 10:13 -0500
            Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop "Carlos E.R." <robin_listas@es.invalid> - 2025-11-14 13:24 +0100
              Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Paul <nospam@needed.invalid> - 2025-11-14 13:03 -0500
                Re: scanners. "Carlos E.R." <robin_listas@es.invalid> - 2025-11-14 20:31 +0100
                  Re: scanners. Paul <nospam@needed.invalid> - 2025-11-14 17:52 -0500
                    Re: scanners. "Carlos E.R." <robin_listas@es.invalid> - 2025-11-15 04:06 +0100
          Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Java Jive <java@evij.com.invalid> - 2025-11-15 01:57 +0000
            Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop "Carlos E.R." <robin_listas@es.invalid> - 2025-11-15 14:51 +0100
              Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Java Jive <java@evij.com.invalid> - 2025-11-15 15:01 +0000
                Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Paul <nospam@needed.invalid> - 2025-11-15 11:54 -0500
          Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Java Jive <java@evij.com.invalid> - 2026-02-20 17:44 +0000
            Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Paul <nospam@needed.invalid> - 2026-02-20 13:46 -0500
              Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Java Jive <java@evij.com.invalid> - 2026-02-20 20:01 +0000
                Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Java Jive <java@evij.com.invalid> - 2026-02-20 23:29 +0000
      Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop TJ <TJ@noneofyour.business> - 2025-11-16 13:58 -0500
      Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop Java Jive <java@evij.com.invalid> - 2025-12-16 17:04 +0000
        Re: Is it possible to dual-boot both MBR & GPT without changing BIOS settings on laptop "Carlos E.R." <robin_listas@es.invalid> - 2025-12-16 21:27 +0100

Page 2 of 2 — ← Prev page 1 [2]

#2975

On 2025-11-11 13:19, Java Jive wrote:
>
> On 2025-11-11 03:45, Paul wrote:
>>
>> On Mon, 11/10/2025 7:27 PM, Java Jive wrote:
>>>
>>> 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.
> 
> Had a go at that meantime, couldn't get it to work.

Still no success with this business of trying to boot Win11P on a GPT 
disk from Grub launched from an MBR disk.  This is what I've tried ...

menuentry 'Windows 11 Professional (on /dev/sdc2)' --class windows 
--class os $menuentry_id_option 'osprober-chain-65153A0C0A7F9BDA' {
	savedefault
	insmod part_gpt
	insmod ntfs
	set root='hd2,gpt2'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt2 
--hint-efi=hd2,gpt2 --hint-baremetal=ahci2,gpt2 65153A0C0A7F9BDA
	else
	  search --no-floppy --fs-uuid --set=root 65153A0C0A7F9BDA
	fi
	chainloader /BOOTMGR
}

The above is what seems to get slightly furthest, but it fails with ...

         error: invalid signature
         Press any key to continue...

I've also tried both of the following ...

         chainloader +1
         chainloader /BOOTSECT.BIN

... where /BOOTSECT.BIN is a dd dump of the first sector of the Win11P 
partition, but both simply end up with the PC rebooting.

-- 

Fake news kills!

I may be contacted via the contact address given on my website: 
www.macfh.co.uk

[toc] | [prev] | [next] | [standalone]

#2977

On 2025-11-15 02:57, Java Jive wrote:
> On 2025-11-11 13:19, Java Jive wrote:
>>
>> On 2025-11-11 03:45, Paul wrote:
>>>
>>> On Mon, 11/10/2025 7:27 PM, Java Jive wrote:
>>>>
>>>> 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.
>>
>> Had a go at that meantime, couldn't get it to work.
> 
> Still no success with this business of trying to boot Win11P on a GPT 
> disk from Grub launched from an MBR disk.  This is what I've tried ...

Maybe using os-probe from the first disk, it would find the W11 and 
create an stanza.


-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#2979

On 2025-11-15 13:51, Carlos E.R. wrote:
> On 2025-11-15 02:57, Java Jive wrote:
>> On 2025-11-11 13:19, Java Jive wrote:
>>>
>>> On 2025-11-11 03:45, Paul wrote:
>>>>
>>>> On Mon, 11/10/2025 7:27 PM, Java Jive wrote:
>>>>>
>>>>> 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.
>>>
>>> Had a go at that meantime, couldn't get it to work.
>>
>> Still no success with this business of trying to boot Win11P on a GPT 
>> disk from Grub launched from an MBR disk.  This is what I've tried ...
> 
> Maybe using os-probe from the first disk, it would find the W11 and 
> create an stanza.

Running 'update-grub' produces two entries, one for each set of UEFI 
boot files in /dev/sdc{1,2}, and both entries are similar to the one 
already quoted, except that both insert a drivemap command and use 
chainloader +1, so both reboot the PC.

-- 

Fake news kills!

I may be contacted via the contact address given on my website: 
www.macfh.co.uk

[toc] | [prev] | [next] | [standalone]

#2983

On Sat, 11/15/2025 10:01 AM, Java Jive wrote:
> On 2025-11-15 13:51, Carlos E.R. wrote:
>> On 2025-11-15 02:57, Java Jive wrote:
>>> On 2025-11-11 13:19, Java Jive wrote:
>>>>
>>>> On 2025-11-11 03:45, Paul wrote:
>>>>>
>>>>> On Mon, 11/10/2025 7:27 PM, Java Jive wrote:
>>>>>>
>>>>>> 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.
>>>>
>>>> Had a go at that meantime, couldn't get it to work.
>>>
>>> Still no success with this business of trying to boot Win11P on a GPT disk from Grub launched from an MBR disk.  This is what I've tried ...
>>
>> Maybe using os-probe from the first disk, it would find the W11 and create an stanza.
> 
> Running 'update-grub' produces two entries, one for each set of UEFI boot files in /dev/sdc{1,2}, and both entries are similar to the one already quoted, except that both insert a drivemap command and use chainloader +1, so both reboot the PC.
> 

Would this process go any easier, if the controlling disk was
a UEFI one, and the only tricky chainloading it had to do was
an MBR one ?

I have a copy of the Supergrub disc, and it appears to only
support UEFI booting, as if MBR booting would not be sufficient.

Name: supergrub2-2.06s4-multiarch-USB.img.zip
Size: 24206301 bytes (23 MiB)
SHA256: 3F690588C5DBE80A9186818F5AA7B7566D4F2DC079F0FD9D06961F62DE0D7A0D

   Paul

[toc] | [prev] | [next] | [standalone]

#3312

On 2025-11-11 13:19, Java Jive wrote:
> On 2025-11-11 03:45, Paul wrote:
>>
>> On Mon, 11/10/2025 7:27 PM, Java Jive wrote:
>>>
>>> Then reboot, and it all works.
> 
> Except, I've discovered, OSs won't hibernate, all that happens is that 
> the screen locks, the PC doesn't even sleep, let alone hibernate.

I wrote this some time ago, so can not be sure now what was going on 
then, but my suspicion is that it was the same as I recently discovered 
on one particular PC ...

The PC has a single GPT disk dual-booting between Windows 11 & Ubuntu 
24.  I have two GRUB entries to boot Windows 11.  The first is a 
conventional Windows Boot Manager entry in the EFI partition, the second 
is similar but installed in the Windows 11 partition \EFI folder.  If 
Windows 11 is booted via the first option, it hibernates, but if it 
booted via the second option, it won't hibernate as originally I 
described above.  I think it's something to do with Ubuntu/GRUB not 
being able to access some needed data on the ntfs partition when booting.

The relevant entries in /boot/grub/grub.cfg are as follows:

# Boots and hibernates
menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows --class 
os $menuentry_id_option 'osprober-efi-E00A-0248' {
         savedefault
         insmod part_gpt
         insmod fat
         set root='hd0,gpt1'
         if [ x$feature_platform_search_hint = xy ]; then
             search --no-floppy --fs-uuid --set=root 
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1
E00A-0248
         else
           search --no-floppy --fs-uuid --set=root E00A-0248
         fi
         chainloader /efi/Microsoft/Boot/bootmgfw.efi
}
# Boots but does not hibernate
menuentry 'Windows 11 Professional (on /dev/sda2)' --class windows 
--class os $menuentry_id_option 'osprober-efi-53C598050A7F9BDA' {
         savedefault
         insmod part_gpt
         insmod ntfs
         set root='hd0,gpt2'
         if [ x$feature_platform_search_hint = xy ]; then
           search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 53C598050A7F9BDA
         else
           search --no-floppy --fs-uuid --set=root 53C598050A7F9BDA
         fi
         chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

-- 

Fake news kills!

I may be contacted via the contact address given on my website: 
www.macfh.co.uk

[toc] | [prev] | [next] | [standalone]

#3313

On Fri, 2/20/2026 12:44 PM, Java Jive wrote:
> On 2025-11-11 13:19, Java Jive wrote:
>> On 2025-11-11 03:45, Paul wrote:
>>>
>>> On Mon, 11/10/2025 7:27 PM, Java Jive wrote:
>>>>
>>>> Then reboot, and it all works.
>>
>> Except, I've discovered, OSs won't hibernate, all that happens is that the screen locks, the PC doesn't even sleep, let alone hibernate.
> 
> I wrote this some time ago, so can not be sure now what was going on then, but my suspicion is that it was the same as I recently discovered on one particular PC ...
> 
> The PC has a single GPT disk dual-booting between Windows 11 & Ubuntu 24.  I have two GRUB entries to boot Windows 11.  The first is a conventional Windows Boot Manager entry in the EFI partition, the second is similar but installed in the Windows 11 partition \EFI folder.  If Windows 11 is booted via the first option, it hibernates, but if it booted via the second option, it won't hibernate as originally I described above.  I think it's something to do with Ubuntu/GRUB not being able to access some needed data on the ntfs partition when booting.
> 
> The relevant entries in /boot/grub/grub.cfg are as follows:
> 
> # Boots and hibernates
> menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-efi-E00A-0248' {
>         savedefault
>         insmod part_gpt
>         insmod fat
>         set root='hd0,gpt1'
>         if [ x$feature_platform_search_hint = xy ]; then
>             search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1
> E00A-0248
>         else
>           search --no-floppy --fs-uuid --set=root E00A-0248
>         fi
>         chainloader /efi/Microsoft/Boot/bootmgfw.efi
> }
> # Boots but does not hibernate
> menuentry 'Windows 11 Professional (on /dev/sda2)' --class windows --class os $menuentry_id_option 'osprober-efi-53C598050A7F9BDA' {
>         savedefault
>         insmod part_gpt
>         insmod ntfs
>         set root='hd0,gpt2'
>         if [ x$feature_platform_search_hint = xy ]; then
>           search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 53C598050A7F9BDA
>         else
>           search --no-floppy --fs-uuid --set=root 53C598050A7F9BDA
>         fi
>         chainloader /EFI/Microsoft/Boot/bootmgfw.efi
> }
> 

The first entry has a short disk identifier, suggesting the ESP FAT32 partition.

The second entry has a long disk identifier, suggesting the NTFS OS partition,
which does not particularly have a /EFI/Microsoft/Boot/bootmgfw.efi and
so "something else" is happening there when it boots. While the second entry
might be able to find C:\boot (which third-party tools might use), it would
take a BCD file to point to that, at a guess.

The OS-Prober seems to have sniffed and found two ways in,
implying that at least one key file could be found via each
path. The OS-Prober is a tiny utility, 23KB or so,
and I doubt it would have a verbose interface to tell you
what it thinks it saw. When you do an update-grub, you can
see in the command line, it will spit out text for each
detected item. But it might not comment on the type of
boot entry it located, so you can understand how it managed
to do that.

*******

The behavior of Windows changes slightly, if you do this:

   bcdedit /set {bootmgr} displaybootmenu True

The appearance of that, is the black coloured, text based WinXP menu.
But appearances are not important, the important detail by enabling
that, is if two Windows OSes are listed in multi-boot, you can
start either one "without paying for a second boot cycle". Windows
records which of the two OSes booted last, and this may have something
to do with honouring hiberfiles and fast boot. Whereas the WinXP style
menu allows entering an OS, with no care at all about what previously
booted. The black menu is "stateless", which I like.

Now, if you set that, then booted over to Ubuntu and doing another
OS-Prober run via sudo update-grub, I doubt the sniffing and detection
would change. Maybe nothing would change. But that's another variable
in the situation. The black WinXP-era boot menu, also offers F8 if
you wanted to use Safe Mode. I've never had to resort to Safe Mode
on Windows 11, so that may offer zero utility these days.

There is just little leverage that I can see, for stopping this
from happening. And all I can suggest, is watching the output
of OS-Prober for a hint of why it thinks the second path is valid.

There are many ways to prepare Windows partitions. A user for example,
could do version upgrades sequentially, one after another, over top
of C: , with the end result being, the potential to inherit rather
"old" materials. A clean install should be in the current epoch,
and the snooty behavior of current Windows versions, I really
cannot see it leaving behind "anything inviting" for mistakes like this.

   Paul

[toc] | [prev] | [next] | [standalone]

#3314

On 2026-02-20 18:46, Paul wrote:
> On Fri, 2/20/2026 12:44 PM, Java Jive wrote:
>> On 2025-11-11 13:19, Java Jive wrote:
>>> On 2025-11-11 03:45, Paul wrote:
>>>>
>>>> On Mon, 11/10/2025 7:27 PM, Java Jive wrote:
>>>>>
>>>>> Then reboot, and it all works.
>>>
>>> Except, I've discovered, OSs won't hibernate, all that happens is that the screen locks, the PC doesn't even sleep, let alone hibernate.
>>
>> I wrote this some time ago, so can not be sure now what was going on then, but my suspicion is that it was the same as I recently discovered on one particular PC ...
>>
>> The PC has a single GPT disk dual-booting between Windows 11 & Ubuntu 24.  I have two GRUB entries to boot Windows 11.  The first is a conventional Windows Boot Manager entry in the EFI partition, the second is similar but installed in the Windows 11 partition \EFI folder.  If Windows 11 is booted via the first option, it hibernates, but if it booted via the second option, it won't hibernate as originally I described above.  I think it's something to do with Ubuntu/GRUB not being able to access some needed data on the ntfs partition when booting.
>>
>> The relevant entries in /boot/grub/grub.cfg are as follows:
>>
>> # Boots and hibernates
>> menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-efi-E00A-0248' {
>>          savedefault
>>          insmod part_gpt
>>          insmod fat
>>          set root='hd0,gpt1'
>>          if [ x$feature_platform_search_hint = xy ]; then
>>              search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1
>> E00A-0248
>>          else
>>            search --no-floppy --fs-uuid --set=root E00A-0248
>>          fi
>>          chainloader /efi/Microsoft/Boot/bootmgfw.efi
>> }
>> # Boots but does not hibernate
>> menuentry 'Windows 11 Professional (on /dev/sda2)' --class windows --class os $menuentry_id_option 'osprober-efi-53C598050A7F9BDA' {
>>          savedefault
>>          insmod part_gpt
>>          insmod ntfs
>>          set root='hd0,gpt2'
>>          if [ x$feature_platform_search_hint = xy ]; then
>>            search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 53C598050A7F9BDA
>>          else
>>            search --no-floppy --fs-uuid --set=root 53C598050A7F9BDA
>>          fi
>>          chainloader /EFI/Microsoft/Boot/bootmgfw.efi
>> }
> 
> The first entry has a short disk identifier, suggesting the ESP FAT32 partition.
> 
> The second entry has a long disk identifier, suggesting the NTFS OS partition,
> which does not particularly have a /EFI/Microsoft/Boot/bootmgfw.efi and
> so "something else" is happening there when it boots. While the second entry
> might be able to find C:\boot (which third-party tools might use), it would
> take a BCD file to point to that, at a guess.

Yes, basically I would prefer a system where everything needed to boot 
an OS is contained within that OS' partition.  Therefore, when setting 
up the dual-boot I ran the following command to install a secondary BCD 
file onto the C: drive in addition to the one in the FAT32 EFI partition ...

C:\Windows\System32\BCDBoot C:\Windows /s C: /f ALL

... and, because the default option name for such installs is "Windows 
Boot Manager", to remove the ambiguity between the additional option on 
the C: drive and the usual one in the EFI partition, I then ran ...

BCDEDIT /set {default} DESCRIPTION "Windows 11 Professional"

... which simply renames the additional option so that the two options 
will appear in GRUB under two different menus.

As I have explained, the additional option does indeed boot fine, 
seemingly entirely normally, it's only when you try to hibernate the OS 
that it becomes apparent that something is wrong.

> [snip]
> 
> *******
> 
> The behavior of Windows changes slightly, if you do this:
> 
>     bcdedit /set {bootmgr} displaybootmenu True
> 
> The appearance of that, is the black coloured, text based WinXP menu.
> But appearances are not important, the important detail by enabling
> that, is if two Windows OSes are listed in multi-boot, you can
> start either one "without paying for a second boot cycle". Windows
> records which of the two OSes booted last, and this may have something
> to do with honouring hiberfiles and fast boot. Whereas the WinXP style
> menu allows entering an OS, with no care at all about what previously
> booted. The black menu is "stateless", which I like.
> 
> Now, if you set that, then booted over to Ubuntu and doing another
> OS-Prober run via sudo update-grub, I doubt the sniffing and detection
> would change. Maybe nothing would change. But that's another variable
> in the situation. The black WinXP-era boot menu, also offers F8 if
> you wanted to use Safe Mode. I've never had to resort to Safe Mode
> on Windows 11, so that may offer zero utility these days.
> 
> There is just little leverage that I can see, for stopping this
> from happening. And all I can suggest, is watching the output
> of OS-Prober for a hint of why it thinks the second path is valid.
> 
> There are many ways to prepare Windows partitions. A user for example,
> could do version upgrades sequentially, one after another, over top
> of C: , with the end result being, the potential to inherit rather
> "old" materials. A clean install should be in the current epoch,
> and the snooty behavior of current Windows versions, I really
> cannot see it leaving behind "anything inviting" for mistakes like this.

Thanks for this additional information.

-- 

Fake news kills!

I may be contacted via the contact address given on my website: 
www.macfh.co.uk

[toc] | [prev] | [next] | [standalone]

#3315

On 2026-02-20 20:01, Java Jive wrote:
> On 2026-02-20 18:46, Paul wrote:
>> On Fri, 2/20/2026 12:44 PM, Java Jive wrote:
>>> On 2025-11-11 13:19, Java Jive wrote:
>>>> On 2025-11-11 03:45, Paul wrote:
>>>>>
>>>>> On Mon, 11/10/2025 7:27 PM, Java Jive wrote:
>>>>>>
>>>>>> Then reboot, and it all works.
>>>>
>>>> Except, I've discovered, OSs won't hibernate, all that happens is 
>>>> that the screen locks, the PC doesn't even sleep, let alone hibernate.
>>>
>>> I wrote this some time ago, so can not be sure now what was going on 
>>> then, but my suspicion is that it was the same as I recently 
>>> discovered on one particular PC ...
>>>
>>> The PC has a single GPT disk dual-booting between Windows 11 & Ubuntu 
>>> 24.  I have two GRUB entries to boot Windows 11.  The first is a 
>>> conventional Windows Boot Manager entry in the EFI partition, the 
>>> second is similar but installed in the Windows 11 partition \EFI 
>>> folder.  If Windows 11 is booted via the first option, it hibernates, 
>>> but if it booted via the second option, it won't hibernate as 
>>> originally I described above.  I think it's something to do with 
>>> Ubuntu/GRUB not being able to access some needed data on the ntfs 
>>> partition when booting.
>>>
>>> The relevant entries in /boot/grub/grub.cfg are as follows:
>>>
>>> # Boots and hibernates
>>> menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows 
>>> --class os $menuentry_id_option 'osprober-efi-E00A-0248' {
>>>          savedefault
>>>          insmod part_gpt
>>>          insmod fat
>>>          set root='hd0,gpt1'
>>>          if [ x$feature_platform_search_hint = xy ]; then
>>>              search --no-floppy --fs-uuid --set=root 
>>> --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1
>>> E00A-0248
>>>          else
>>>            search --no-floppy --fs-uuid --set=root E00A-0248
>>>          fi
>>>          chainloader /efi/Microsoft/Boot/bootmgfw.efi
>>> }
>>> # Boots but does not hibernate
>>> menuentry 'Windows 11 Professional (on /dev/sda2)' --class windows 
>>> --class os $menuentry_id_option 'osprober-efi-53C598050A7F9BDA' {
>>>          savedefault
>>>          insmod part_gpt
>>>          insmod ntfs
>>>          set root='hd0,gpt2'
>>>          if [ x$feature_platform_search_hint = xy ]; then
>>>            search --no-floppy --fs-uuid --set=root 
>>> --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 
>>> 53C598050A7F9BDA
>>>          else
>>>            search --no-floppy --fs-uuid --set=root 53C598050A7F9BDA
>>>          fi
>>>          chainloader /EFI/Microsoft/Boot/bootmgfw.efi
>>> }
>>
>> The first entry has a short disk identifier, suggesting the ESP FAT32 
>> partition.
>>
>> The second entry has a long disk identifier, suggesting the NTFS OS 
>> partition,
>> which does not particularly have a /EFI/Microsoft/Boot/bootmgfw.efi and
>> so "something else" is happening there when it boots. While the second 
>> entry
>> might be able to find C:\boot (which third-party tools might use), it 
>> would
>> take a BCD file to point to that, at a guess.
> 
> Yes, basically I would prefer a system where everything needed to boot 
> an OS is contained within that OS' partition.  Therefore, when setting 
> up the dual-boot I ran the following command to install a secondary BCD 
> file onto the C: drive in addition to the one in the FAT32 EFI partition 
> ...
> 
> C:\Windows\System32\BCDBoot C:\Windows /s C: /f ALL
> 
> ... and, because the default option name for such installs is "Windows 
> Boot Manager", to remove the ambiguity between the additional option on 
> the C: drive and the usual one in the EFI partition, I then ran ...
> 
> BCDEDIT /set {default} DESCRIPTION "Windows 11 Professional"
> 
> ... which simply renames the additional option so that the two options 
> will appear in GRUB under two different ...

... names!

> As I have explained, the additional option does indeed boot fine, 
> seemingly entirely normally, it's only when you try to hibernate the OS 
> that it becomes apparent that something is wrong.

-- 

Fake news kills!

I may be contacted via the contact address given on my website: 
www.macfh.co.uk

[toc] | [prev] | [next] | [standalone]

#2994

On 2025-11-10 19:27, Java Jive wrote:
> 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
> 

FWIW, I multi-boot on my UEFI-capable machines using the rEFInd boot 
manager. https://www.rodsbooks.com/refind/ IIRC, I believe it can boot 
either an EFI or a BIOS OS, but you might want to read the website 
carefully to confirm that. Seems to me that I was able to boot a legacy 
usb stick once, but it's been a couple of years since I tried it.

While it works for me, there are several differences between my machines 
and yours. I'm using Mageia 9 Linux, for one thing, and it will install 
rEFInd on your UEFI machine for you if requested.

I do not have separate Windows partitions. For the very few things I 
need Windows to do I have a Windows 7 and Windows 10 guests in 
VirtualBox. At this time I have zero interest in Windows 11.

I also have a relatively new scanner, part of an HP Envy Photo 7858 
printer. My old scanner died a few years back, and while looking for a 
stand-alone model to replace it I discovered that the most economical 
way to get one was to buy one with a printer attached. The scanner, as 
well as my color Laserjet m254dw, can be connected via wifi or Ethernet 
and both work well with both Mageia and the Windows guests.

TJ

[toc] | [prev] | [next] | [standalone]

#3074

On 2025-11-11 00:27, Java Jive wrote:
> 
> 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.

Had another look at this today, and, as I suspected, it is indeed a 
firmware limitation of these Dell Precision M6700/M6800 laptops:

https://www.google.com/search?q=boot+via+UEFI+32-bit+windows+on+Dell+Precision+M6700

"AI Overview

Booting a 32-bit version of Windows in UEFI mode on a Dell Precision 
M6700 is not typically possible, because the system's UEFI firmware is 
64-bit and does not support native 32-bit UEFI booting.  Most modern 
systems, including the M6700, use a 64-bit UEFI, which requires a 64-bit 
operating system to boot in UEFI mode."

-- 

Fake news kills!

I may be contacted via the contact address given on my website: 
www.macfh.co.uk

[toc] | [prev] | [next] | [standalone]

#3075

On 2025-12-16 18:04, Java Jive wrote:
> On 2025-11-11 00:27, Java Jive wrote:
>>
>> 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.
> 
> Had another look at this today, and, as I suspected, it is indeed a 
> firmware limitation of these Dell Precision M6700/M6800 laptops:
> 
> https://www.google.com/search?q=boot+via+UEFI+32- 
> bit+windows+on+Dell+Precision+M6700
> 
> "AI Overview
> 
> Booting a 32-bit version of Windows in UEFI mode on a Dell Precision 
> M6700 is not typically possible, because the system's UEFI firmware is 
> 64-bit and does not support native 32-bit UEFI booting.  Most modern 
> systems, including the M6700, use a 64-bit UEFI, which requires a 64-bit 
> operating system to boot in UEFI mode."
> 

Ah.

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | alt.comp.microsoft.windows

csiph-web