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