Custom grub efi package for puppy

[rizalmart]

I wonder if someone in puppy developer will provide a custom grub efi packages. Which contains a custom grub efi files with embedded grub.cfg which set to read grub.cfg file beside the grub efi file. So that installing puppy on uefi gpt will be much easier. Just placing custom efi file on efi partition and write grub.cfg file on the same location of grub efi file

[gyrog]

FYI. I have managed to really boot Puppy from a USB stick with "SecureBoot" enabled, and with my frugal install directory in an f2fs partition on the stick. In /EFI/BOOT I renamed my "bootx64.efi" to "grubx64_real.efi" and then added "BOOTX64.EFI", "grubx64.efi" and "MokManager.efi" from "Super-UEFIinSecureBoot-Disk". I also copied "ENROLL_THIS_KEY_IN_MOKMANAGER.cer" to the root of the stick.

So none of Puppy is signed, even my grub2 is not signed. But there is a catch, the first time you boot the stick, it fails authentication but when you click on "OK", the MokManager kicks in and allows you to enroll the key in the "ENROLL_THIS_KEY_IN_MOKMANAGER.cer" file, this interface is a bit crude and best done with a stick containing only a single fat32 partition. But, it only needs to be done once on each machine, since it would be the same key for every Puppy, (and any other stick that uses "Super-UEFIinSecureBoot-Disk").

[CollaboratorGCM]

If you have a test ISO, community can test it (or post path here and I will test on my configurations). I will try to help with some crude documentation/report of steps here.

Your work @gyrog combined with the work of @wdlkmpx improves PUP's boot process such that many more users coming from distros with GRUB2 will easily understand the PUP Linux ease of use.

Secure-boot & loopback.cfg is a win-win. When new "official" PUPs are announced, these GRUB2 advancements should be noted in Puppy's Distrowatch announcement. I believe it will attract many and could case a rebound in membership participation, support, and development. Combined it allows PUPs to live on newer UEFI PCs, old PCs, and expands boot process options.

I feel confident many will want to try PUPs to witness these advancements.

[jamesbond3142]

[efiboot.img] This link doesn't last forever, so enjoy while it is hot. Thank me later.

EDIT: Superseded by https://github.com/puppylinux-woof-CE/woof-CE/issues/1618#issuecomment-562425932

[gyrog]

@wdlkmpx, Please wait for FrugalPup v16.

I plan to release another beta version of FrugalPup v15v very soon. This one includes the"SecureBoot" support as outlined in my previous post.

[gyrog]

FrugalPup v16 will probably not include any pseudo MOK support, just "SecureBoot disabled" I'm looking to implement full MOK support for FrugalPup v17.

Does anyone know if a binary can be signed a second time with a different key?

[jamesbond3142]

Does anyone know if a binary can be signed a second time with a different key?

Yes it can. But certain version of shims will only recognise the first signature; so the additional signatures won't have any effect. It's best that you drop the original signature and then re-sign.

[CollaboratorGCM]

Wouldn't that shim behavior constitute a "BUG"? If a new shim is added, the most recent shim addition should be the one used.

Can that be reported? OR is it pertinent ONLY to the PC manufacturer?

Edit: I may be off-track. If shim has a spec, its design may designate that only 1 per binary is allowed. Thus it may/may-not have the logic to process binary-key associations. Although, if some do and some don't, then one is a bug and should be reported: Which???

[CollaboratorGCM]

GRUB2 & EFI has made progress during past weeks. Several PUP developers have come forward with working efforts. I have reported 2 of them here as both are working to boot via its ISO; post is here. Further, I have tested the session-save to folder feature of those ISOs.

Has the time arisen to make GRUB2 obvious for use-selection via PUP's Menu?

If there is a standard library placement forthcoming, I will attempt to create a simple document on couple of options to boot new PUPs from their ISO files without exploding to various media for frugal/DVD and how they can maintain their sessions at the same time. PUPs using the standard library placement means that only one such document would be needed for future GRUB2 PUPs as their files & configurations would follow an PUP agreed to library placements; as well (it is hoped) as one that would be familiar to any person coming from other mainstream distros which have been using GRUB2 for years as the libraries would have consistent placement. Thus, it would match with each PUP produced.

[jamesbond3142]

