XPost: uk.comp.os.linux, alt.comp.microsoft.windows, alt.comp.os.windows-11   
   From: java@evij.com.invalid   
      
   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   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)