Jump to content











Photo
- - - - -

Experiments on GPT/UEFI with grub4dos, grub2, grub4EFI


  • Please log in to reply
30 replies to this topic

#1 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 20 July 2021 - 12:00 PM

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

#2 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 20 July 2021 - 05:05 PM

@ 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



#3 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 20 July 2021 - 09:33 PM

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.



#4 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 20 July 2021 - 10:16 PM

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



#5 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 21 July 2021 - 02:34 AM

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.



#6 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 21 July 2021 - 05:08 AM

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


#7 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 21 July 2021 - 06:30 AM

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

#8 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 22 July 2021 - 02:08 AM

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.



#9 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 22 July 2021 - 03:42 AM

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



#10 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 22 July 2021 - 04:40 AM

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



#11 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 23 July 2021 - 04:34 AM

This Lenovo laptop was sold as new, for little money, and without Windows, by a renowned German notebook shop site. It came with pre-installed FreeDOS, giving the out-of-box experience of a 1980s IBM AT. But that was not because of the Superfish adware shit, which happened later, in 2014. I did not know this story; instead, I was curious whether my machine would be one of those "Lenovo computer models with Secure Boot [that] had firmware that was hardcoded to allow only executables named 'Windows Boot Manager' or 'Red Hat Enterprise Linux' to load, regardless of any other setting" (it isn't).

 

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

 

Maybe I should attach emojis to remarks that are meant ironically, but it's funnier for me if I don't. Of course I'm on your side, Alacran, with your criticism of the Secure Boot approach, because booting should become easier, not harder. Also, my initial quoting of Zammibro's complaint (in post no. 341) does not mean that I'm complaining too. I just try to analyze, like: If the malware people laugh about Secure Boot being enabled, then why don't we? I want to know how we can live with it.

By the way,  the Chinese site A1ive and you referred to freqently is either offline now or inaccessible from Germany, even with Tor browser. I probably missed important basic information from there, so it would be nice if someone could upload a backup of that material to a, well, "secure" location.

 

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

 

SUSE Linux gained a little popularity in Germany during the time when Windows still struggled with stability problems. During the past 23 years, I frequently created the classical dual-boot scenario (which I only adopted here for GPT/UEFI/SB) on various machines, and while SUSE Linux never was considered a "cool" distro like Ubuntu, I'm amazed how its installation procedure runs smoother and faster with every year.

SUSE's YaST not only is "Yet another Setup Tool" but also a comprehensive control center for system administration like the one (or two) you are used to on Windows but somehow cannot find on other Linux distros. For instance, its boot manager configuration GUI allows to install another bootloader (Grub2 or Grub2 for EFI) even after setup is already finished. A few options like Secure Boot support or the default operating system can be changed, but a dialog to add further menu entries is missing -- no wonder as grub.cfg is a shell script of quite some complexity rather than a configuration file.

It is correct that grub.cfg gets rebuilt automatically from fragments located elsewhere. I still have to study the mechanism and to use the Grub2 command line meanwhile. I see a new "Grub4EFI" build just arrived; I had downloaded the previous one a few days ago. The EFI partition gets mounted to /boot/efi/EFI and has subfolders Microsoft and opensuse. I opened the file manager in supervisor mode, created a subfolder Grub4EFI and copied the file BOOTX64.EFI from the extracted archive to it. Then I secure-booted to Grub2, opened the command-line and entered:

chainloader (hd0,gpt1)/EFI/Grub4EFI/BOOTX64.EFI
boot

And then it really did show up, with its title line "GRUB4DOS for_UEFI 2021-06-19". (I haven't made any further experiments with it yet, I'm getting tired now.)

You quoted the sentence "Using SB activates 'lockdown' mode in the Linux kernel" from the Debian Wiki and concluded:

 

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

 

Only that Grub2 which I used here for chainloading "Grub4EFI" obviously does not include a Linux kernel or any other code that is responsive to Secure Boot mode. I understand the Debian Wiki such that only the first-stage bootloader Shim, the "root of trust", then kills the next binary to be chainloaded if that file is not signed. But that's not the case for openSUSE's Grub2, and Shim neither knows nor cares what Grub2 will do later.

So my answer to Zammibro's complaining question ("How to add this thing to a Windows PC?") would be, in a nutshell and still incomplete: Create a dual-boot scenario with a "trusted" Linux distro to get a signed Grub2 installed, and then modify its configuration to chainload "Grub4EFI" and your other cool "untrusted" stuff. You don't trust my reporting? C'mon, you'll find a spare computer to reproduce this experiment.



#12 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 23 July 2021 - 06:39 AM

It is correct that grub.cfg gets rebuilt automatically from fragments located elsewhere. I still have to study the mechanism and to use the Grub2 command line meanwhile. 

 

That "feature", that is in my personal opinion one of the stupidest things ever made by humans[1], is AFAIK mis- or under- documented, the only place where I could find an understandable explanation is here, jFYI, on dedoimedo's:

https://www.dedoimed...ers/grub-2.html

https://www.dedoimed...#mozTocId226706

 

:duff:

Wonko

 

[1] not the general idea in itself, but the fact that in practice it makes difficult to "mantain" a valid "customized" grub.cfg in case of updates/changes to the system.


  • alacran and Gerolf like this

#13 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 23 July 2021 - 07:54 AM

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?

 

 

UEFI Secure Multi-Boot of Windows 10 and Linux in VHD using Grub2 and viskchain was realised and described in

 

How to make Linux VHD for Multi-Boot with Windows using Grub2 and vdiskchain

 

in VHD_WIMBOOT PDF page 10 and 11 (Experts Only if you know what you are doing ....)


  • alacran and Gerolf like this

#14 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 23 July 2021 - 08:12 PM

@ Wonko

 

Good info, thanks, it may very useful for future readers too.

 

alacran



#15 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 28 July 2021 - 01:49 AM

To resume my previous postings (no. 341 ff.) concerning:

Secure-Boot Installation of Grub4DOS for UEFI on Internal GPT Disk

Zammibro asked (post no. 285):

How to add this thing to a Windows PC?

I answered (post no. 351):

Create a dual-boot scenario with a "trusted" Linux distro to get a signed Grub2 installed, and then modify its configuration to chainload "Grub4EFI" and your other cool "untrusted" stuff.

 

1. GPT partitioning: post no. 343

 

A 120 GB solid state disk should be sufficient for this experiment.

 

2. Windows 10/11 installation: ditto

 

The minimum partition size for Windows 10 is 32 GiB officially, out of which it uses 20 GiB. Windows 11 wants to have 64 GiB and uses 26 GiB. Thus, if Windows 11 is installed as an update to Windows 10 in order to bypass the newly introduced hardware requirements test, the partition should have at least 84 GiB, which can be reduced after installation.

 

3. openSUSE Tumbleweed installation: post no. 345

 

The recommended partition size for this rolling release is 48 GiB, but only 8 GiB will be used in the default setup with KDE Plasma desktop (which already looks like Windows 11 for quite some time, except that the Start button doesn't move to another position whenever you start or close an application). So you can squeeze it onto a small partition if you only need it for an automated and manageable installation of a secure-bootable Grub2 for EFI.

 

4. "Grub4EFI" installation

 

Download and extract the latest version of Grub4DOS for UEFI to, say, USB drive U:. Since its menu.lst has to go to the /EFI/grub folder of the EFI system partition, copy its binary BOOTX64.EFI to the same location (instead to /EFI/Grub4EFI like in my previous post no. 351), without renaming. (Even that way, a confusion with Grub legacy, which won't get a UEFI update, or Grub2, which won't read menu.lst, should not occur.)

To install "Grub4EFI" under Windows, open a command prompt window as administrator and enter:

mountvol E: /s  
md E:\EFI\grub
copy U:\menu.lst E:\EFI\grub
copy U:\BOOTX64.EFI E:\EFI\grub

The first command mounts the EFI system partition as volume E: but it still won't show up in File Explorer. Under Linux you have to open the file manager in supervisor mode to access this partition, which gets mounted to /boot/efi/EFI in openSUSE.

 

5. Customize "Grub2EFI" menu to add "Grub4EFI"

Sometimes I like to play with stupid things, see my PC Emulator test a few weeks ago, before the new Windows 11 got me: Now, I can better tell one white window from the other in case of overlap, but when I right-click on the name of a file on hard disk, I only hear the DVD drive rattle, and the context menu just pops up and collapses. It may stay open on the second right-click-and-rattle. Or the third. Sometimes it helps to also press [Context Menu] on the keyboard. Or to restart File Explorer.  

But this improves over the weeks, updates are underway. They get installed with a message that just sounds offensive, at least to German ears, somehow alleging you're still recovering from blue cabbage hangover: We give you an "Estimated time: 5 Minutes" until "You are 100% there." And now for my next proposal, dealing with a menu that gets rebuilt automatically from fragments.

Wonko said (post no. 352):

That "feature" (...) is in my personal opinion one of the stupidest things ever made by humans (...) not the general idea in itself, but the fact that in practice it makes difficult to "mantain" a valid "customized" grub.cfg in case of updates/changes to the system.

That feature does make sense for a rolling release like Tumbleweed, which can update its own grub.cfg fragments without losing those you have added for customization. The "stupid" thing is that grub.cfg wouldn't be necessary at all because Grub2 might as well run the menu builder fragment collection at boot time. The grub.cfg script introduces redundancy in order to reduce the time to boot to the menu. A user won't know the former but might notice the latter. And doesn't the update problem haunt you with a menu.lst too?

The menu configuration script /boot/grub2/grub.cfg gets rebuilt whenever any change, like selecting another default menu entry, is done to the boot manager's settings via YaST GUI. As indicated in a comment at the beginning of grub.cfg, you can also trigger this manually, entering the supervisor command

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

(Other distros have

sudo update-grub

which is not mentioned in the Grub2 manual.)

 

The menu builder fragments are collected in /etc/grub.d and named

00_header
00_tuned
10_linux
20_linux_xen
20_memtest86+
30_os-prober
30_uefi_firmware
40_custom
41_custom
80_suse_btrfs_snapshot
90_persistent
95_textmode

Called by grub2-mkconfig, they run in the order of their numbering, with the executable bit being used to enable or disable individual fragments (see Dedoimedo's Grub2 tutorial).
 
The 30_os-prober script detects the Windows Boot Manager. Next year, Tumbleweed may replace it with a buggy update to also find "Grub4EFI", but won't do no harm to your own customized menu entry script (named 09_grub4efi to be listed first, compare Alacran's proposal in post no. 347):

#!/bin/sh -e
# /etc/grub.d/09_grub4efi
# lines between EOF marks go into /boot/grub2/grub.cfg
cat << EOF
  menuentry "Grub4EFI" {
    set file=/EFI/grub/BOOTX64.EFI
    search --file --set root \$file
    chainloader \$file
  }
EOF

This file must be saved in Unix format if created under Windows. On Linux, drop it into the /etc/grub.d folder and change its file mode to "executable" under "Permissions" in the file manager's context menu or, in a terminal window, with the supervisor command

sudo chmod +x /etc/grub.d/09_grub4efi

6. Customize "Grub4EFI" menu to add "Grub2EFI" and BootMGFW

 

Once "Grub4EFI" shows up, system administrators can focus on maintaining, updating, bloating, fragmenting, and auto-rebuilding their own customized /EFI/grub/menu.lst. Essentially, it looks like this, sporting entries to switch to the other two UEFI boot managers (compare posts no. 1 by A1ive and no. 336 by Alacran, and note the DOS/Linux-style syntax differences to the above menu entry definition for Grub2):

# /EFI/grub/menu.lst  
default 0
timeout 10
    
title Grub2EFI\n openSUSE Tumbleweed
set file=/EFI/opensuse/grubx64.efi
find --set-root %file%
chainloader %file%
  
title BootMGFW\n Microsoft Windows 10/11
set file=/EFI/Microsoft/Boot/bootmgfw.efi
find --set-root %file%
chainloader %file%

title Commandline
commandline

title Reboot
reboot

title Halt
halt    

7. Customize BootMGFW menu to add "Grub4EFI" to "Grub2EFI"

 

Sorry, here comes a spoiler: This will fail at the end, despite a promising start. Run Bootice under Windows (using the recommended version 1.3.3.2) and open the dialog to edit UEFI boot entries (like on the second image in Alacran's post no. 346). Bootice retrieves the following Boot Configuration Data from the Windows Boot Manager's store (see post no. 348):

# all entries:
Boot disk:  HDD: ST ... (300 GB, C: D:)
Boot part:  0: (FAT32, 100.0 MB, ESP)

Menu title: Windows Boot Manager
Media file: \EFI\Microsoft\Boot\bootmgfw.efi

Menu title: opensuse-secureboot
Media file: \EFI\opensuse\shim.efi

So openSUSE successfully inscribed itself to the BCD store during its installation, with the first-stage bootloader Shim being the "root of trust" for secure-booting Grub2 (post no. 341). We can take the above UEFI boot menu entries as templates to add a third one for "Grub4EFI" (the required dialog would not open in the last version 1.3.4.0 of Bootice):

Menu title: Grub4EFI
Media file: \EFI\grub\BOOTX64.EFI

But it's all in vain: BootMGFW doesn't show those entries to boot openSUSE's Shim or our "Grub4EFI", not even in non-Secure Boot mode, and thus turns out to be a real "Boot Manager for Windows (only)".
 

 

8. Start from scratch on GPT disk

 
Here I also talk about the creation of a stable testbed for fast hypervisors which make use of hardware-assisted virtualization, so that you can run two modern operating systems at the same time. Windows 10 and 11 bring Hyper-V, which can even be enabled on the Home Edition, while openSUSE, unlike other Linux distros, comes with pre-installed Xen hypervisor.

 

I said (post no. 351):

C'mon, you'll find a spare computer to reproduce this experiment.

Alacran said (post no. 355):

My test machine layout is: (...) HD-0 is MBR formated (...) HD-1 MBR formated

In 2005, the year he lost his re-election bid, German chancellor Gerhard Schroeder introduced "One-Euro-Jobs". His beloved successor, Angela Merkel, introduced and slowly raised minimum wage such that today, after she became re-elected again and again and again, for about two hours of work one can afford a brand-new solid-state disk of at least 120 GB, which is already the smallest available size, and if one takes into consideration the time needed for system re-installation or backup and restore, it might be reasonable to just exchange a suitable and running test computer's internal disk for this experiment without increasing one's stakes too much.

 


#16 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 28 July 2021 - 10:24 AM

@Gerolf

The issue is/was that a number of distro's periodically change (changed?) the (stupid) name of the kernel when updating, and ran "update-grub" (or whatever) in order to ONLY modify that particular kernel name, and in case the grub.cfg had been manually modified and/or the series of script was (by accident or whatever) "wrongly" made, this caused the whole grub.cfg be rebuilt from scratch, with (often) making other entries disappear or be no longer valid...

 

Since the mechanism of the scripts and the behaviour of the various distro's is not well (or at all) documented/advertised in the "basics" (as said the only place where I could find an easy, understandable explanation was dedoimedo's), and it is (AFAIK) "new" to GRUB2, I have seen grown men cry after having updated a distro and finding not anymore a numebr of (directly) added entries in grub.cfg.

 

Your mission, should you accept it, is to replace in a plain txt file the word "kernel123" with the word "kernel234", which approach would you take:
1) just replace that d@mn string
2) rebuild the whole file from bits and pieces WITHOUT warning the user
3) rebuild the whole file from bits and pieces warning the user BEFORE doing it and - in any case - make a backup copy of the current grub.cfg

 

