Jump to content











Photo
- - - - -

GRUB4DOS for UEFI


  • Please log in to reply
372 replies to this topic

#326 Tokener

Tokener

    Frequent Member

  • Developer
  • 336 posts

Posted 4 weeks ago

Hola my friend alacran

Thank you so much for taking the time to find out and share this :worship:

 

If your only intention is to test how to boot a VHD in UEFI environment this easy manual approch may work for you.

 

Procedure:

  1. Create a fixed size (mine is 1 GB for a 790 MB ISO) MBR inicialized single FAT-32 active primary partition VHD.
  2. Extract to the VHD all content of your ISO (...)

 

Yes indeed, this was my only intention.

These 2 steps made it work. (in my case) No need to modify the BCD.

 

 

Windows-Start-Manager
---------------------
Bezeichner              {9dea862c-5cdd-4e70-acc1-f32b344d4795}
description             Windows Boot Manager
locale                  en-US
inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
custom:1600007e         Yes
default                 {7619dcc9-fafe-11d9-b411-000476eba25f}
displayorder            {7619dcc9-fafe-11d9-b411-000476eba25f}
toolsdisplayorder       {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout                 30

Windows-Startladeprogramm
-------------------------
Bezeichner              {7619dcc9-fafe-11d9-b411-000476eba25f}
device                  ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
path                    \windows\system32\boot\winload.efi
description             Windows Setup
locale                  en-US
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
custom:16000060         Yes
osdevice                ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
systemroot              \windows
custom:250000c2         1
detecthal               Yes
winpe                   Yes
ems                     No

 

Great finding! :thumbup:

 

Thanks again   T.


  • alacran likes this

#327 alacran

alacran

    Gold Member

  • .script developer
  • 2111 posts
  •  
    Mexico

Posted 4 weeks ago

It is good to know that worked fine for your tests.

 

This is not a new approach, I mentioned it since some of the first tests on this topic, but it was not explained in detail before.

 

Yes, in fact that part of instructions related to edit the internal bcd(s) (into the VHD) is the generic procedure (to cover all scenarios), as sometimes certain 7-zip extracted WinPE.iso(s) may not work/load fine without that edition. An example could be some of my old WinPEs with diskmod filter driver integrated (not signed and approved by MS) that is loaded during first stages during boot, also same applies for any OS installation on a VHD having SVBus driver, then I consider it is a good practice to follow, just to be on the safe side.

 

By the way I made a new 1.5 GB 10XPE_x64-Flat.vhd (boot.wim installed in Compact LZX mode) + boot files/folders from the PE.iso, and all is working fine now.

 

NOTE: This VHD can't be Rambooted as it lacks SVBus driver, will see if I find a way to install it, (it may be a little hard because of the volatile Registry).

 

There is no doubt I was doing something wrong (memory fails sometimes), just followed by the letter my own instructions on first post of my topic:

 

Install Win10XPE_x64 Flat or Compact Mode on VHD

 

alacran



#328 alacran

alacran

    Gold Member

  • .script developer
  • 2111 posts
  •  
    Mexico

Posted 4 weeks ago

Also tested this entry in UEFI menu.lst to Ramboot a VHD by means of ntloader:

 

 

title Mini-10x64.vhd-SVBUS (/VHD/Mini-10x64.vhd)-chainloader ntloader-vhd-svbus-RAMOS
find --ignore-floppies --ignore-cd /EFI/grub/ntloader | set x=
echo x=%x%
find --ignore-floppies --ignore-cd --set-root /VHD/Mini-10x64.vhd
map --mem --top /VHD/Mini-10x64.vhd (hd)
uuid (hd-1,0)
chainloader %x%/EFI/grub/ntloader hires=0 uuid=%?_UUID% initrd=/EFI/grub/initrd.lz1

 

It worked very fine. It's based on this post by liuzhaoyzz

 

NOTE-1: In this case ntloader and initrd.lz1 are located into \EFI\grub folder which is located on the root of the (MBR first primary active) FAT-32 partition on my USB, and the VHD is located into \VHD folder which is located on the root of the (MBR second primary) NTFS partition on my USB.

 

NOTE-2: This commands will not work for the WinPE.iso extacted by 7-zip to the VHD, where the boot.wim is in sources folder (not deployed), ntloader internal code (in case of UEFI booting VHDs) looks for \Windows\system32\winload.efi, and it is not available.

 

I apologize if my posts may seem with an excess of details and maybe a little repetitive for advanced users but let's remember also non advanced users could come to read this topic.

 

alacran


  • Tokener likes this

#329 alacran

alacran

    Gold Member

  • .script developer
  • 2111 posts
  •  
    Mexico

Posted 4 weeks ago


By the way I made a new 1.5 GB 10XPE_x64-Flat.vhd (boot.wim installed in Compact LZX mode) + boot files/folders from the PE.iso, and all is working fine now.

 

NOTE: This VHD can't be Rambooted as it lacks SVBus driver, will see if I find a way to install it, (it may be a little hard because of the volatile Registry).

 

Just to let you know I was able to install SVBus driver and the VHD is now capable to Ramboot on MBR and UEFI environments.

  1. Mounted the boot.wim with DismMountService by Tokener.
  2. Used offlinereg by erwan.l to integrate the EVRootCA.reg in the Registry.
  3. Added the driver with DismMountService.
  4. Commited changes and dismounted.

 

After this reformated the VHD and deployed the new boot.wim (Compact mode LZX) on the VHD, added the boot files/folders extracting them with 7-zip from the PE.iso, edited the bcd(s), and ready to test.

 

Commands used:

 

MBR menu.lst

title 10XPE_x64-Flat.vhd - SVBus RAMDISK - 1.5 GB - map as (hd-1) for USB
find --set-root --ignore-floppies /10XPE_x64-Flat.vhd
map --top --mem /10XPE_x64-Flat.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr


UEFI menu.lst

title 10XPE_x64-Flat.vhd - SVBus RAMDISK - 1.5 GB for UEFI boot
load /EFI/grub/ntfs_x64.efi
find --set-root /10XPE_x64-Flat.vhd
map --mem --top /10XPE_x64-Flat.vhd (hd)
chainloader (hd-1)

 

After testing I can say: The VHD now Ramboots fine on MBR and UEFI

 

NOTE: Also teted ntloader and it can't boot this VHD as Filedisk or as Ramdisk, it seems as it does not read/use the bcd(s), then don't make use of the "Boot into WinPE" option/parameter selected there.

 

alacran

Attached Thumbnails

  • 10XPE_x64-Flat.png

  • Tokener likes this

#330 Tokener

Tokener

    Frequent Member

  • Developer
  • 336 posts

Posted 4 weeks ago

@alacran

Thank you very much for detailed information.

 

 

  1. Mounted the boot.wim with DismMountService by Tokener.
  2. Used offlinereg by erwan.l to integrate the EVRootCA.reg in the Registry.
  3. Added the driver with DismMountService.
  4. Commited changes and dismounted.

I guess the driver you are mentioning is SVBus, but where is EVRootCA.reg to be found?

 

Best regards   T.



#331 alacran

alacran

    Gold Member

  • .script developer
  • 2111 posts
  •  
    Mexico

Posted 4 weeks ago

To boot 10 in UEFI, drivers digitally signed and MS approved are a requirement.

 

Some guy in China signed it and EVRootCA.reg is the certificate he used, that need to be integrated in the Registry before installing the SVBus driver.

 

But as that certificate has being used widely, including in some malware programs it is tagged as a virus by the AV programs, so you can download it as the file is password protected, but before extract it dissable your AV, I read about it on the Chinese topic made by yaya on woyunet and asked A1ve to share it with us, and I uploaded it to the Downloads Section of the reboot.pro forum, here.

 

To avoid troubles integrating the reg file with offlinereg by erwan.l (as it do not work fine with *.reg files exported from regedit), make right click on it and select edit, copy all its content to a file opened with Notepad and save it as EVRootCA.reg file into offlinereg folder.

 

Booting from Win7 or a Win7 PE (when adding the driver I saw a message about the driver is unsigned but as the host OS was a different version than the target OS then Dism avoided this check):

  1. Mount your boot.wim file with DismMountService into  C:\temp folder.
  2. Go to offlinereg folder, open on same folder an elevated command promt and paste following line:
  3. offlinereg-win64 "C:\temp\Windows\System32\config\software" " " import EVRootCA.reg
  4.   >>> Enter, waith for it to finish and let you know all was fine, then you can close the command window.
  5. Now you can add/import the driver with DismMountService.
  6. Commit changes and dismount.

 

alacran


  • Tokener likes this

#332 alacran

alacran

    Gold Member

  • .script developer
  • 2111 posts
  •  
    Mexico

Posted 3 weeks ago

Summary of ntloader by A1ive

 

Useful to boot:

  • WinPE WIM files
  • VHD files
  • OS

 

Valid environments:

  • Bios  - MBR partition table logical partition is not supported.
  • x64 UEFI, ia32 UEFI

 

How it works:

 

When using ntloader the info located into the BCD store is not used or required, its internal code recognize a WinPE WIM file, a VHD file or a OS and then it loads/run the right boot file in each case.

 

Advantages:

  • It can be used with A1ive's grub2, grub2 and grub4dos on MBR and/or UEFI.
  • There is no need to create boot files/folders into our VHDs when using ntloader.
  • It can run a VHD as Filedik or as Ramdisk (as long as SVBus is installed).
  • There is no need to edit the BCDs if we use SVBus driver for Ramboot.
  • It works fine if Secure Boot is enabled or not.
  • Our VHDs can have only a single NTFS partition without boot files/folders and there is no need to additionaly include in our menu entries the commands to preload ntfs_x64.efi on PCs with usual firmwares for only FAT.

 

Disadvantages:

  • It do not work on MBR logical partitions, (My tests confirm this).
  • The VHDs do not boot from FAT partitions preferable from NTFS, only recent 10 versions could boot from ExFAT partitions (I haven't tested this).
  • It do not work for VHDs installed on Wimboot mode as I read on its topic.
  • A VHD made from a WinPE do not boot using ntloader, (My tests confirm this).

 

Then I can conclude:

 

It is very clear to me the advantages overcome the disadvantages, and I can say it is a very good tool for our tool box.  Anyway for all cases where ntloader can't be used we can use other options.

 

alacran


  • Tokener and Gerolf like this

#333 Shivan

Shivan
  • Members
  • 2 posts
  •  
    Argentina

Posted 2 weeks ago

Hi, i wanted to ask if someone was able to make the new grub4dos version for UEFI work for PXE booting in UEFI mode?

 

Because, i did tried, but it just seem to drop the tftp connection, on my tftp server no other file is requested after the grub4dos.efi file, meaning it does not search for the menu file on the tftp root. I did tried using the mkimage to add the menu file directly into the .efi file, this works, but as expected i cant chainload anything that is on the tftp root, because it says "invalid device expecified". Doing something as simple as "chainload /bootmgrfwx64.efi"

 

Ive been trying to replace my old PXE Bios booting system build upon Grub4Dos that has been working for years now, to boot a Windows BCD menu to points to diferent .wims, clonezilla, linux installers, and iPXE kernel to boot from iSCSI devices.

This has been impossible to me so far, the network version of GRUB2 (grubnetx64.efi) can boot clonezilla and linux installers, but trying to chainload the Windows boot mgr .efi file results in "BlinitializeLibrary failed 0xc0000001" (if i point the DHCP server to the Windows .efi directly  the Windows boot maganer boots and i can boot all wims). And well, i dont know what im going to do for iSCSI because i was unable to find a iPXE .efi file that works where i can point it to diferents "initrds" menu files.

 

I keep trying but im suprised to see that nothing seems to work.

 

Edit: oh i also tryied with the A1live ntloader to boot wim files directly from grub2, but it always gives me "a specified device is not avalible" error on windows boot mgr, i think it is because it cant see the .wim files on the tftp root because i cant pass a uuid for a tftp device. But this is a wild guess here.


Edited by Shivan, 2 weeks ago.


#334 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15714 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 2 weeks ago

Possibly a stupid question, but do you get a (pd) device available?

 

(I seem to remember that with grub4dos - the BIOS only version - in some cases you needed to use it explicitly.) :unsure:

 

As well, still among the things I vaguely remember, there is the pxe keep directive that is (or was) sometimes needed.

 

Maybe if you choose one and one only "payload" that works on BIOS grub4dos (and the settings you use for it) and the settings in grub4uefi for the same payload you are actually trying (and faling with under UEFI), A1ive will be able to see at a glance what is wrong or missing.

 

:duff:

Wonko



#335 Shivan

Shivan
  • Members
  • 2 posts
  •  
    Argentina

Posted 2 weeks ago

Yeah, i on grub4dos bios i had to use "pxe keep" for WIndows chainload and pd for iso booting like this

title Windows Menu
pxe keep
chainloader --raw /boot/pxeboot.n12

title HDD Regenerator
map --mem (pd)/HDDREG.iso (0xFF)
map --hook
root (0xFF)
chainloader (0xFF)

 

"pxe keep" does not exist anymore on the uefi version, so i tried several ways to do it on the uefi version

title Windows
chainloader --raw /boot/bootmgfwx64.efi

title Windows 2
chainloader /boot/bootmgfwx64.efi

title Windows 3
chainloader (pd)/boot/bootmgfwx64.efi 

Does not work, but, again it has to be because it is dropping the tftp connection, at the very least i should be able to see grub4dos requesting the menu file on the tftp server, but it does nothing. using the mkimage was a last resort effort to embed the menu file, it shouldnt be needed.

 

I really not sure how i can help debug this.


Edited by Shivan, 2 weeks ago.


#336 alacran

alacran

    Gold Member

  • .script developer
  • 2111 posts
  •  
    Mexico

Posted 2 weeks ago

@ Shivan

 

Hi, i wanted to ask if someone was able to make the new grub4dos version for UEFI work for PXE booting in UEFI mode?

 

Because, i did tried, but it just seem to drop the tftp connection, on my tftp server no other file is requested after the grub4dos.efi file, meaning it does not search for the menu file on the tftp root. I did tried using the mkimage to add the menu file directly into the .efi file, this works, but as expected i cant chainload anything that is on the tftp root, because it says "invalid device expecified". Doing something as simple as "chainload /bootmgrfwx64.efi"

 

I'm not familiar with TFTP PXE boot, but this is a summary of requirements to UEFI boot using G4E from the HD:

(maybe you can adapt some of this info to work on your PXE server).

 

UEFI menu.lst default location is /EFI/grub/menu.lst

 

MS bootmgfw.efi located into /EFI/Microsoft/Boot/bootmgfw.efi can be renamed to bootx64_win.efi

 

BOOTX64.EFI from grub4dos for UEFI (G4E) can be renamed and copied to /EFI/Microsoft/Boot/bootmgfw.efi, to boot from it, but Secure Boot has to be disabled.

 

To boot from MS bootx64_win.efi use following commands on your UEFI menu.lst:

 

title Windows EFI BootManager - chainloader /EFI/Microsoft/Boot/bootx64_win.efi
find --set-root /EFI/Microsoft/Boot/bootx64_win.efi
chainloader /EFI/Microsoft/Boot/bootx64_win.efi

 

For UEFI booting the partition where EFI boot files/folders are located should be FAT-32, all UEFI firmwares read/load/run EFI boot files from a FAT-32 partition. Usually the firmwares lack NTFS drivers and have only FAT-32 drivers. (same applies for partitions on VHDs).

 

Nevertheless some new MB are now also capables to read/load/run EFI boot files from a NTFS partition.

 

Anyway you may pre-load ntfs_x64.efi, see following example of the commands used on the UEFI menu.lst into my USB device:

 

UEFI Rambooting a VHD (single primary active NTFS partition) using ntfs_x64.efi (MS MBR and UEFI boot files into the VHD):

 

title Boot /Mini-10x64.vhd - UEFI Grub4dos  SVBus  RAMDISK  - 2 GB
load /EFI/grub/ntfs_x64.efi
find --set-root /Mini-10x64.vhd
map --mem --top /Mini-10x64.vhd (hd)
chainloader (hd-1)

 

Filedisk booting a VHD (single primary active NTFS partition) using ntfs_x64.efi (MS MBR and UEFI boot files into the VHD):

 

title Boot /Mini-10x64.vhd - UEFI Grub4dos - Filedisk - 2 GB
load /EFI/grub/ntfs_x64.efi
find --set-root /Mini-10x64.vhd
map /Mini-10x64.vhd (hd)
chainloader (hd-1)

 

Or better use ntloader, very useful for booting OSs, WIM and VHDs, no need to have MS MBR and UEFI boot files into the VHD:

 

Filedisk booting WIM and VHD files using ntloader, (MS MBR and UEFI boot files are NOT required into the VHD):

 

title Boot Windows NT6+ PE - /10XPE_x64.wim
find --set-root /10XPE_x64.wim
uuid %@root%
kernel /ntloader uuid=%?_UUID% file=/10XPE_x64.wim
initrd /initrd.lz1

title Boot Windows NT6+ PE - /Mini-10x64.vhd
find --set-root /Mini-10x64.vhd
uuid %@root%
kernel /ntloader uuid=%?_UUID% file=/Mini-10x64.vhd
initrd /initrd.lz1

 

NOTE: On this case ntloader and initrd.lz1 are on the root of the NTFS partition holding the WIM and the VHD files.

 

UEFI Rambooting a VHD (single primary active NTFS partition) using ntloader, (MS MBR and UEFI boot files are NOT required into the VHD):

 

title Mini-10x64.vhd-SVBUS (/VHD/Mini-10x64.vhd)-chainloader ntloader-vhd-svbus-RAMOS
find --ignore-floppies --ignore-cd /EFI/grub/ntloader | set x=
echo x=%x%
find --ignore-floppies --ignore-cd --set-root /VHD/Mini-10x64.vhd
map --mem --top /VHD/Mini-10x64.vhd (hd)
uuid (hd-1,0)
chainloader %x%/EFI/grub/ntloader hires=0 uuid=%?_UUID% initrd=/EFI/grub/initrd.lz1

 

NOTE: On this case ntloader and initrd.lz1 are located into /EFI/grub folder, and Mini-10x64.vhd is located into /VHD folder on another NTFS partition.

 

Just try to change/adapt previous examples (to your needs) in your embedded menu.

 

You should use this version: grub4dos-for_UEFI-2021-06-19.7z

 

Hope this info can be useful for you.

 

alacran


  • Gerolf likes this

#337 alacran

alacran

    Gold Member

  • .script developer
  • 2111 posts
  •  
    Mexico

Posted 2 weeks ago

On previous post forgot to give an example of the commands for UEFI menu.lst used for a WinPE ISO:

 

 

title Win10XPE - Find images/Win10XPE_x64.ISO
find --set-root /images/Win10XPE_x64.ISO
map /images/Win10XPE_x64.ISO (0xff)
chainloader (0xff)

 

NOTE-1: Win10XPE_x64.ISO is located into /images folder.

 

NOTE-2: If a ISO lacks into it the boot files/folders required to boot on a UEFI environment, it will not boot.

 

alacran



#338 alacran

alacran

    Gold Member

  • .script developer
  • 2111 posts
  •  
    Mexico

Posted 2 weeks ago

@ Shivan

 

Bad news, you are not the only one having troubles trying to make grub4dos for UEFI work for PXE booting in UEFI mode, (it seems there is something related to not being capable to read/load fine the info from the DHCP server), contrary to the grub4dos for MBR that does that task very well.

 

I just saw several post on the grub4dos for UEFI topic  with same issue and it seems so far there is not a known solution for this yet.

 

2011whp is recommending on this post to try integrating the menu (something you already tried): http://bbs.c3.wuyou....652&pid=4308565 translated using Google Translate

Spoiler

 

 

Only thing I could recommend you is open an Issue Report.

 

But it seems you already opened an Issue Report since April 28: https://github.com/c...4dos/issues/262

 

There you are in direct contact with the main developer yaya2007, so I'm afraid nobody here can give you better help or info than the developers.

 

alacran



#339 Guest_AnonVendetta_*

Guest_AnonVendetta_*
  • Guests

Posted A week ago

How does this compare to legacy G4D? Since it's much newer, I'd assume it's pretty much alpha/beta quality, and doesn't have anywhere near the featureset that legacy G4D has.

Does it work with Secure Boot? SB EFI binaries have to be signed, not sure if this is or not.

The comments I'm reading seem to imply that this works with SVBus too. I don't have much use for SVBus in a Windows ramboot scenario, but I can still think of circumstances it would be useful for, like automatically attaching virtual disk images at boot, and exposing them to Windows as a seemingly real disk. Windows can tell the difference between a real disk vs a VHD. But I've noticed that when I use SVBus to mount the VHD at boot, Windows thinks it's a real disk. And so do my other softwares (cloning, backup, FDE encryption).

I'm thinking about switching all my UEFI-supporting OSes to UEFI/GPT, while relegating older legacy OSes to VMs. I can still do legacy boot with all of them, but there's not much sense in trying to live in the past forever, since most future hardware won't support legacy at all.

#340 alacran

alacran

    Gold Member

  • .script developer
  • 2111 posts
  •  
    Mexico

Posted A week ago

How does this compare to legacy G4D? Since it's much newer, I'd assume it's pretty much alpha/beta quality, and doesn't have anywhere near the featureset that legacy G4D has.

Does it work with Secure Boot? SB EFI binaries have to be signed, not sure if this is or not.

 

So far all is working very fine, excluding PXE booting in UEFI mode.

 

It DO NOT work on Secure Boot, but A1ve's grub2 can work on Secure Boot and you can call/run G4E from it.

 

You can have an idea of how it works (with Secure Boot disabled) and see several menu samples reading post No. 336 and 337

 

But I suggest you to make a USB device with USB_FORMAT and also using UEFI_MULTI and VHD_WIMBOOT (all by wimb) and try it from there before doing changes to your internal disk(s), Download link: https://github.com/wimbrts

 

NOTE: A1ve's grub2 is included on USB_FORMAT

 

alacran



#341 Gerolf

Gerolf

    Member

  • Members
  • 67 posts
  •  
    Germany

Posted A week ago

Sorry, this is not a detail instruction a reasonable person would find adequate for a novice using Windows PC. No examples either. By now 12 pages of this topic - and no-one is able to present a clear instruction for a novice, how to add this thing to a Windows PC? Does it require a dedicated FAT32 or EFI partition, located at the internal HDD start? What are the exact Grub4DOS commands, etc.

 

Before discussing VHD boot issues with grub4efi, would it be reasonable to at least explain how to add this to a PC in a concise step-by-step guide anyone can repeat? It will engage a lot more people to the discussion. This is what I consider a sacred duty of any OP presenting a new bootloader or program.

 

It is not intended for novice users. (...)

 

That's no place to stay. We have to put together the pieces for such a tutorial. And while Liuzhaoyzz's tutorial (post 220) is brilliant, with its focus on RAM OS booting it starts well beyond the novize's position, which in my case could be characterized like this:

 

 

(...) I'm thinking about switching all my UEFI-supporting OSes to UEFI/GPT, while relegating older legacy OSes to VMs. I can still do legacy boot with all of them, but there's not much sense in trying to live in the past forever, since most future hardware won't support legacy at all.

 

So let's say I've got this spare shitty old laptop securely booting to Windows 10 and even 11 on a GPT disk. But as Liuzhaoyzz mentions ...

 

 

The essence of "secure boot" is that Microsoft suppresses Linux and charges protection fees in order to strengthen its monopoly. Dirty means, grub4dos/grub2 does not pay Microsoft a protection fee, so it cannot be directly started via secure boot. Generally, it is recommended to disable secure boot in the BIOS settings.

Then we would lag behind the development. Grub4DOS for UEFI must be bootable even on a "secure" PC. The Debian Wiki Team contradicts:

 

 

Other Linux distros (Red Hat, Fedora, SUSE, Ubuntu, etc.) have had Secure Boot working for a while, but Debian was slow in getting this working. This meant that on many new computer systems, users had to first disable SB to be able to install and use Debian. The methods for doing this vary massively from one system to another, making this potentially quite difficult for users. Starting with Debian version 10 ("Buster"), Debian included working UEFI Secure Boot to make things easier. (...)

UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run. There are certain identification requirements that organisations have to meet here, and code has to be audited for safety. But these are not too difficult to achieve. SB is also not meant to lock users out of controlling their own systems. (...)

Shim is a simple software package that is designed to work as a first-stage bootloader on UEFI systems.It was developed by a group of Linux developers from various distros, working together to make SB work using Free Software. It is a common piece of code that is safe, well-understood and audited so that it can be trusted and signed using platform keys. This means that Microsoft (or other potential firmware CA providers) only have to worry about signing shim, and not all of the other programs that distro vendors might want to support.

Shim then becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust - the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.

 

On each architecture, Debian includes various packages containing signed binaries: (...) grub-efi-amd64-signed (...)

 

So I would expect my test computer to be securely dual-bootable to Windows 10/11 and Debian 10, with the latter's signed Grub2 for UEFI to be able to chainload our new Grub4DOS for UEFI, such that I could do my unsecure booting experiments with virtual disks, right? Which would be the menu entry for Grub2?

 

(Just that my preferred Linux is openSUSE Tumbleweed, which is very much like Windows because as a rolling release it must not be re-installed for years, at least in theory. openSUSE also focuses on hypervisors and has a Yast GUI to configure the Grub2 boot manager.)
 


  • Tokener likes this

#342 alacran

alacran

    Gold Member

  • .script developer
  • 2111 posts
  •  
    Mexico

Posted A week ago

@ Gerolf

 

So I would expect my test computer to be securely dual-bootable to Windows 10/11 and Debian 10, with the latter's signed Grub2 for UEFI to be able to chainload our new Grub4DOS for UEFI, such that I could do my unsecure booting experiments with virtual disks, right? Which would be the menu entry for Grub2?

 

It seems you already have your multiboot working on UEFI + Secure Boot solved.

 

And you only want to make some experiments using grub4dos for UEFI (G4E), sorry but AFAIK so far G4E can't boot the way you want.  EDIT: See post No. 347  for testing a possible option.

 

Remember this is a very new development (it started in October 2020) and we should be very grateful to the development team of grub4dos for UEFI (G4E) for all achievements they have reached so far, and nobody has any right to complain for this gift they are very kindly making to all of us, if it don't fit his/hers preferences, or wishes.

 

And in fact manual procedure is not intended for novice users, as yourself quoted from a topic by the good steve6375

 

The best option available for novice users is boot from a USB device using the programs developed by wimb as USB_FORMAT to automatically format the USB device and install into it a slightly modded a1ve's grub2 (that will help us to boot on UEFI + Secure Boot) and also create the full layout into the FAT-32 partition with all required to be able to boot including config menus, this way the USB will be able to boot on following scenarios:

 

USB_FORMAT

 

On MBR:

Using Windows bootmanger as main boot loader

Chainload to boot from grub4dos for MBR

Chainload to boot from Grub2 File Manager of a1ive

Chainload to boot from Grub2 Menu of a1ive

 

On UEFI:

Using a1ve's grub2 as main boot loader

Chainload to boot from grub4dos for UEFI

Chainload to boot from Windows bootmanger

 

UEFI_MULTI

 

Useful to add WIM, ISO or VHD files to our BCDs and config menus for MBR and UEFI.

 

VHD_WIMBOOT

 

Useful to create Wimboot and Compact mode installations on VHDs and to add them to our BCDs and config menus for MBR and UEFI.

 

This three programs made by our good fellow wimb resume all the knowledge we have got here on reboot.pro about this subject, after making many experiments and test, it has being a collective effort of many of us to help wimb improve his programs.

 

After testing this programs you will be able to look carefully to all BCDs and config menus to analyze in detail its content.

 

Hope this can help you test new grub4dos for UEFI (G4E).

 

alacran



#343 Gerolf

Gerolf

    Member

  • Members
  • 67 posts
  •  
    Germany

Posted A week ago

Thank you for writing a long answer, Alacran! However, before I step through your suggestions, I still want to clear my mind from the experience I made installing Windows 11 to officially unsupported hardware, because I fear this may turn out to be the easier part, as everything was hacked and leaked within hours after Microsoft's presentation this June 24th:

https://translate.go...ot_installieren

 

Since I did not expect Windows 11 to run, I started with Windows 10 for a clean GPT/UEFI/SB installation on my testing laptop. It's a Lenovo B590 with a UEFI BIOS dating from 2013 and a 300 GB hard disk, upgraded to 8 GiB RAM to run a hypervisor. It has a non-whitelisted Intel Pentium 2020M dual core processor, no DirectX12 graphics, and no Trusted Platform Module.

 

I downloaded the Windows 10 ISO using Microsoft's Media Creation Tool and copied it to a USB stick in a bootable way with Rufus. At the laptop's boot beep, I pressed [F1] to enter the BIOS setup so that I could enable and reset Secure Boot; or [F12] for the boot drive selection, respectively. As the Windows 10 Setup refused to convert the hard disk's partition table from MBR to GPT, I had to do this with a bootable partition editor. Any Linux live distro with GParted is suitable in that case; I used the free Minitool Partition Wizard Bootable, which runs atop Tiny Core Linux. I then installed Windows 10 to a 64 GiB partition, without problems. A 100 MiB EFI system partition and a 508 MiB recovery partition were also created. One is not asked to enter a product key only after installation.

 

Then I prepared the bootable USB stick with one of the Windows 11 setup ISOs mentioned in the linked article. The simple trick to bypass the new booting obstacles imposed by Microsoft is to create this text file named BYPASS.REG, which must be copied to the USB stick:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\Setup\LabConfig]
"BypassTPMCheck"=dword:00000001
"BypassSecureBootCheck"=dword:00000001

After Windows 11 setup has booted, press [Winlogo]+[R] to open the command line, enter NOTEPAD, open the "File" dialog, right-click on BYPASS.REG and select "Merge". That way I got a running Windows 11 on a second 64 GiB partition.

 

Even funnier still was the installation experience on my other test computer, which is a desktop PC from 2008 with multiple MBR hard disks and a non-whitelisted AMD Athlon 4450e dual core processor. It does not even have UEFI (and therefore makes a candidate for the Clover UEFI emulator). In that case, on a non-GPT disk, the Windows 11 setup shall not be booted from USB. Instead, the setup.exe on it must be started from the running Windows 10, which then can be updated to the new version. I only had to increase the size of partition C: to get 64 GiB free space. Here the trick is to bypass the new hardware test by replacing the file sources\appraiserres.dll with its predecessor from the Windows 10 ISO before running setup:

https://www.windowsl...-0-requirement/
 

So now I enjoy a licensed and activated Windows 11 Home (version 21H2, build 22000.71, Windows Feature Experience Pack 421.18201.0.3) on a dinosaur machine that fails on every of the postulated new hardware requirements. And I would expect Microsoft to suffer a major backlash on social media should such installations be rolled back to Windows 10 later this year when its successor gets officially launched.



#344 alacran

alacran

    Gold Member

  • .script developer
  • 2111 posts
  •  
    Mexico

Posted A week ago

Yes my friend, I'm aware of the tricks to install Win11, in fact your reg file lacks the following:

 

[HKEY_LOCAL_MACHINE\SYSTEM\Setup\LabConfig]
"BypassTPMCheck"=dword:00000001
"BypassSecureBootCheck"=dword:00000001
"BypassRAMCheck"=dword:00000001        <<<---  And it will boot on low Ram equipments too.
"BypassStorageCheck"=dword:00000001    <<<---  This may be usefull too.

 

Also by the way the best version of appraiserres.dll you can use is from a 1703 ISO.

 

Easier methods for a clean install is just make a USB device for Win10 Installation replacing the install.wim, other alternatives may be booting from a PE to install it using WinNTSetup (it will let you apply many reg tricks including your own), or using Wimlib, Dism or ImageX.

 

But to be honest I'm not interested in testing Win11, it is same thing as Win10 with very minor (aesthetic majorly) changes, with a new name (old marketing trick), plus artificially added limitations (to make people buy new PCs), and it is still in Beta stage.

 

alacran



#345 Gerolf

Gerolf

    Member

  • Members
  • 67 posts
  •  
    Germany

Posted A week ago

I, too, surely wasn't curious for those rounded window corners, the flickering task bar, or the crashing context menus in Explorer. However, for another project, I had to check out whether old MSHTA.EXE, the Microsoft Hypertext Application host (which is great for rapid prototyping), would still be running after retirement of Internet Explorer (it does).
 
In the meantime I downloaded my desired x86-64 Tumbleweed ISO, prepared a bootable USB stick with it, and started the Linux setup called Yast. SUSE's partitioner revealed that the prior Windows setup also had created a "Microsoft Reserved Partition" of 16 MiB that Windows Disk Manager does not show. For Linux, I created a third 64 GiB partition to mount as root and also mounted the existing EFI partition. No problems occurred. Yast installed Grub2 with a menu item to chainload BootMGR, so that I can successfully secure-boot to both Windows and Linux on my testing laptop. The recognizable difference is the "Lenovo" banner being shown while secure-booting.

 

And now, as said, I want to install Grub4DOS for UEFI to the GPT hard disk, to be chainloaded from SUSE's Grub2 menu.



#346 alacran

alacran

    Gold Member

  • .script developer
  • 2111 posts
  •  
    Mexico

Posted A week ago

Well let me doubt your old laptop is in fact booting 11 using Secure Boot (Which was incorporated to UEFI specs v3.21):

 

The Registry trick "BypassSecureBootCheck"=dword:00000001 you used, is to avoid SB check.

 

About:

 

The recognizable difference is the "Lenovo" banner being shown while secure-booting.

 

That only means you are booting in UEFI, that image is saved on NVRAM, when I boot with SB disabled I also see the OEM image.

 

So to be sure I suggest you to boot from Win11 and run BootIce and select UEFI tab, see this pictures taken from the topic Testing UEFI booting on a only Bios PC on first post, first picture is if you did not boot from at least UEFI v2.31, second is if booted from a UEFI v2.31 or higher.

 

alacran

Attached Thumbnails

  • NOT v2.31.png
  • v2.31 or higher.png


#347 alacran

alacran

    Gold Member

  • .script developer
  • 2111 posts
  •  
    Mexico

Posted A week ago

Anyway just for testing purposes, even if I'm 99% sure it will not work if SB is enabled, maybe it can work with disabled SB.

 

Following is the entry in my a1ve's grub2 config file to load/run G4E, (taken from my USB device made using USB_FORMAT)

 

    if [ -e "/efi/boot/bootx64_g4d.efi" ]; then
    menuentry "UEFI Grub4dos x64 - /efi/boot/bootx64_g4d.efi" {
      chainloader /efi/boot/bootx64_g4d.efi
    }
    fi

 

Where bootx64_g4d.efi is BOOTX64.EFI from G4E renamed to bootx64_g4d.efi and copied to \EFI\Boot folder located on the EFI partition where Win boot files/folders reside.

You need to create a new entry in your grub.cfg adapting this entry to your case, using as a guide the current entry on your grub.cfg for Win. 

 

NOTE: To future readers: Gerolf commented in a previous post his preferred distro (openSUSE Tumbleweed) has a GUI tool (YaST) to edit the grub.cfg file. Please don't ask how to edit grub.cfg file, as each distro has its own way to automatically create its grub.cfg file, and it is known direct manual edition very frecuently do not work, as it is usually auto-repaired on next boot, (so better google for info about this for your own case).

 

Also (if not present) you need to create \EFI\grub folder just next to the \EFI\Boot folder located on the EFI partition where Win boot files/folders reside, and your menu.lst for G4E has to be located into that \EFI\grub folder.

 

You can use following commands on your menu.lst to load/run Win from G4E:

 

title Windows EFI BootManager - chainloader /EFI/Microsoft/Boot/bootmgfw.efi
find --set-root /EFI/Microsoft/Boot/bootmgfw.efi
chainloader /EFI/Microsoft/Boot/bootmgfw.efi

Good luck with this experiment.  And don't forget to comment back the results.

 

alacran


  • Gerolf likes this

#348 Gerolf

Gerolf

    Member

  • Members
  • 67 posts
  •  
    Germany

Posted A week ago

That only means you are booting in UEFI, that image is saved on NVRAM, when I boot with SB disabled I also see the OEM image.

Right. It was just after I enabled Secure Boot that I first noticed the "Lenovo" banner instead of the -- now rectangular -- blue Windows logo atop of the circling dots, before the Windows 10/11 selection screen appears. But this did not change back when I disabled Secure Boot temporarily for a test.

 

Well let me doubt your old laptop is in fact booting 11 using Secure Boot (Which was incorporated to UEFI specs v3.21):

 

The Registry trick "BypassSecureBootCheck"=dword:00000001 you used, is to avoid SB check.

Wrong. These bypasses do not make it into the registry of the running system after setup. Regedit does not show any "HKEY_LOCAL_MACHINE\SYSTEM\Setup\LabConfig" handles.

 

So when I run Bootice under Windows 11 (using the recommended version 1.3.3.2), I do in fact see the dialog to edit UEFI boot entries, like on your second image. Excerpts:

Menu title: Windows Boot Manager
Boot part:  0: (FAT32, 100.0 MB, ESP)
Media file: \EFI\Microsoft\Boot\bootmgfw.efi

Menu title: opensuse-secureboot
Boot part:  0: (FAT32, 100.0 MB, ESP)
Media file: \EFI\opensuse\shim.efi

Now you suggest that Grub2 cannot chainload "Grub4EFI" in Secure Boot mode:

 

Anyway just for testing purposes, even if I'm 99% sure it will not work if SB is enabled, maybe it can work with disabled SB.

 

Following is the entry in my a1ve's grub2 config file to load/run G4E

 

How could such a behaviour be achieved? Do I have to imagine Secure Boot as some spooky background process that hinders my startup binaries from doing what I want? Isn't it that those binaries, on the contrary, have to be compliant and actively check whether Secure Boot is enabled, calling a "UEFI interrupt" or looking up a specific memory address? Do you think Linux distributors have been forced to modify code of Grub2, so that it can only chainload signed binaries in Secure Boot mode, in order to get their certification by Microsoft?

 

The Debian Wiki states that only the first-stage bootloader Shim required this certification. An unmodified Grub2 then should be able to chainload legacy systems, escaping those restrictions Microsoft implemented in Bootmgfw. Sham, uh, "Shim is the root of trust", I'll write it on the walls in golden letters.



#349 alacran

alacran

    Gold Member

  • .script developer
  • 2111 posts
  •  
    Mexico

Posted A week ago

OK, so in fact your Win 11 is booting in UEFI + Secure Boot Enabled.

 

Just test booting and you will see if it can boot on SB enabled or not.

 

alacran



#350 alacran

alacran

    Gold Member

  • .script developer
  • 2111 posts
  •  
    Mexico

Posted A week ago

Just to answer your statement here:

 

The Debian Wiki states that only the first-stage bootloader Shim required this certification. An unmodified Grub2 then should be able to chainload legacy systems, escaping those restrictions Microsoft implemented in Bootmgfw. Sham, uh, "Shim is the root of trust", I'll write it on the walls in golden letters.

 

Better don't spend your money on the golden paint.

 

That's not right, sorry but you are wrong, Shim is signed by MS and following files in UEFI boot chain have to be signed with Devian key in your specific case, see this quote from: https://wiki.debian....SecureBoot#Shim

 

 

Secure Boot limitations

By its very design, SB may affect or limit some things that users want to do.

If you want to build and run your own kernel (e.g. for development or debugging), then you will obviously end up making binaries that are not signed with the Debian key. If you wish to use those binaries, you will need to either sign them yourself and enrol the key used with MOK or disable SB.

Using SB activates "lockdown" mode in the Linux kernel. This disables various features that can be used to modify the kernel:

  • Loading kernel modules that are not signed by a trusted key. By default, this will block out-of-tree modules including DKMS-managed drivers. However, you can create your own signing key for modules and add its certificate to the trusted list using MOK.

  • Using kexec to start an unsigned kernel image.
  • Hibernation and resume from hibernation.
  • User-space access to physical memory and I/O ports.
  • Module parameters that allow setting memory and I/O port addresses.
  • Writing to MSRs through /dev/cpu/*/msr.

  • Use of custom ACPI methods and tables.
  • ACPI APEI error injection.
You can avoid this by disabling Secure Boot through the EFI setup program or through MOK.

 

So as G4E boot loader is not signed with a Devian Key it will not load/run when Secure Boot is enabled.

 

Don't worry so much about the bad named "Secure Boot" it do not make a PC more secure (that's just a bad joke), the only thing Secure Boot protects is MS pockets, now everybody has to pay them BIG MONEY to get a "Trusted Certificate" to be able to run the Software, drivers, etc., on Win, (they just copied Acer and Google with its Android), as a protection tool it is good for nothing, all modern virus and ransomware laugh about SB, and are infecting more PCs than never in history, don't just believe and repeat what the payed people say, think by yourself, all this is related to money, nothing else.

And if you feel you have more privacy, security or safety using a Linux distro, read this old article from 2012: Richard Stallman calls Ubuntu “spyware” because it tracks searches.

 

Also maybe you don't know MS is a Platinum Member of Linux Fundation and a very big contributor since 2016, why? to gain control there too. Money is the key word for all the companies nothing else.

See: https://techcrunch.c...nux-foundation/

 

By the way, as your old Laptop is a Lenovo, were you aware about Lenovo scandal some years ago?: https://slate.com/te...w-ups-ever.html

 

 

By installing a single self-signed root certificate (trust me: That’s really bad) across all of Lenovo’s affected machines, Superfish intentionally pokes a gigantic hole into your browser security and allows anyone on your Wi-Fi network to hijack your browser silently and collect your bank credentials, passwords, and anything else you might conceivably type there. As Errata Security’s Robert Graham put it, “I can intercept the encrypted communications of SuperFish’s victims (people with Lenovo laptops) while hanging out near them at a cafe wifi hotspot.” If you have a Lenovo laptop that has Superfish on it (try Filippo Valsorda’s Superfish test to see), I would advise nothing short of wiping the entire machine and installing vanilla Windows—not Lenovo’s Windows. Then change all of your passwords.

 

So a key sign or certificate also means nothing in security or safety terms, if ANY company can include its own signed malware in their products, to spy its customers.   All is about money.

 

alacran






9 user(s) are reading this topic

0 members, 9 guests, 0 anonymous users