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