[efiboot.img] This link doesn't last forever, so enjoy while it is hot. Thank me later.

Everyone seems to be borrowing grub2 left and right from other distros, even from obscure places I've never heard before. Except, of course, from one distro which has proven UEFI/SecureBoot support since 2012. Which also happens to be in the Puppy Linux family 🙄

I've already provided the link to efiboot.img above. For those who care about f2fs, the linked grub2 in that efiboot.img does support f2fs as well. I hope someone finds it useful. If not, then at least I know I have tried to help.

[gyrog]

@jamesbond3142, When I substituted my "EFI" directory with the "EFI" directory" from "efiboot.img", the boot failed with SecureBoot" enabled. Complained about my system being corrupt. I assumed that my kernel would need to be signed with the same private key used to sign grub2. As to borrowing, I'm using grub2 that I compile from source from GNU. For my next delve into this "rabbit hole", I will try to minimise my borrowing to a signed shim, and a signed MOK manager.

[jamesbond3142]

EDITED. In order to make this more accessible, I have removed the IMG files and replace them with a ZIP file which can just be extracted: EFI-shim-1.33-puppy.zip.

[CollaboratorGCM]

BTW, in using the 3 distros which have included "loopback.cfg" appropriately, they have all booted in BOTH standalone, as well as, via use of their ISOs being included in SG2D's "/bootisos" folder on the USB as well as the folder of ISOs being present on the systems HDD/SSD drives.

The 4 PUP distros are:

1. the one offered via GIT by @wdlkmpx , here ===> https://github.com/puppylinux-woof-CE/woof-CE/wiki/Builds#dpxp-stretch
2. FD810
3. ScPUP64 (2020 versions by @peabee Bee)
4. LxScPUP64 (2020 versions by @peabee Bee)

It is hoped that this new intelligence is carried forward in future PUPs/DOGs. It provides some immeasurable advantages for productive use, for testing, for evaluations, for comparisons, etc that developers as well as users will gain benefit with NO downside in this ability.

Further, it is hoped that this will be formulated in each PUP that is built going forward using GRUB2 for the advantages we know it offers developers. This means developers benefit by knowing of the worldwide GRUB2 Open Source commitment to keep it current as advancements in technology continues. Thus Puppy developer win as its little to no development work for them and the massive Linux user community wins as GRUB2 is so FAMILIAR to them and especially those in universities coming our way.

I apologize for my tardiness in reporting this to all here.

[CollaboratorGCM]

To streamline the pathway to WoofCE's "Puppy linux GRUB2 ISO use" on DVD/CDs, this should pave the way: https://www.gnu.org/software/grub/manual/grub/grub.html#Making-a-GRUB-bootable-CD_002dROM

The world's community has provided a wealth of clear documentation and videos that the Puppy community does not need to generate.

Consolidating boot around GRUB2 reduces PUP developer efforts into a singularity for the forthcoming years.

BTW: It is my understanding the infamous " 'puppy...'.sfs not found" that has plagued users for years on booting attempts in certain bios-uefi PCs will disappear as we move to GRUB2. We will have the toolset to track down many issues, thanks in part to all the commandline things provided.

[CollaboratorGCM]

ALL of @PeaBee's 2020 PUP distros BOTH meets this original poster's requests AND ALSO are able to selectable ISO files for booting via a "ISO Boot Selector" as SG2D (SuperGrub2). Same appear's to be true for @JamesBond & @Kirk Fatdogs from last month and going forward.

In the latter case, NO MEDIA IS NEEDED TO BURNED FOR THOSE PUPPY ISO FILES. Merely, the user just downloads the ISO and SG2D will present them for booting without user intervention. Simple, secure, easy!

I have found this a savior so that I no longer will ever need to burn a PUP ISO to any media thanks to the PUP developers who have made GRUB2 available OOTB.

PUPPY Development "CONTINUES" to be GREAT! as it continues improvements, continues steps to simplicity in use, and continues maturity over time.

With the new implementations via WOOFCE, developers are freed from having to wonder about booting on new devices or filesystems via GRUB2's international Open-Source community of contributors.

Bark-bark!

The author of this thread "may" want to close it.

P.S. I have acquired SG2D and burn the 16MB file to a CD. It finds Fatdog and PeaBee's ISO files and present them for selection. All of the PUP ISOs, tested thus far, boot without ANY issues or any need for user intervention. This is a very secure method of maintaining the integrity of the ISOs shipped by the PUP authors.