The issue is with the choice #2 that was taken. 

 

:duff:

Wonko 


  • Gerolf likes this

#17 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 30 July 2021 - 03:49 PM

If a system wants to be cool, it has to hide its complexity, see Windows 10: Its installation feedback messages are of the utmost triviality. Users or admins always have their own problems. Why bother them with a warning, something dangerous may happen right now, but a backup will be created?

I see Grub2's updating issues as being caused by some kind of information redundancy between the input fragments and the output "configuration file". The fragments, however, add at least one layer of complexity, as code must be added to write the relevant information to the end of grub.cfg. Thus admins are tempted to think: "Oh, I better hack that file", whose creation I would rather avoid at all. But no grown man should cry if he has "customized" a file that starts with a warning: "Don't hack me, I'll be overwritten."
 


Edited by Gerolf, 30 July 2021 - 03:51 PM.


#18 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 30 July 2021 - 09:26 PM

Under the rules of Grub2, however, we are allowed to create, at a location that won't be overwritten, an additional, customized \EFI\grub2\grub.cfg that gets loaded when selecting an entry written by a standard menu builder fragment /etc/grub.d/49_custom_menu defined as follows:

#!/bin/sh -e
# /etc/grub.d/49_custom_menu
# this file must have Unix-style line endings and be made executable
# lines between EOF marks go into /boot/grub2/grub.cfg when running
# sudo grub2-mkconfig -o /boot/grub2/grub.cfg
cat << EOF
  menuentry "More ..." {
    set file=/EFI/grub2/grub.cfg
    search --file --set root \$file
    configfile \$file
  }
