From Newsgroup: alt.comp.os.windows-11

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

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

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.-a I have two GRUB entries to boot Windows 11.-a 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.-a 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.-a 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' {
-a-a-a-a-a-a-a savedefault
-a-a-a-a-a-a-a insmod part_gpt
-a-a-a-a-a-a-a insmod fat
-a-a-a-a-a-a-a set root='hd0,gpt1'
-a-a-a-a-a-a-a if [ x$feature_platform_search_hint = xy ]; then -a-a-a-a-a-a-a-a-a-a-a search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1
E00A-0248
-a-a-a-a-a-a-a else
-a-a-a-a-a-a-a-a-a search --no-floppy --fs-uuid --set=root E00A-0248 -a-a-a-a-a-a-a fi
-a-a-a-a-a-a-a 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' {
-a-a-a-a-a-a-a savedefault
-a-a-a-a-a-a-a insmod part_gpt
-a-a-a-a-a-a-a insmod ntfs
-a-a-a-a-a-a-a set root='hd0,gpt2'
-a-a-a-a-a-a-a if [ x$feature_platform_search_hint = xy ]; then -a-a-a-a-a-a-a-a-a search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 53C598050A7F9BDA
-a-a-a-a-a-a-a else
-a-a-a-a-a-a-a-a-a search --no-floppy --fs-uuid --set=root 53C598050A7F9BDA -a-a-a-a-a-a-a fi
-a-a-a-a-a-a-a 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
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

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.-a I have two GRUB entries to boot Windows 11.-a 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.-a 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.-a 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' {
-a-a-a-a-a-a-a savedefault
-a-a-a-a-a-a-a insmod part_gpt
-a-a-a-a-a-a-a insmod fat
-a-a-a-a-a-a-a set root='hd0,gpt1'
-a-a-a-a-a-a-a if [ x$feature_platform_search_hint = xy ]; then
-a-a-a-a-a-a-a-a-a-a-a search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1
E00A-0248
-a-a-a-a-a-a-a else
-a-a-a-a-a-a-a-a-a search --no-floppy --fs-uuid --set=root E00A-0248
-a-a-a-a-a-a-a fi
-a-a-a-a-a-a-a 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' {
-a-a-a-a-a-a-a savedefault
-a-a-a-a-a-a-a insmod part_gpt
-a-a-a-a-a-a-a insmod ntfs
-a-a-a-a-a-a-a set root='hd0,gpt2'
-a-a-a-a-a-a-a if [ x$feature_platform_search_hint = xy ]; then
-a-a-a-a-a-a-a-a-a search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 53C598050A7F9BDA
-a-a-a-a-a-a-a else
-a-a-a-a-a-a-a-a-a search --no-floppy --fs-uuid --set=root 53C598050A7F9BDA >> -a-a-a-a-a-a-a fi
-a-a-a-a-a-a-a 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

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

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.-a I have two GRUB entries to boot Windows 11.-a 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.-a 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.-a 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' {
-a-a-a-a-a-a-a-a savedefault
-a-a-a-a-a-a-a-a insmod part_gpt
-a-a-a-a-a-a-a-a insmod fat
-a-a-a-a-a-a-a-a set root='hd0,gpt1'
-a-a-a-a-a-a-a-a if [ x$feature_platform_search_hint = xy ]; then
-a-a-a-a-a-a-a-a-a-a-a-a search --no-floppy --fs-uuid --set=root
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1
E00A-0248
-a-a-a-a-a-a-a-a else
-a-a-a-a-a-a-a-a-a-a search --no-floppy --fs-uuid --set=root E00A-0248
-a-a-a-a-a-a-a-a fi
-a-a-a-a-a-a-a-a 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' {
-a-a-a-a-a-a-a-a savedefault
-a-a-a-a-a-a-a-a insmod part_gpt
-a-a-a-a-a-a-a-a insmod ntfs
-a-a-a-a-a-a-a-a set root='hd0,gpt2'
-a-a-a-a-a-a-a-a if [ x$feature_platform_search_hint = xy ]; then
-a-a-a-a-a-a-a-a-a-a search --no-floppy --fs-uuid --set=root
--hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
53C598050A7F9BDA
-a-a-a-a-a-a-a-a else
-a-a-a-a-a-a-a-a-a-a search --no-floppy --fs-uuid --set=root 53C598050A7F9BDA
-a-a-a-a-a-a-a-a fi
-a-a-a-a-a-a-a-a 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.-a 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

--- Synchronet 3.21b-Linux NewsLink 1.2