[CollaboratorGCM]

This is merely a comment; FYI

I know EVERYONE knows this, but, it bears reminding. I am an old-guy. I remember the original days of PC manufacturers and multiple BIOS makers and the "REQUIREMENT" of user to update their BIOS for their PCs as it was necessary for the hardware to work properly.

The same is TRUE for UEFI. And old UEFIs without their updates are, well, you know.

How many of us have noticed? (No answer required or requested)

[gyrog]

@jamesbond3142, Thanks for your efiboot-1.33. I'd already extracted the ".img" before I noticed your ".zip".

I tested it booting bionicpup32, bionicpup64, scpup, and scpup64; In each case the 64bit version booted fine, but the 32bit did not. With the 32bit versions I don't get the "EFI stub:" message, just a blank screen and nothing more. I then replaced the 32bit kernels with the 64bit kernels and tried again, they both booted successfully. So the problem seems to be with 32bit kernels.

[gyrog]

@jamesbond3142, Also, is there anyway to get rid of the annoying first "menu"?

[jamesbond3142]

@gyrog, You'd probably want to re-download and use the updated ".zip" version. I replaced with fatdog certificate with puppy's one. There is no difference in functionality, only the visual appearance, though.

In each case the 64bit version booted fine, but the 32bit did not.

I downloaded bionicpup32 8.0 and tested the package on qemu. I tested with both SB enabled and SB disabled. In both cases it boots to the graphical desktop.

Here is the filesystem layout I use for testing. All the puppy files comes the ISO.

├── adrv_upupbb_19.03.sfs
├── EFI
│   └── boot
│       ├── bootx64.efi
│       ├── grubx64.efi
│       ├── mmx64.efi
│       └── puppy.cer
├── fdrv_upupbb_19.03.sfs
├── grub.cfg
├── initrd.gz
├── puppy_upupbb_19.03.sfs
├── vmlinuz
└── zdrv_upupbb_19.03.sfs

Contents of grub.cfg:

set timeout=10
menuentry "Start Linux" {
    linux /vmlinuz 
    initrd /initrd.gz
}

I also tested on a real machine, a 8-year-old Dell HP desktop without SB, with a slightly different filesystem layout (all the puppy files are under a subdirectory). It also boots to graphical desktop too.

I tested it booting bionicpup32, bionicpup64, scpup, and scpup64; In each case the 64bit version booted fine, but the 32bit did not. With the 32bit versions I don't get the "EFI stub:" message, just a blank screen and nothing more.

This is a bit odd. I'm assuming you're testing on the same machine?

If you're testing on different machines for the 64-bit and 32-bit version, here is something to consider. Most UEFI machines have 64-bit UEFI. But not all. Some machines - especially the bottom-of-the-pit varieties - those that uses Baytrail and the like, have 64-bit CPU and 32-bit UEFI BIOS. (Aldi used to sell some of these before, and I'm sure other shops do too.) They will look for bootia32.efi to be able to boot successfully. I would argue that these machines are rare, but if you do have one of these for testing, then yes it will fail to boot without any "EFI stub" message because I don't have it in the zip file. I can update the zip file with bootia32.efi if you need it.

I then replaced the 32bit kernels with the 64bit kernels and tried again, they both booted successfully. So the problem seems to be with 32bit kernels.

^ This statement however seems to indicate that you use the same machine to test, and the 64 bit kernels boots ok. Which is odd. I cannot reproduce the problem - the 32-bit pup boots in all my test cases. I only tested bionicpup32 though, I didn't test sc32.

Also, is there anyway to get rid of the annoying first "menu"?

You mean the one that says "Load grub.cfg from local disk"? Do you want it to always go for the first action without waiting?

[CollaboratorGCM]

Should there be a loopback.cfg somewhere in "that" filesystem layout?

Further, WOOFCE, etc are distro builders. Should this tool, GRUB Customizer (below), be a part of the build for developers to tailor their individual opening stanzas? Evaluate applicability.

Can this be used to tailor a proper GRUB+EFI for PUP developer uses/needs such that it reduces and standarizes a method for PUP distro presentations? GRUB Customizer tool