EOF

To replace the /etc/grub.d/09_grub4efi fragment proposed in section 5, our customized \EFI\grub2\grub.cfg has to look like this (compare sample and tutorial):

# \EFI\grub2\grub.cfg
# /boot/efi/EFI/grub2/grub.cfg
set timeout=10
set default=0

menuentry "Grub4EFI" {
  set file=/EFI/grub/BOOTX64.EFI
  search --file --set root $file
  chainloader $file
}

menuentry "Reboot" {
  reboot
}

Use arrow keys to reach hidden menu entries. Now guess what solution openSUSE suggests in the /etc/grub.d/41_custom fragment.

Spoiler


Edited by Gerolf, 30 July 2021 - 09:29 PM.


#19 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 31 July 2021 - 02:11 AM

In my installation, at the Grub2 prompt, the "set" command shows that the environment variable $config_directory is empty, while $prefix is set to "(hd0,gpt6)/boot/grub2". Thus openSUSE's /etc/grub.d/41_custom expects your custom menu as /boot/grub2/custom.cfg on the Linux partition, which might get re-formatted when the system must be re-installed, so that we better load the actual customization from the EFI system partition:

# /boot/grub2/custom.cfg
menuentry "More" {
  set file=/EFI/grub2/grub.cfg
  search --file --set root $file
  configfile $file
}