The idea of these boot loader approaches to become a standard view for PUPs such that each PUP generated has standard library formats leading to one where little thought goes into understand why on one distro it is laid out this way and on another the boot files are laid out differently. Since the elements of booting is the same, shouldn't PUPs have their "boot" library formats the same across to board to reduce many questions that arise from time to time. This also has the potential benefit that problem solutions would surface that would apply across the PUP distro spectrum as the library would be common for any/all debug processes.

The boot-loader process should be common sighted structure and common library structures.

And, this has long-term benefit to all; developers, contributors, and users, alike. And, since a few "hate the word" Standard, why not just call it 'COMMON'; both words meet the objective.

Worth considering?

[gyrog]

@jamesbond3142 , Thanks. I'll download the ".zip" and re-test.

For all tests I'm using a HP Stream 11, a small laptop Windows 8.1 machine, with an mmc internal drive. It's the only machine I have with SecureBoot enabled.

As to the first screen, yes, I think it should always "Load grub.cfg from local disk" and go directly to the OS selection (main) menu. It's what I'm used to with grub4dos, and with grub2 when I've compiled it and installed it in a rather vanilla way.

[gyrog]

@jamesbond3142, Good news. I created a simple frugal install of ScPup and ScPup64 to a usb stick (single fat32 partition), using the /EFI directory from your "EFI-shim-1.33-puppy.zip". I sucessfully booted both to the desktop, with "SecureBoot" enabled and "SecureBoot" disabled. As expected, with "SecureBoot" enabled the MOK manager kicked in on the first boot with this new key, but after that just straight boot.

One thing I noticed about the MOK manager is that the partition selection screen is not quite so obsscure if the fat32 partition has a label.

I still would prefer that it went straight to the main OS selection menu.

Also, one of the things I miss about grub4dos is the console messages while it loads vmlinuz and initrd.gz. With all the different grub2 installs I've tried, the screen remains completely blank during this time, which can take several seconds on a slow machine booting from a slow usb stick. Is there a way to get grub2 to spit out some console messages during this time?

As to "bootia32.efi": I have a Lenovo that needs that even for "SecureBoot" disabled, so for completeness, I would appreciate it being included in the ".zip". If the shim is "bootx64.efi", can it work on such a machine?

[jamesbond3142]

For all tests I'm using a HP Stream 11, a small laptop Windows 8.1 machine, with an mmc internal drive. It's the only machine I have with SecureBoot enabled.

I had something like that - the Aldi PC, I think - but right now I don't have it anymore and can't recall whether it had 32-bit UEFI or 64-bit UEFI. I think it was 32-bit UEFI. In any case, if your HP Stream can boot 64-bit pups with bootx64.efi, then it must have 64-bit UEFI and the rest of my comment for bootia32.efi is not applicable.

As to the first screen, yes, I think it should always "Load grub.cfg from local disk" and go directly to the OS selection (main) menu. It's what I'm used to with grub4dos, and with grub2 when I've compiled it and installed it in a rather vanilla way.

Ok. I can make the timeout to zero so the screen is effectively skipped, but I cannot eliminate it altogether, because, what would happen if grub.cfg cannot be found on any disk?

Good news. I created a simple frugal install of ScPup and ScPup64 to a usb stick (single fat32 partition), using the /EFI directory from your "EFI-shim-1.33-puppy.zip". I sucessfully booted both to the desktop, with "SecureBoot" enabled and "SecureBoot" disabled.

Excellent!

As expected, with "SecureBoot" enabled the MOK manager kicked in on the first boot with this new key, but after that just straight boot.

Yes, that the correct behaviour.

One thing I noticed about the MOK manager is that the partition selection screen is not quite so obsscure if the fat32 partition has a label.

That's good to know. The old MOK manager didn't do this, I think this is an improvement from the original MOK manager.

I still would prefer that it went straight to the main OS selection menu.

Well for SB we really can't skip it until the signature has been authorised.

Also, one of the things I miss about grub4dos is the console messages while it loads vmlinuz and initrd.gz. With all the different grub2 installs I've tried, the screen remains completely blank during this time, which can take several seconds on a slow machine booting from a slow usb stick. Is there a way to get grub2 to spit out some console messages during this time?