That way, we won't have to create and activate any menu builder fragment scripts in Unix format. To prevent tears over a non-booting Linux in case of a misconfiguration, you can install it to an ext3 file system, which is accessible from Windows using the ext2fsd driver. Also, to navigate the EFI system partition under Windows, enter the command "mountvol E: /s" and open 7-Zip File Manager 7zFM.exe in administrator mode.



#20 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 31 July 2021 - 03:42 AM

To stop being locked out from KDE Plasma every five minutes without enough clicking activity, change "Settings/System Settings/Workspace Behavior/Screen Locking". Now that the issue with /boot/grub2/grub.cfg being overwritten automatically seems to be solved with the help of another bypass, I am curious to install Chenall's Universal Master Boot Record in order to also boot Grub4DOS on GPT disk, like in Doveman's dual-boot scenario with Linux-based LibreElec.



#21 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 05 August 2021 - 03:15 AM

So resuming my previous postings (no. 341 ff., especially no. 368 to no. 373), let's have a closer look on how to deal with those concepts that are "veraltet":

 

9. Grub4DOS installation on GPT disk

 

Misty said:

I have not been keeping track of Grub4dos development. I had mistakenly believed that Grub4dos is not able to access GPT type disks. I was very pleasantly surprised to find that this is not the case.

 

This does not mean, however, that we could simply chainload Grub4DOS from "Grub4EFI", with the firmware set to UEFI mode. Such an attempt would throw "Error 13: Invalid or unsupported executable format". In legacy mode, however, the BIOS does not find any code in the "protective" Master Boot Record, the first sector of the disk, to load grldr. We also cannot use bootlace to install the required grldr.mbr because that file is 16 sectors large and would overwrite the beginning of the GUID partition table.

 

While the big grldr.mbr can read file systems and thus is able to find grldr in the root folder of any partition of any drive, it is at least possible to squeeze some small code into a single-sector MBR that can at still load a non-fragmented grldr from a known address on the disk. That's the purpose of Chenall's Universal Master Boot Record. The provided umbr binary, which runs at the commandline of Grub4DOS (not "Grub4EFI"), can be seen as an alternate installer for Grub4DOS. Here's the syntax.

Spoiler

 

Download umbr and the latest Grub4DOS legacy archive. Under Windows, having booted in UEFI mode, copy umbr and the extracted grldr to S:\, the root of the EFI system partition, just outside of the EFI folder, if that volume is mounted with the administrator command

mountvol S: /s

(different from the example in section 4 of my post no. 368, because drive letter E: is typically assigned to a USB drive when C: and D: are already used for Windows 11 and 10). Then switch the firmware to legacy BIOS mode and boot from a Grub4DOS-bootable USB stick (prepared with e.g. Rufus; it does not matter if it has an older grldr). At the commandline, you get the following feedback when entering commands to switch root to the internal drive and install the new grldr with the umbr command:

grub> echo  %@root%
 (hd0,0)
grub> find --set-root /umbr
 (hd1,0)
grub> root
 (hd1,0) Filesystem type is fat32, partition type is 0xFE
grub> ls
 EFI grldr umbr
grub> geometry
drive 0x80(LBA): C/H/S=38914/255/63, Sector Count/Size=625142448/512
   Partition num: 0,  Filesystem type is fat32, partition type 0xEE  <= ESP
                                                                     <= Microsoft Reserved Partition
   Partition num: 2,  Filesystem type is ntfs, partition type 0xEE   <= Windows 10
   Partition num: 3,  Filesystem type is ntfs, partition type 0xEE   <= Microsoft Recovery Partition
   Partition num: 4,  Filesystem type is ntfs, partition type 0xEE   <= Windows 11
   Partition num: 5,  Filesystem type is ext2fs, partition type 0xEE <= openSUSE Tumbleweed
grub> umbr -d=1 -p=0 --test /grldr 
 [0]:/grldr
         success:[ffffeb84]
 [3]:(129,1)+1

If you repeat the last command without the "--test" switch, a few bytes of code to jump to the grldr's address are written to the "protective" MBR. Now we can boot the machine in BIOS mode, without an attached USB stick, and successfully get to the prompt of the latest Grub4DOS. This will work until the day you update grldr, because the new one will be copied to another address. Thus later this must be repeated, and we should prepare a fallback to make the system partition (-d=1 -p=0) legacy-bootable in case grldr cannot be found.
 

Next let's try to get Windows booted in BIOS mode from Grub4DOS. First, I have to copy the file bootmgr from the legacy Windows 10/11 installation of my desktop computer (post no. 343) because it cannot be found on the UEFI installations on the laptop. That file also goes to S:\, the root of the system partition, outside of the EFI folder. Chainloading bootmgr from Grub4DOS works, but bootmgr says: "Windows failed to start. File: \Boot\BCD". The Boot Configuration Data store is still missing! But there is a standard solution to this problem:

 

Wonko said:

If I were you, I would try booting to the Windows 10 in UEFI mode, mount the ESP partition to a drive letter and then re-run bcdboot with the suitable options:

  BCDBOOT C:\WINDOWS /s <drive letter> /f BIOS 

see for reference:
https://docs.microso...ions-techref-di

 

Let's do it:

C:\> mountvol S: /s
C:\> bcdboot C:\WINDOWS /s S: /f BIOS 
Failure when attempting to copy boot files

And that's because there's only 1 MiB of space left on the 100 MiB EFI system partition, as 7-Zip File Manager tells me, although the command "dir S:" reports nearly 8 GiB of free space. That seems to be a "protective" misinformation, reminding of the 8 GiB disk size limit of old BIOSes, which could only address 1024 cylinders * 256 heads * 63 sectors * 512 bytes = 8064 MiB. So the disk must be re-partitioned, shifting all partitions but the first to higher addresses.

 

This should be done with GParted on a Linux live distro, because when running under the installed openSUSE, GParted cannot move the Linux partition. Minitool Partition Wizard, on the other hand, refuses to move the Microsoft Reserved Partition for free. After I had increased the size of the EFI system partition to around 7.8 GiB, and repeating the above commands, bcdboot acknowledged: "Boot files successfully created". But Windows still didn't boot in legacy mode; simply chainloading bootmgr instead caused a reboot.

 

Wonko said:

the hard disk partition mapped to floppy should work even if - for whatever reasons - there are issues with bootmgr on the GPT partition, as the "virtual" (fd0) thus created will be only a "volume".

 

So I adapted Wonko's proposed command sequence as follows for Grub4DOS's menu.lst on the root of the EFI system partition:

# /menu.lst  
default 0
timeout 10

title BootMGR\n Microsoft Windows 10/11\n Legacy Mode
set file=\bootmgr
find --set-root %file%
map %@root%+1 (fd0)
map --hook
root (fd0)
chainloader %file%

title Commandline
commandline

title Reboot
reboot

title Halt
halt   

with %@root%+1 returning (hd0,0)+1 as the whole EFI system partition that gets mapped to virtual floppy (fd0). That way I can successfully boot Windows in legacy mode, a fact that is reported by the output of the msinfo32 command. Note that the EFI system partition cannot be mounted with the mountvol command any longer. You can assign drive letter S: to it using Minitool Partition Wizard and then edit the menu saying "notepad S:\menu.lst", but for 7-Zip File Manager, access is denied.

 

I have increased the FAT32 EFI system partition to nearly 8 GiB because I am curious to use it with legacy systems. There is even a small UEFI-bootable operating system that wants to be placed exactly there.

Spoiler


#22 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 05 August 2021 - 09:28 AM

The usual caveat with UMBR applies.
Since the grldr extents are hardcoded if you move or update it (or in some cases if you defrag the volume where grldr is) UMBR won't be able to find it anymore and you need to re-run the UMBR "install".

 

In this aspect my alternate (and half-@§§ed) approach:

http://reboot.pro/in...=19516&p=197691


is (maybe) "better" in the sense that while the extents for the underfloppy are hardcoded, the image is in a rather "protected" area and since the grldr is found (inside the underfloppy) by "normal" means (normal code of the grub4dos bootsector), grldr can be updated without need to change the MBR.

 

Please understand how at the time the method was devised to have a GPT disk boot to Windows WITHOUT any change to the visible filesystems/volumes, in a case where it is possible to write the BOOTMGR and the \boot\BCD to the "normal" ESP partition/volume, all is needed in the underfloppy is the grldr (it has to be tested, but also the menu.lst could go in the ESP)

 

:duff:

Wonko



#23 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 08 August 2021 - 11:54 PM

Typo correction for my previous post (no. 378):

 

# /menu.lst 
# (...)
title BootMGR\n Microsoft Windows 10/11\n Legacy Mode
set file=/bootmgr

# (...)

 

Concerning the reliability of the UMBR concept, I said there:

 

This will work until the day you update grldr, because the new one will be copied to another address. Thus later this must be repeated, and we should prepare a fallback to make the system partition (-d=1 -p=0) legacy-bootable in case grldr cannot be found.

 

Wonko agreed (post no. 379):

 

The usual caveat with UMBR applies.
Since the grldr extents are hardcoded if you move or update it (or in some cases if you defrag the volume where grldr is) UMBR won't be able to find it anymore and you need to re-run the UMBR "install".

 

But grldr can indeed be moved, updated, or defragmented if it is called by grldr.mbr, which in this case has to be installed to a safe space, and there is one: the 32 sectors at the beginning of the FAT32 EFI partition that are reserved for legacy bootloaders. The existing code there won't be required to start bootmgr because that file will be chainloaded directly from the Grub4DOS menu.

 