Yes, I miss this feature as well. I have not been able to do this. That being said, I have never used grub2 for non-UEFI booting. I wonder whether the BIOS grub2 lack the ability as well, or is this a specific problem for UEFI version of grub2?

I'll test it if I have time.

As to "bootia32.efi": I have a Lenovo that needs that even for "SecureBoot" disabled, so for completeness, I would appreciate it being included in the ".zip".

Okay, I'll update the zip package then. I need to rebuild it to zero the timeout first.

If the shim is "bootx64.efi", can it work on such a machine?

If your Lenove requires bootia32.efi, it runs 32-bit UEFI and requires 32-bit shim. bootx64.efi is 64-bit shim and won't work. You will need 32-bit shim.

In the past 32-bit shim didn't exist so I would have said that for these kind of machines, just disable SB. However, we now have 32-bit shim. I haven't tested it though, I don't have 32-bit UEFI with SB (only the non-SB one). Once I update the zip file you can probably test if the 32-bit shim really works on 32-bit SB UEFI.

[CollaboratorGCM]

With changes that now are in @jamesbond3142 & @PeaBee distros, so far working with the SG2D boot selector, I have no further needs to use Frugal/DVD/CD installs, ever.

Merely download the ISOs to a '/boot-isos' folder and boot SG2D to a FD810/ScPUP/LxPUP/... desktop.

Save session persistence remains as expected.

Not only no future frugal steps, but also no need to install the ISO to ANY media.

Puppy Linux, now, has a solution to boot its ISOs on either BIOS/UEFI system, maintaining PUP integrity and expected system behavior in a static read-only base system ISO file for security.

Another PUPPY Linux win-win.

I am in the process of further detailing a simple disk layout where any user can use it to boot these PUPs and other distro ISOs, like Ubuntus/etc... This intends to allow users to see how a simple pathway can alleviate any need to do anything beyond "download an ISO and boot".

[gyrog]

@jamesbond3142, Thanks. I look forward to the next version of the zip.

I'll try testing the 32bit shim on the Lenovo.

"Interesting": For not-uefi booting, I've started playing with using Grub4Dos to chainload grub2. (Grub4Dos mbr writing utility much, much simpler to use than Grub2.) The interesting thing is that when I do this, after selecting a Puppy in the Grub2 menu, I do see some console messages, before I see the first one from the "init" script.

[gyrog]

@jamesbond3142, Sorry, I might have been misleding, I just checked again with a non-uefi boot using grub2 directly, and I get some console messages before the first one from "init". So, the extra console messages seems to a non-uefi thing. I suspect that it's a console thing. When booting grub2 non-uef, by default the console begins with quite a large font, similar to grub4dos, for both the main menu and subsequent console messages. But when grub2 is booted uefi, by default the console has a very small font. I always use my own font for the main grub2 menu for uefi boots.

[gyrog]

@jamesbond3142 Of course there is another difference between your efi grub2 and my non-uefi grib2, Yours is version 2.03, mine is version 2.04.

[jamesbond3142]

@gyrog

Thanks. I look forward to the next version of the zip.

The zip is updated. It now has the full shim64/32 and grub64/32, with the first "search for grub.cfg" menu hidden (timeout=0). Give it a try when you have time.

Thanks for testing non-UEFI grub booting for the boot message. I figured out that when I "echo" something, that echo is now shown. So now I have edited my grub.cfg to look like this:

menuentry "Start Linux" {
    echo "Loading ..."
    linux /vmlinuz pfix=nocopy
    initrd /initrd.gz
    echo "Loading complete, booting now ..."
}

So at least it shows something, and not completely blank. I can't show the dynamic message though, like grub4dos showing the file size as it is being loaded, or like syslinux showing the dots as the file is being loaded.

Yours is version 2.03, mine is version 2.04.

Mine is actually somewhere in between, it's from 2018-07, after they have added f2fs support. Commits after that until 2.04 release are mostly for non-x86 platforms support and fixes (RISC-V, arm64, Xen etc).

But when grub2 is booted uefi, by default the console has a very small font. I always use my own font for the main grub2 menu for uefi boots.

I can't remember where I found the font anymore. It is called euro.pf2 and is a subset of the full unicode.pf2 which came from GNU Unifont. I can't remember the size. But you can always use grub-mkfont and load it in your own grub.cfg. I just tried it last night with Terminus font with size 24 and the screen does look better. I added this menu entry for future Fatdog release:

menuentry "Use larger font" {
    loadfont /terminus24.pf2
    terminal_output console
    terminal_output gfxterm
}

Let me know how it goes.

[gyrog]

@jamesbond3142 Thanks. I have the new zip, it's bigger, so I probably do have the new one.

I'll test and report back here, when I can.

An "echo" at the beginning of loading looks good. I'm not sure if I need an after one, since the "init" script starts spiting messages quite early, but we'll see.

I'm conually intrigued by the differences between uefi and non-uefi grub2. I just fould a hardware situation where hd0 is the default root device in a non-uefi boot, but hd1 is the default root device in a uefi boot, identical hardware situation.

[gyrog]

@jamesbond3142 Good news.

On my Lenevo, (which I presume to need 32biit efi, since it doesn't recognise a stick without bootia32.efi).: Booted to desktop with "SechreBoot" disabled. With "SecureBoot" enabled, after MOK stuff, booted to desktop.

On a HP Stream (works with bootx64.efi): Booted to desktop with "SecureBoot" enabled, (Puppy MOK was already enrolled).

On my desktop (works with bootx64.efi): With "SecureBoot" disabled, booted to desktop.

All tests included Bionicpup32, with 32bit kernel.

So, it looks like we have a solution that should work on pretty much any machine. Thanks.

A note on the messages while loading the kernel: The "echo" statements work fine. I suspect that the messages we see from a non-uefi boot are from the Kernel, not Grub2.

There is 1 change I make to your efi stuff, I change the name of the key file to "Puppy_key.cer" and place it in the root of the fat32 boot device. My idea is to make it a litle easier for a user to find during the MOK enroll process.

[jamesbond3142]

@gyrog

So, it looks like we have a solution that should work on pretty much any machine. Thanks.

You are much welcome, and thanks for testing it.

There is 1 change I make to your efi stuff

I'll leave that to you on how to package it. After all you're the one providing the end-user tool to install it (Frugalpup) - you've got to decide what you think is best (easiest) for the end-user.

The ZIP file I uploaded isn't meant for end-user (they probably don't know what to do with it anyway); it's a public service for all tool builders like yourself and everyone else in the Woof-CE community to integrate with whatever installation tool that comes with their Puppies, if they wish.

[CollaboratorGCM]

@gyro. Would you consider, please, testing your Bionicpup32 ISO being booted directly to desktop from your ISO file. Download SG2D and place your ISO in its appropriate /boot-isos folder.

Does it boot your ISO directly to desktop?

This, we know, works with @Peabee and @Jamesbond 2020 distros (Dec 2019 too). Does it work the same for your productions?

I think you know the benefit that this test brings to your ISO file's use, along with the other PUP distros mentioned.

P.S. If you would like me to test, too, send me a link to your ISO version(s)

[CollaboratorGCM]

I think, by now, we all can see what this offers. We can not only boot these ISOs from a DVD-CD as well as Frugal and full-installations after some fiddling.

BUT a new dimension to PUP service is now available where PUPs are booted DIRECTLY from the downloaded ISO file with NO need for anything to be done to boot to a desktop. No USB, no DVD, no Full...Just boot the ISO file, you choose, from your folder of ISOs.

• Users see exactly the same distro boot dialogues for the ISO they select from their folder
• PUP persistence (save sessions) continue to behave as they do today.

Win-win for users, testers, developers, remasterers, etc.

P.S. I must commend @JamesBond for ALL of what I have learned thru his recent experiences and contributions to this thread and PUP boot process understanding! THX!

[jamesbond3142]

@rizalmart, @gyrog I've just updated the EFI zip package with a version of grub2 that can load grub.cfg from the same folder as grub2.efi as the first priority. If grub.cfg isn't found there, then the usual places will be searched. This should finally answer the first post of this long thread.

EDIT: zip file updated with more robust implementation. If you downloaded before you see this EDIT, then please re-download. Current version dated 2020-Feb-05 05:01:05 in ibiblio.org.

[CollaboratorGCM]

Puppy member @ETP has opened a forum thread announcing those Puppy ISOs which boot directly from their ISO files when selected in SG2D.

Users, who choose so, will never need to explode the ISO to media: No Frugal requirement and no DVD requirement. Download the file and boot to its desktop with persistence via folders or squash or file just as they do today.

Works beautifully.

[gyrog]

@jamesbond3142, I've re-downloaded "EFI-shim-1.33-puppy.zip", thanks.

Although the expected location of "grub.cfg" doesn't matter much to me, since I've used a number of grub2 implementations with different expectation. I just place a "grub.cfg" in the expected loaction that contains the line "configfile /grub.cfg".

[jamesbond3142]

@gyrog, no worries.

I should have made it clear - it will look for grub.cfg 4 different places:

1. In the same path as where grub2.efi is located.
2. In /grub.cfg, all drives
3. In /boot/grub.cfg, all drives,
4. In /boot/grub/grub.cfg, all drives

The first one found will be used.

You can put grub.cfg in any one of those. The first one (1) is specifically to meet @rizalmart's request who wants to have a grub2.efi that loads grub.cfg from where it is located.

In fact, there is the grub.cfg snippet that does it, for your reference:

menuentry "Load grub.cfg from local disks" {
    if [ "$cmdpath" ]; then
        unset root
        regexp --set 1:root "(\(.*\))" $cmdpath
        if [ "$root" ]; then
            configfile $cmdpath/grub.cfg
        fi
    fi

    unset root try
    for try in /grub.cfg /boot/grub.cfg /boot/grub/grub.cfg; do
        echo Looking for $try ...
        if search --file --set=root $try; then
            configfile $try
            break
        fi
    done
}

This seems to work on UEFI only. On BIOS grub2, $cmdpath does seem to provide the full path to grub2.img - only the (root) part of it.

[CollaboratorGCM]

@gyrog, a request. On your forum thread here you say "It uses grub2-efi for uefi booting and grub4dos for mbr/legacy booting."

Is there any chance for a version which has a single bootloader and says "It uses grub2-efi for uefi booting and grub2 for bios-mbr/legacy booting."?

This would lead to those who would only need to use & debug a single boot loader; namely GRUB2.

This is NOT asking to remove the GRUB4DOS utilities; merely that OOTB it would be based GRUB2 for both PC firmware boot types.

I am sure you know the advantages.

[gyrog]

@CollaboratorGCM, Your forum refernece is to the first post in the topic. The text you are referring to is part of the announcement for FrugalPup v0.3, the first release. I'll edit the first post to make this more obvious.

Since FrugalPup v16, grub2 has been used for both uefi and non-uelf booting, so the same '/grub.cfg' is used for both.

FrugalPup v19 will actually re-intoduce grub4dos, simply to load grub2 in non-uefi boots. So from a users perspective, it's still grub2 that boots Puppy in uefi and non-uefi boots.

[CollaboratorGCM]

@gyrog , Thanks! Should boot in SG2D, I hope. What couple of PUP members are doing is to have a central folder "boot-isos" which it will find and boot those 2020 PUP ISO files it find....as long as they have the loopback.cfg.

No media is needed to be burned from the ISO unless members feel they must do that.

Namely, downloading the ISO into that folder, boot SG2D which finds the download and the user selects the ISO and it boots to desktop. No CD no DVD no USB...just the ISO file(s) with all of the features we get today in media frugal expansion.

I know you know these things and understand them better than most users.

Thanks for understanding. Looking forward.

[CollaboratorGCM]

@peabee ALL of your PUPs including your latest ArchPUP64 boots via SG2D to desktop on both UEFI & BIOS PCs.

Great! As it allows ALL of these newer 2020 PUPs as well as FATDOG ISO can be kept in a single library where they will boot with ALL of PUPpies' traditional glories!

Speed to desktop is as fast/faster than Frugals. This negate any need for manual/auto undoing any PUP ISO and needing to take storage space to manage as is required for Frugal use. Merely download, save ISO to common folder (normally done anyhow) and can boot immediately in real PC or in VMs or ...

Thanks for all of what you guys are doing to allow this new PUP boot feature to be exploited with NO NEW CODE!

[CollaboratorGCM]

Tested Fossapup64 - alpha and UPup Eoan-Focal as well as ArchPUP64on both BIOS & UEFI machines. Boots without any issues via SG2D, along with all the other 2020 WOOFCE PUP ISOs found in my /boot/boot-isos/ folder, thus far.