Extract and copy bootlace.com (the installer for grldr.mbr) from the Grub4DOS archive to the root of the EFI system partition. This binary cannot run at neither the Grub4DOS nor the Windows command prompt, so boot Linux in UEFI mode and enter the following command in a terminal window to install grldr.mbr to the first partition of the internal disk:

/> sudo /boot/efi/bootlace.com --floppy /dev/sda1
Filesystem type is FAT32.
Success.

This makes the machine unbootable from the internal disk in legacy mode. So boot from the Grub4DOS-bootable USB stick, which becomes (hd0). At the commandline, enter:

grub> find --set-root /umbr
 (hd1,0)
grub> umbr -d=1 -p=0 --test 
 [3]:(129,0)+1

Without the "--test" switch, the code to jump to the beginning of the first partition gets written to the "protective" MBR. Booting from internal disk (hd0), we see:

1try
2try

But if we press [Enter] again, grldr.mbr, installed as a partition boot record, calls grldr, and we are shown the Grub4DOS menu. Only to get rid of those failing trials, go the commandline and enter:

grub> find --set-root /umbr
 (hd0,0)
grub> umbr -d=0 -p=0 --test /grldr /grldr.mbr 
 [0]:/grldr
         success:[ffffeb84]
 [1]:/grldr.mbr
         success:[33bd]
 [3]:(128,0)+1

Without the "--test" switch, so that the code gets written, and legacy-booting from internal disk (hd0), we now come to the Grub4DOS menu immediately. So I expect that after updating only grldr, I might have "1try" before the old grldr.mbr on the file system boots, and that after defragmenting the EFI boot partition, I might also have "2try" before the grldr.mbr boots that is installed as a fallback to the reserved sectors at the beginning of this partition.


Edited by Gerolf, 08 August 2021 - 11:58 PM.


#24 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 09 August 2021 - 07:30 AM

Nice :).

 

Still, if the idea is to have a same disk bootable to both UEFI and BIOS, and if we are allowed to modify the bootsector of the FAT32 volume a "more normal" (why does it sound so strange? :unsure: ) Hybrid MBR would do nicely.

 

You write to the MBR *any* code that chainloads the bootsector of the FAT32 ESP partition, and then you write to that *any* code that can chainload grldr.

To avoid the ugly (and theoretically non-standard) double entry in the MBR partition table one could use the code I put together, changing the hardcoded address (now for the underfloppy in sectors before 2048) to the FAT32 ESP extents.

 

Last time I tried (but has to be checked with newish MS code and newish grldr) the normal FAT32 bootsector code that loads BOOTMGR can be used to chainload grldr just fine.

 

I think (but again it should be checked) that one could use the bootsect.exe /NT52 to write the "old" 2k-XP code loading NTLDR and rename either the grldr or the grldr.mbr to NTLDR (I know that this is officially deprecated, but if it works, it works), or -alternatively - post-edit the NTLDR string in the bootsector to grldr..

 

:duff:

Wonko

 

P.S. Just in case, I am attaching a modified makebootfat MBR I put together at the time, moving the partition table (one entry only) to offset 414.

It should work, but has to be tested, a lot of years have passed in the meantime, the attached should be latest (working) version, but I actually have a mess of these test mbr's, so it is possible that it still needs some further tweaks. 

Attached Files



#25 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 10 August 2021 - 11:18 PM

Concerning the installation of Grub4DOS legacy on GPT disk using Chenall's Universal MBR (section 9, post no. 378), I can make a simplification in my previous post (no. 381).

 

The UMBR syntax help says that the first two files given as arguments to the umbr installer "can also be a PBR like (hd0,3)+1". Thus, to get rid of any ugly "1try, 2try" messages that might raise eyebrows on occasion, and relying entirely on grldr.mbr being installed as a "fallback" partition boot record using bootlace.com, I can install the UMBR just as follows (without the --test switch):

grub> find --set-root /umbr
 (hd0,0)
grub> ls
 EFI bootlace.com bootmgr grldr grldr.mbr menu.lst umbr
grub> umbr --test (hd0,0)+1
 [0]:(hd0,0)+1
         success:[66a5]
 [3]:(128,0)+1

Wonko said:

Still, if the idea is to have a same disk bootable to both UEFI and BIOS, and if we are allowed to modify the bootsector of the FAT32 volume a "more normal" (why does it sound so strange? :unsure: ) Hybrid MBR would do nicely.

 

You write to the MBR *any* code that chainloads the bootsector of the FAT32 ESP partition, and then you write to that *any* code that can chainload grldr.

 

To avoid the ugly (and theoretically non-standard) double entry in the MBR partition table one could use the code I put together (...) it is possible that it still needs some further tweaks.

 

The two commands "umbr (hd0,0)+1" (under Grub4DOS) and "sudo /boot/efi/bootlace.com --floppy /dev/sda1" (under Linux) already accomplish the task to make MBR and PBR chainload grldr, so I prefer Chenall's working UMBR code for now. But you proposed very useful Windows alternatives to the second command so that Grub4DOS could be chainloaded from NTLDR or BootMGR. Here I just liked the open-source option to boot a machine without the help and control of Microsoft.

 

In comparison to a "more normal Hybrid MBR", Chenall's "Universal MBR" misses the "ugly (and theoretically non-standard)" overlapping entry for the partition addressed by hard-code (and probably the unused ability to boot any other given partition). Legacy systems, however, may need this additional entry. It could be created permanently, using partnew, or virtually, using "map --in-situ", like I will do in the next one of my experiments to get a better understanding of a multi-bootable dual-mode UEFI/BIOS machine with GPT disk. Here's the actual UMBR from my test laptop.

Spoiler

 

10. FreeDOS installation on GPT disk

 

It is annoying that we have to wait one minute until Windows or Linux boots, and so many keystrokes are still required in administrator mode, when we just want to do a small change to one of our customized configuration files that we already have neatly sitting together on the EFI system partition (post no. 368 ff.):

 

  • \EFI\grub2\grub.cfg for Grub2 for UEFI ("Grub2EFI")
  • \EFI\grub\menu.lst for Grub4DOS for UEFI ("Grub4EFI")
  • \menu.lst for Grub4DOS for BIOS (legacy)

 

Can't we edit them faster, without forgetting some details while waiting for the system to boot? I had a similar problem when I was testing which Grub4DOS version would be the latest to run in PC Emulator. Then, I rebooted to a DOS image that automatically opened these files in an editor with a multi-document interface. Now, the DOS must just be able to access a FAT32 file system. We can stay open-source here, using FreeDOS.

 

Download the latest Live CD ISO archive, which comes with a modern Unicode text editor named BLOCEK. Currently we have preview release candidate 4 to version 1.3. Extract the file FD13LIVE.iso and copy it as \_SYS\FREEDOS\FREEDOS.ISO to any drive, preferably the EFI system partition. With the file being renamed, you can later update the FreeDOS installation to a new preview release candidate without the need to change the following two entries (for "Boot Live/Install" and "Normal boot on EFI system partition") in \menu.lst:

# \menu.lst
# ( ...)

title FreeDOS\n FreeDOS Live + Install CD ISO
set file=/_SYS/FREEDOS/FREEDOS.ISO
find --set-root %file%
map %file% (0xff)
set file=/KERNEL.SYS
find --set-root %file%
map --in-situ %@root%+1 (hd0)
map --hook
root (0xff)
chainloader (0xff)

title FreeDOS\n FreeDOS on EFI system partition
set file=/KERNEL.SYS
find --set-root %file%
map --in-situ %@root%+1 (hd0)
map --hook
root (hd0,0)
chainloader %file%

# ( ...)

Boot FreeDOS from CD ISO to the Live Environment. At the command prompt, enter FDISK to display the partition information:

Current fixed disk drive: 1

Partition Status   Type    Label   Mbytes   System  Usage
 C: 1        A   PRI DOS  No NAME    8001  FAT32 L     3%
    2            NON DOS           305251            100%
   
Total disk space is 305251 Mbytes (1 Mbyte = 1048576 bytes).

So we got the EFI system partition "mapped in situ" as drive C: while the actual partition table in the UMBR has only one "protective" entry. Here's the syntax for "map --in-situ" from README_GRUB4DOS.txt.

Spoiler

 

Reboot the Live CD ISO and select “Install to harddisk”. As we have seen before, FreeDOS already recognizes one existing and formatted FAT32 partition as drive C: and will therefore neither run FDISK nor FORMAT now, but just copy its files to the default directories. On a second run, it will notice that it is already installed. If you exchange the ISO file with a newer preview, SETUP will remove the old version and then install the new one.

 

Now write a small batch file named \SYSEDIT.BAT to open the configuration files in the multidoc text editor:

:: \SYSEDIT.BAT
@mode con lines=50 > nul
edit \FDAUTO.BAT \FDCONFIG.SYS \EFI\grub2\grub.cfg \EFI\grub\menu.lst \menu.lst
@mode con lines=25 > nul

The SYSEDIT command can be added to FDAUTO.BAT, and the FreeDOS boot entry in \menu.lst can be renamed to “Editor”. The downside of this quick access is, one may still have to temporarily switch the firmware to legacy BIOS mode. Therefore I also want to have a similar solution for UEFI.

 

Another disadvantage is that this FreeDOS installation somehow starts to mess up the EFI system partition, as multiple files and folders are created in the root directory. To avoid this, just use the Live Environment and only save \SYSEDIT.BAT to the EFI system partition (drive C:).






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users